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

Leider sind zu oft Kunden, aber auch Startups nur am Produkt interessiert, aber nicht am Prozess. Folgende kleine Geschichte soll Zeigen, dass aber auch dieser erfolgskritisch ist. Vor ein paar Jahren hatte ich bei einem Kunden mit einem „Webdesigner“ zu tun. Dieser sollte für ein Typo3 mehrere Plugins nach Kundenwunsch entwickeln. Zunächst wollte besagter entwickler einen unverschlüsselten FTP Zugang zu dem Server haben, er bestand sogar hartnäckig darauf. Erst ein Hinweis auf die Grundschutzkataloge des BSI beendete die Diskussion, da unverschlüsselt im offenen Internet definitiv pfui ist.  Aber auch der verschlüsselte Zugang zum Server änderte nichts daran, das nicht lokal entwickelt und getestet wurde -sondern schön auf dem Produktivserver im laufenden Betrieb. Da der IT Abteilung des Unternehmens nie mitgeteilt wurde, das der Server nicht mehr im Testbetrieb war, sondern schon produktiv genutzt wurde, wurde versäumt, das System in das Backup aufzunehmen. Es kam, wie es kommen musste: Der Server hatte einen Festplattendefekt und die Daten waren weg. Sie können sich wahrscheinlich schon denken, wie die kleine Geschichte weitergeht. Es sollte ja ein Leichtes sein, auf den bereit gestellten Ersatzserver das Typo3 und die Plugins einfach neu zu installieren. Ist es normalerweise auch, nur der „Entwickler“ hatte leider keine lokalen Kopien seiner Plugins, da er ja auf seinem Windows XP keinen passenden Webserver hatte und quasi nur auf dem Produktivserver entwickelt hatte. Das Ende vom Lied? Die Plugins und die Webseite mussten dann aufwändig und vollständig von vorne entwickelt werden.

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...

Leider arbeiten in diesem Bereich viele Leute mit dem falschen Werkzeug. Man sollte generell in der Lage sein, auf einer der Zielplattform möglichst ähnlichen Umgebung zu arbeiten. In unserem ersten Beispiel war die Zielplattform Linux mit Apache2 als Webserver und MySQL als Datenbank. Sicherlich kann man für diese Plattform auch unter Windows XP entwickeln, aber es gibt schon Unterschiede, z.B. was das Dateisystem angeht. Hier ist es also deutlich besser auch selbst auf einem unixoiden System zu arbeiten. So kann man viel besser das Produkt testen, ohne das es nötig ist dieses jedes mal in das Zielsystem laden zu müssen. Natürlich ist es einfacher das System zu nehmen, welches man schon kennt oder welches das Unternehmen standardmäßig einsetzt, aus meiner Sicht ist es aber falsche Bequemlichkeit bzw. falscher Geiz. Die Standardumgebung in Betrieben ist oft für den normalen Geschäftsbetrieb, aber nicht die Entwicklung ausgelegt. Hier lohnt es sich also auf jeden Fall, zuerst über die spätere Zielplattform nachzudenken und dem entsprechend seine Entwicklungsumgebung einzurichten.

Wo bewahrt man Sourcecode auf?

Man glaubt auch nicht, welche Antworten man auf diese Frage bekommt: Von Festplatte über Netzlaufwerk bis zu USB Stick (damit man ihn immer dabei hat) habe ich alles schon gehört. Und alles ist falsch. Quelltexte gehören in eine Sourcecodeverwaltung und sonst nirgendwo hin. Hier gibt es mehrere unterschiedliche Ansätze und Systeme. Ältere Systeme wie CVS oder SVN speichern hierbei den Quelltext versioniert zentral auf einem Server. Die Entwickler checken den Code aus, bearbeiten ihn und checken ihn wieder ein. Durch die Versionierung kann man die Änderungen nachvollziehen. Leider hat dieser Ansatz das Problem, dass es sehr kompliziert ist mehr als ein Entwicklungszweig zu haben. Alle Entwickler arbeiten an diesem, und er ist die Wahrheit. Daher werden kleine, halbfertige oder ungetestet Änderungen oft nicht eingecheckt, weil im Idealfall die aktuelle Version auf dem Server lauffähig sein sollte.

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?

Dateien hochladen ist so 1995. Das Stichwort ist hier das so genannte „Deployment“. Hierbei wird eine Version getestet, auf die Produktivserver geladen, Anpassung an diesen vorgenommen und erst dann wird von der laufenden auf die neue Version umgestellt. Der gesamte Prozess geht so schnell, das man es sogar bei größeren Serverfarmen im laufenden Betrieb bewerkstelligen kann ohne dass der laufende Betrieb beeinträchtigt wird. Best Practices und Werkzeuge hierzu werden wir in den nächsten Artikeln dieser Serie vorstellen.

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.