Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Entwicklung & Design

Traditionelle Webentwicklung vs Versionsverwaltung

Die Website ist konzeptioniert, definiert und es gibt ein Design. Sie soll auf Basis eines Open Source Frameworks in PHP mit MySQL-Datenbank umgesetzt werden. Jetzt kann es an die Arbeit gehen. Doch welche Workflows technischer Art gibt es für kleine bis große Webprojekte? Dieser Beitrag vergleicht einfache, traditionelle Webentwicklung-Workflows mit den Möglichkeiten, die moderne Versionsverwaltungssoftware bieten, und versucht, einen Anreiz zu geben, den Umstieg trotz etwas Einarbeitungszeit zu wagen.

Der traditionelle Weg

Vereinfacht gesagt gibt es hier zwei Methoden deren Anwendung fließend ineinander übergehen und beliebig kombiniert werden können:

a) Lokal arbeiten und später hochladen

Beim lokalen Arbeiten werden die Dateien (HTML, CSS, JS, PHP, etc.) zunächst auf dem eigenen Arbeitsrechner bearbeitet. Um die Website zu testen, kann auf dem lokalen Rechner ein Webserver laufen. Im Anschluss werden Änderungen manuell auf den Webserver übertragen, der die finale Version der Website ausliefert.

Dies ist natürlich etwas langsam und mühselig. Auch besteht die Gefahr, beispielsweise eine Datei in einem verschachtelten Unterordner zu vergessen. Zwar kann man nach jeder Änderung stets alles hochladen. Dieses Verfahren ist weniger fehlerlastig, doch zugleich langsamer.

Einige moderne für Webentwicklung optimierte Text Editoren bringen eine Projektverwaltung mit. Der Editor merkt sich die lokalen Änderungen und synchronisiert dann nur diese mit dem Server. Dies erspart ein lästiges Hantieren mit Dateien in verschachtelten Verzeichnisstrukturen.

b) Direkt auf dem Server arbeiten

Die Dateien vom Webserver werden vom FTP-Client direkt im Texteditor geöffnet und beim Speichern unverzüglich zurück auf den Webserver geschrieben. Dies kann durch temporäre lokale Dateien realisiert werden oder durch das Mounten des Webserver-Verzeichnisses mit Programmen wie CurlFTP oder SSHFS.

Änderungen sind sofort übertragen und online. Modifikationen lassen sich vorher aber nicht testen. Tippfehler sind für die Besucher sichtbar. Sollte während der Datenübertragung die Internetverbindung unterbrochen werden, droht Datenverlust.

Um Daten bei der traditionellen Webentwicklung zwischen dem lokalen Entwicklungsrechner und dem Webserver transferieren, bedarf es eines Übertragungsprotokolles. Der Standard hierfür ist FTP, aber WebDAV oder SCP und SFTP via SSH sind auch möglich.

Viele FTP-Clients beherrschen auch SFTP. Bei diesem auf SSH basierendem Protokoll kann man serverseitige Aktionen wie das Entpacken einer Datei vornehmen. Eine TYPO3-Installation wäre damit beispielsweise deutlich schneller umgesetzt.

Mit Tools wie rsync lassen sich die lokalen und online Dateien abgleichen. Auch bieten viele moderne FTP Clients Synchronisationsmöglichkeiten an, die lokales Caching der Stände auf dem Webserver anbieten.

Versionsverwaltung

History Darstellung in GitG (grafische Oberfläche für GIT unter Linux) vom öffentlichen Master Branch des jQuery Repositories.

Aus der klassischen Softwareentwicklung ist Versionsverwaltung (engl. Version Control System = VCS) nicht mehr wegzudenken. Entstanden ist sie aus den Notwendigkeiten des Programmierer-Alltags:

  • alte Stände sollen verfügbar sein
  • gemeinsames Arbeiten am Programmcode
  • schneller und einfacher Austausch von Änderungen

