Im letzten Artikel dieser Serie hatte ich darüber geschrieben, wie man als Entwickler von der produzierenden Industrie lernen kann. In diesem Artikel geht es um einen der Bausteine eines professionellen und geordneten Entwicklungsprozesses. Für den einen oder anderen wird das Thema keine Neuigkeit darstellen, aber leider trifft man in der Realität (sprich da wo der Pizzamann her kommt) nur zu oft auf das Gegenteil. Das hier ist zwar eher ein technischer Artikel, aber sicherlich auch interessant für unsere Betriebswirte; denn ob Kunde oder Manager, man kann sicherlich am Prozess abschätzen ob man auf einem professionellem Weg ist, oder ob es doch Richtung “Frickelbude” tendiert.

Der Prozess ist genauso wichtig wie das Produkt

Von der kleinen Anekdote lernen wir, dass zu mindestens der Entwicklungsprozess nicht optimal war. Entwicklung sollte nicht auf Produktivservern geschehen und Sourcecode sollte auch sicher verwahrt werden. Zu dem sollte die Übergabe des Programms aus der Entwicklung in den Produktivbetrieb in einem geordnetem Prozess erfolgen.

Die Entwicklung – nimm doch einfach den PC dahinten...

Wo bewahrt man Sourcecode auf?

Hier schafft ein neues Konzept Abhilfe: Die verteilte Versionsverwaltung, auch „Distributed Versioning Control System“ oder auch DVCS genannt. Populär in diesem Bereich sind die Systeme GIT und Mercurial, letzteres nutzen beispielsweise wir bei 42he. Hierbei hat jeder Entwickler auf seinem Rechner eine komplette Kopie, welche alle Versionen und alle Zweige des Codes enthält. Diese werden dann über einen zentralen Server oder Cloud-Dienst miteinander abgeglichen. Da hier im Gegensatz zu den alten Systemen das „Branching“, also das Abzweigen von Entwicklungslinien, wie auch das „Merging“, also das Zusammenführen optimiert worden ist, entstehen ganz neue Möglichkeiten in der Entwicklung.  So kann man zum Beispiel einen neuen Zweig in Version x abzweigen, um ein neues Feature zu entwickeln. In der Zwischenzeit können die Kollegen weiter am Hauptzweig arbeiten, um beispielsweise Fehler zu beheben. Dies Zweig kann dann auch weiterhin problemlos auf dem Server veröffentlicht werden. Wenn mein Feature fertig ist, kann ich dieses dann wieder zu der Version x+20 zusammenführen. Es entsteht dann die Version x+21. Das vereinfacht den Prozess und gibt Sicherheit.

Und wie kommt das System dann auf den Server, wenn nicht per FTP?

Nun haben wir also unser Produkt für die Produktion designed, haben eine passende Entwicklungsumgebung geschaffen und verwalten unsere Quelltexte vernünftig. Diese Maßnahmen alleine hätte die Wiederherstellung der Webseite aus unserer kleinen Geschichte vom Anfang innerhalb weniger Minuten möglich gemacht; und zwar zu jeder gewünschten Version des Programms, welche es je im Laufe der Entwicklung gegeben hat.

Im nächsten Teil widmen wir uns dann dem Ops Teil. Vom automatischen Einrichten und Einbinden vom Server in eine Farm bis zu dem automatischen Testing und Deployment sind dort einige spannende Technologien im Einsatz.