Versionsverwaltung ist ein System zur Erfassung von Änderungen an Dokumenten oder Dateien. Jede Versionsverwaltungssoftware sollte folgende Eigenschaften aufweisen:

  • Wann? Jede Änderung hat eine Zeitstempel.
  • Wer? Der Benutzer, der die Änderung vorgenommen hat.
  • Was? Die Daten der Änderung bestehen immer aus dem Differential (den geänderten Zeilen von einer oder mehreren Dateien).
  • Warum? Zu jeder Änderung kann eine Anmerkung gespeichert werden.
  • Und: Jede Änderung hat eine eindeutige Nummer, über die sie zu jedem Zeitpunkt identifiziert werden kann.

Versionsverwaltung bietet also Protokollierung, Archivierung und damit einhergehend die Möglichkeit zur Wiederherstellung. Es gibt zwei verschiedene Arten von Versionsverwaltungssystemen: zentral und dezentral (engl. Distributed VCS = DVCS).

Zentrale Versionssysteme gehören meist zu den älteren Generationen. Am bekanntesten sind wahrscheinlich Concurrent Version System (CVS) und Subversion (SVN). Alle Änderungen werden von den Benutzern auf den zentralen Server eingespielt und können dann von anderen Benutzern wiederum heruntergeladen werden. Diese Vorgänge nennt man oft commit (oder check-in) und update (oder check-out).

Neuere dezentrale Versionssysteme kommen komplett ohne einen Server in der Mitte aus - schließen diesen aber nicht aus. Bekannte Vertreter sind GIT, Bazarr und Mercurial. Jeder Benutzer ist gleichzeitig „Anbieter“, man spricht hier von einem Repository. Die Richtung des Austausches von Änderungen ist hier weniger definiert. Geläufig ist, dass sich ein Benutzer eine Kopie (oft clone genannt) eines Repositories zieht und daran weiterentwickelt. Später kann das Orginal und die Kopie dann wieder zusammengeführt werden (merge).

Die Relevanz und der Zeitgeist dieser Technologie lässt sich am Erfolg von GitHub, SourceForge und BitBucket (und den zahlreichen ähnlichen Anbietern) messen. Diese Dienste hosten Softwareprojekte und bieten Versionsverwaltung an. Alleine auf GitHub gab es Anfang 2011 über 1,5 Millionen Repositories. Darunter viele populäre Open Source Projekte wie Ruby on Rails oder jQuery.

Hintergründe: Versionsverwaltungssysteme

Die Mutter aller Versionsverwaltungssysteme ist CVS (Concurrent Versions System). Dieses Urgestein (1986 veröffentlicht) ist auch heute noch im Einsatz. Inzwischen ist es allerdings nicht mehr zu empfehlen, da neuere Systeme anwenderfreundlicher sind und grundlegende Verbesserungen in vielen Bereichen bieten.

Neben CVS wahrscheinlich das verbreitetste Versionierungssystem ist Subversion (SVN). Auch SVN hat eine zentrale Verwaltung. Gegenüber CVS bietet es viele Neuerungen, wie z.B. der bessere Umgang mit Logs für einzelne Dateien, Revisionierung für gesammelte Änderungen (anstatt eine Version für jede geänderte Datei), ein schlankeres Protokoll, da alle Änderungen lokal erfasst werden und vieles mehr.

HG (Mercurial): Ein neueres Versionssystem mit verteilter Architektur, in Python geschrieben, was es plattformunabhänig macht. Mercurial wird von Google Code unterstützt.

GIT: Eine weitere verteilte Versionsverwaltung, initial entwickelt von Linus Torvalds, dem Vater von Linux. Im Gegensatz zu Mercurial ist es komplett in der Sprache C geschrieben, was einen nicht unerheblichen Geschwindigkeitsvorteil mit sich bringt. GIT ist das, was die coolen Kinder benutzen.

Versionsverwaltung in anderen Bereichen: Mac-Benutzer sind mit Apples „Time Machine“ als Backuplösung vertraut, mit Hilfe derer sie auf alte Zustände von Dateien zugreifen können. Adobe Version Cue ist ein Versuch gewesen, Designern die Vorzüge der Revision näher zu bringen. Bei Wikis wie Wikipedia wird Versionierung eingesetzt, um alte Zustände bei Konflikten zwischen Autoren verfügbar zu haben. Auch Textverarbeitungsprogramme wie Microsoft Word oder Google Docs haben eine „Track Changes“-Funktion zur Überwachung von Änderungen. Auch das beliebte Blogsystem WordPress speichert Artikel mit allen Änderungen.

Der moderne Weg

Tatsächlich ist der „moderne Weg“ so modern gar nicht. Es gibt wahrscheinlich keine große Website im Netz, bei deren Entwicklung nicht irgend eine Art der Versionsverwaltung eine große Rolle gespielt hat - und dies seit Jahren. Wenn also Versionsverwaltung so grandios ist, warum setzt es dann nicht jeder ein?

Versionsverwaltung wirkt für einige auf den ersten Blick sehr komplex, doch kann man mit wenigen Handgriffen die meisten täglichen Aufgaben ausführen. Hat man sich erstmal eingerichtet, lebt es sich sehr bequem und man profitiert von den Vorteilen. Diese rentieren sich schon bei kleinen Projekten mit nur einem Entwickler.

Versionsverwaltung in der Webentwicklung

Das Aufsetzen eines Systems, welches Versionsverwaltung und Webserver-Struktur vereint, erfordert Vorkenntnisse in Systemadministration. Exemplarisch sei auf das folgende Szenario verwiesen:

Auf dem System, auf dem der Webserver läuft, befindet sich auch noch ein VCS-Server. Werden Änderungen in den VCS-Server eingespielt, aktualisiert dieser die (Website-)Daten des Webservers. Es sollte eine Rückspielmöglichkeit älterer Stände in den Webserver geben.

Ein commit spielt die neuen Änderungen ein. Hierin ist alles enthalten, was geändert, gelöscht und hinzugefügt wurde. Dieser commit wird dann zum VCS-Server geschickt, welcher wiederum die Daten der Website auf den aktuellen Stand bringt. Merkt man dann, dass sich mit der neuen Änderung ein Fehler eingeschlichen hat, kann auf einen früheren Stand zurückgegriffen werden.

Der Kollege zieht sich ein Update über den VCS-Server und kann sicher sein, mit den neuesten Daten zu arbeiten. In puncto Teamfähigkeit erlauben gerade neuere DVCS sogar das parallele Arbeiten in den gleichen Dateien. Bei Programmen wie GIT oder Mercurial muss nur interveniert werden, wenn zwei Änderungen an der gleichen Stelle derselben Datei vorgenommen wurden. Vergleichswerkzeuge (z.B. diff) helfen, diese Konflikte zu verstehen.

Ein Projekt kann dabei mehrere Auslieferungs- bzw Entwicklungsstränge (branches) haben. So kann man mit einer Quelle eine stabile Version und eine Entwicklungsversion verwalten. Diese Zustände lassen sich intelligent zusammenführen und auch weiter verzweigen. Ein Beispiel für Entwicklungszweige bei Webentwicklung: Eine Umgebung (Deployment) der Website ist live und für alle Besucher zugänglich. Eine weitere ist die Entwicklungsumgebung, die ausschließlich den Programmierern zugänglich ist. Gibt es in der Live-Umgebung ein akutes Problem, kann ein Bugfix entwickelt und dort eingespielt werden. Erreicht die Entwicklungsumgebung einen stabilen Stand, kann diese mit der Live-Umgebung unter Berücksichtigung dieses Bugfix zusammengeführt werden. Nach Meinung des Autors bringt erst eine Versionsverwaltung in Kombination mit mehr als einem Deployment wesentliche Vorteile. Weitere Ausführungen hierzu würden den vorgegebenen Rahmen des Artikels überanspruchen.

Professionelle Programmierer greifen auf ihre Repositories natürlich per Shell zu. Merge, commit, update, check-out und Co werden also per Kommandozeile durchgeführt. Es gibt aber auch einige kleine Helfer, die eine GUI für die abstrakten Prozesse zur Verfügung stellen. Vor allem bei der Arbeit mit Branches kann das sehr hilfreich sein. Diese gibt es für verschiedene Betreibssysteme, die verschiedenen Versionsysteme, in kommerziellen und in kostenfreien Varianten. Einige Texteditoren bringen von Hause aus Unterstützung mit, andere lassen sich per Plugin nachrüsten.

Fazit

Die traditionellen Methoden sind für kleinere Projekte mit nur einem Entwickler ausreichend. Sie lassen sich nach Belieben kombinieren. Vor allem ist man schnell ohne Einarbeitung und Einrichtung „drin“.

VCS ist eine sehr interessante Technologie, die Entwicklern Arbeit vereinfacht und Problemen vorbeugt. Projektgröße und Professionalisierung sind entscheidende Kriterien für den Einsatz von VCS.

Betreiber eines eigenen Webservers benötigen Vorkenntnisse in Systemadministration zum Installieren eines VCS in einer Webserverumgebung. Klassische Webhoster bieten in der Regel keine vorgefertigte Lösung für Webentwicklung mit Versionverwaltung an. Doch am Beispiel von modernen Cloud-Hosting-Anbietern (wie Heroku), bei denen teilweise Zugriff nur über Versionsverwaltung möglich ist, erkennt man, dass es für Webhosting mit Versionsverwaltung durchaus ein interessiertes Publikum gibt. Abschließend sei darauf verwiesen, dass es bereits einige reine Repository-Hoster (wie Beanstalk) gibt, die Schnittstellen zu Webhosting anbieten.

Artikel zum Thema

Über den Gastautor

Frank Lämmer ist Webdesigner und Gründer von Fortrabbit, einem Startup aus Berlin, welches innovative WebHosting-Lösungen anbietet. Derzeit wird an Webhosting mit Versionsverwaltung auf Basis von GIT mit Deployment entwickelt.

Finde einen Job, den du liebst

Bitte beachte unsere Community-Richtlinien

13 Reaktionen
Frank Lämmer

@Evil:
Also Versionierung ist eine volatiler Begriff. Wenn Du nach einer Versionierung in der Qualität eines VCS suchst, dann spar dir die Zeit. Wenn Du nach einer Versionierung a la Snapshots suchst, dann ist das relativ einfach.

Via Snapshot: Mach einfach einen Dump vor jedem Update. Das geht in den gängigen VCS via Hooks. Zugegeben, wenn Du eine Große DB (je nach Festplattengeschwindigkeit etc, sagen wir mal 2GB Daten), dann such dir was zu lesen, bevor Du "git push" (oder "svn commit" oder was auch immer) ausführst. Bei einem Rückspielen einer Version, entsprechend einem re-sync des alten Dumps (d.h. Differnzdaten zwischen altem und neuen Update sind verlustig). Das kann man sicher auch noch verbessern: Leg zB eine "db-version"-Datei an und führe den Dump nur aus, wenn sich der Inhalt darin ändert.. oder sowas in der Art.

Für die VCS-like Versionierung muss (mindestens) folgendes erwartet werden: Man kann zu jeder Zeit zwischen Versionen wechseln.

Das geht gut, mit einem VCS auf Dateisystem-Eben, denn hier werden eigentlich nur "statische" Daten versioniert. Beispiel: Nehmen wir an Du hast eine Website mit User-Upload-Daten, zB Bildern, dann würdest Du diese Daten aus der Versionierung via VCS ausnehmen (dafür wären sie aber zB in deinen Backup-Snapshots drin, was eben eine gänzlich andere Art der Versionierung darstellt).

Das abgebildet auf eine DB würde bedeuten: in der DB sind "statische" Objete, die Logik/Struktur abbilden - nicht Inhalte. Das gibt es zwar (Tabellenstrukturen, Stored Procedures, Views, etc), aber diese Objekte sind nicht annähernd so unabhängig von den Laufzeitdaten wie zB eine PHP-Controller-Klasse vom Bilder-Upload Verzeichnis: die Tabellenstruktur kann nicht geändert werden ohne alle Tabellenzeilen zu modifizieren. Stored Procedures sind wiederum abhängig von der Tabellenstruktur - genauso wie Views.

Wenn Du also von der Versionierung von fixen Objekten (Tabellendefinitionen etc) sprichst, dann kann man das zu einem gewissen Teil hin bekommen: Upgrades. Du könntest hier zB ein Script schreiben, was als Quelle eine korrekte/aktuelle Tabellenstruktur nimmt und damit existierende Strukture überprüft und ändert. Hast Du hier nur Upgrades (d.h. neue Spalten, keine Downgrades existierender Spalten wie Varchar(255) -> Varchar(32)), dann würde ich sagen das wäre sicher. Dieses Skript kann man dann genauso via Hooks ins VCS Deployment einbinden.
Damit hast Du aber noch lange keine Versionierung, sondern nur ein automatisiertes Upgrade. Nochmal klarer, wie das deine Daten zerstören würde, wenn Du es bei einem Downgrade nutzt:

* v1.1.1 -> Upgrade der Spalte "abc" von Varchar(32) -> Varchar(255)
* Speichern von mehrern Werten > 32 in "abc"
* Downgrade auf pre v1.1.1 -> Daten in "abc" werden abgeschnitten.
* Re-Upgrade auf v1.1.1 -> Daten bleiben 32 Char lang -> kaputt

Sicher kann man auch etwas mehr in der Mitte finden, indem man anwendungsspezifische Upgrade-Skripte nutzt (also in obigem Beispiel zB einen Downgrade-Converter der Inhalte von Varchar(255) auf Varchar(32) umwandelt und umgekehrt). Aber das ist auf jeden Fall fern ab von einer generalisierten Lösung, nach der hier, glaube ich, gefragt wurde.

Nach meinem Verständnis kannst Du eine wirkliche Versionierung wie auf Dateiebene mit GIT etc nicht wirklich erreichen - noch solltest Du es versuchen. Solange Laufzeitdaten Teil des Datenbestandes zur Versionierung sein sollen kann ich mir eigentlich nur Snapshots als Mittel zum Zweck vorstellen (oder eben die anwendungsspezifische Logik). Ich glaube es gibt kein revisions-fähiges RDBMS (korrigiert mich, wenn ich da falsch liege).

Hier noch ein interessanter Blogbeitrag (English, erstes Kommentar besonders interessant) zu dem Thema: http://www.robsearles.com/2009/10/11/thinking-about-database-revision-control/

Antworten
Evil

Und immer noch:

Wie sieht es mit einer Versionierung von SQL aus? :)
Für viele Webprjekte ist dies unabdingbar...

Gruss!

Antworten
SaaS-Secure.com

Sicher würden sehr viel mehr Entwickler SVN und Co nutzen, wäre die Installation nicht so umständlich. Google Code oder Sourceforge möchte man ja schließlich nicht immer alles anvertrauen was man so entwickelt.
Vielleicht sollten die Erfinder solcher Systeme einfach auch mal an die "Anwender" dabei denken.
Nicht jeder der programmieren kann ist gleich ein Virtuose auf der Linux Konsole.

Antworten
sec0nd

Änderungen sollen aber nur committed werden, wenn Sie als Gesamtheit Sinn machen!

Ich verstehe den Workflow mit dem Reposerver auf der Livekiste sowieso nicht. Normalerweise arbeitet man so (Produktivserver und Entwicklungskiste neben einem irgendwo existierenden Repository vorausgesetzt):

1. Update der Working Copy auf der Entwicklungskiste aus dem Repositoy
2. Entwickeln/Testen auf der Entwicklungskiste
3. wenn fertig -> sinnvoller Commit ins Repository
4. diesen Commit auf das Livesystem exportieren

So erzeugt man keine unnötigen Commits und produktiv befindet sich nur der letzte gesteste Commit.

Antworten
Frank Lämmer

@everyone: Danke fürs Feedback! Sehr interessant die Richtungen zu sehen, von "Ist doch eh Standard" bis "Oh oh, kompliziert".

@Florian Heyer: Unser Beispiel ist ein mögliches Szenario: exemplarisch und vereinfacht; KEINE Empfehlung. Viele andere Workflows sind natürlich auch denkbar.

Mit dem "Trial and Error" Commiten ist in der Tat ein Thema. Wenn ich Frontend Templates mache, kommen bei kleinen Änderungen oft schon ein paar Commits zusammen. CSS-Sachen schaue ich mir im Firebug an, so kann man viele kleine Sachen mit einmal fixen. Darüber hinaus haben wir einen Workflow, bei dem ich auch mal Änderungen per FTP einspielen kann, die ich dann vom Webserver zurück ins Repository synchronisieren kann.

Antworten
sec0nd

Gerade für Einzelentwickler ist auch das Vorhandenseins eines Backups unabhängig vom eigentlichen Backup interessant. Ich nutze SVN nun schon 3 Jahre und würde es nicht mehr missen wollen. Gerade bei Projekten, wo man mehr programmiert als denn CSS/Markup auszeichnet ist es super.

Für die Repos habe ich einen eigenen vServer auf einer meiner Blechbüchsen, auf den per https über das Webdav/SVN-Modul zugegriffen wird.

Antworten
Zac

"Versionsverwaltung wirkt für einige auf den ersten Blick sehr komplex, doch kann man mit wenigen Handgriffen die meisten täglichen Aufgaben ausführen."

Wirkt auf mich leider immer noch komplex... :-|

Antworten
robbz

Schöner Artikel. Ich hatte Versioncontrol zuletzt an der Uni mit Java unter Eclipse im Einsatz und weiß deshalb wie super das eigentlich ist... für Webentwicklung hab ich das bisher allerdings (auch in großen Projekten mit mehreren Teammitgliedern) noch nie verwendet. Da benutze ich immer einen DEV-Server, um das LiveSystem nicht zu verhuntzen.
Mir wäre zwar Versioncontroll auch viel lieber, aber die Einrichtung ... die Einrichtung... :-)

Antworten
Evil

Hi,

und hier wird wieder das grösste Problem aussen vor gelassen: Eine Versionierung von SQL Datenbanken. Die zwischenüberschrift lässt hier mehr vermuten...

Gruss!

Antworten
Florian Heyer

"Auf dem System, auf dem der Webserver läuft, befindet sich auch noch ein VCS-Server. Werden Änderungen in den VCS-Server eingespielt, aktualisiert dieser die (Website-)Daten des Webservers. Es sollte eine Rückspielmöglichkeit älterer Stände in den Webserver geben."

Diese Empfehlung ist aus meiner Sicht für normale Kundenprojekte aus zwei Gründen bedenklich:
- Sicherheit: warum soll das gesamte Repository auf einem öffentlich erreichbaren Server abgelegt sein? Dort sollten nur die für den Betrieb absolut notwendigen Dateien drauf sein. Falls der Server mal kompromittiert wird, ist nicht gleich das Repository kompromittiert.
- Committen um Änderungen auf den Webserver zu kopieren??? Das erzeugt bei Trial-And-Error-Programmierern hunderte von Commits ohne Inhalt.

Antworten
Someone

"Professionelle Programmierer greifen auf ihre Repositories natürlich per Shell zu." Professionelle Programmieren nutzen sicher auch keine Maus.

Antworten
Christian Aust

Ach herrje. Wann ist ein Projekt ein "kleineres", nur weil es von einem Entwickler betrieben wird?

Modernes Webdesign ist Programmierung, ohne wenn & aber. Wer mit HTML & CSS hantiert, mit Javascript-Frameworks plus Erweiterungen, mit Konfigurationen und Assets, mit PHP/Ruby/Python/C#-Frameworks und mindestens zwei Deployments (dev vs production), der kommt um Versionierung überhaupt nicht herum, wenn garantiert werden soll, dass überhaupt irgendein definierter Stand reproduzierbar sein soll. Und dabei rede ich noch gar nicht über Tests, die ohne Versionierung ebenfalls sinnlos sind.

Versionierung ist ein Mittel zur Erzeugung einer definierten Softwarequalität, das hat mit der Team- oder Projektgröße recht wenig zu tun. Wer darauf verzichtet, mutet seinem Kunden eine gewisse "hemdsärmelige Unsicherheit" zu. Grüße,

Christian

Antworten
marlan

"Traditionelle Webentwicklung vs Versionsverwaltung" passt irgendwie nicht, da es schon Versionsverwaltungssysteme vor dem www gab und diese vermutlich auch von Anfang an zum Einsatz gekommen sind.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.