Fortlaufende Entwicklung, jederzeit!

Fortlaufende Entwicklung (engl. Continious Integration) beschreibt einen Prozess, der in der Software Entwicklung Anwendung findet. Dieser Prozess sieht vor, nach Erstellung oder Änderung des Quellcodes einen definierten Ablauf anzustossen. Bestandteil dieses Prozesses ist es, einen Entwicklungsserver mit der neuen Version der Software zu versorgen, damit auf diesem der jeweils aktuelle Stand der Entwicklung eingesehen werden kann.

Deployment

Ein wichtiges Schlagwort in diesem Zusammenhang ist Deployment. Es beschreibt den automatischen Vorgang der ablaufen muss, damit diese sogenannte Integrationsumgebung den jeweils aktuellen Stand der Software erhält. Ein gut funktionierendes Deployment ist in der Lage sich an die Gegebenheiten des Servers anzupassen und übernimmt nicht nur das Übertragen der Sourcecodes sondern setzt auch Ordnerrechte, aktualisiert die Datenbank auf das aktuellste Schema und setzt innerhalb der Anwendung noch Schalter, die das System für diese Umgebung einstellen.

Unit-Tests

Das Durchführen automatisierter Unit-Tests stellt sicher, dass die Software bestimmten Qualitätsanforderungen gerecht wird. Dadurch lässt sich leicht und auch als automatische Entscheidung erkennen, ob eine Software deploy-fähig ist. Nur wenn eine deploy-fähige Version versorgt wurde, ist es möglich einen weiteren Schritt einzuleiten. Dieser Schritt wird Release genannt. Dazu müssen wieder Versorgungen stattfinden, diesmal jedoch auf eine weitere Umgebung. Dies könnte im einfachsten Fall direkt die Produktiv Umgebung sein. In einer erweiterten Version wäre das eine Vor-Prod genannte Umgebung. Diese hat eine größtmögliche Ähnlichkeit mit dem Produktivsystem. Dadurch fallen Unterschiede in Datenbankversionen, Serversoftware oder anderen Umgebungsspezifischen Variablen möglichst vorm Release auf.

Release

Nach erfolgtem Release sollte die Softwareversion speziell gekennzeichnet werden, damit sich später jederzeit rekonstruieren lassen, welcher Stand wann in Produktion gelaufen ist. Dies gewährleistet eine Sicherheit in der Fehlersuche bei Produktivfehlern. Außerdem erleichtet es die Einbindung externer Tester oder Entwickler. Dies wird zumeist durch sogenannte Tags im Subversion oder einer anderen Versionsverwaltung erreicht. Das bedeutet, das der Stand, der zur Versorgung benutzt wurde speziell gekennzeichnet wird und jederzeit leicht wieder zu beziehen ist.

Stage- und Deploy-Management

Damit ein solcher Prozess eingehalten werden kann, ist es nötig eine Oberfläche zur Steuerung der unterschiedlichen Installationen zu haben. Im Fachjargon heissen solche Installationen Stage. Eine Verwaltungsoberfläche für mehrere Stages ist zumeist für jedes Projekt mit anderen Anforderungen konfrontiert. Eine Individuallösung empfiehlt sich in fast jedem Fall. Zumeist lässt sich ein einmal entwickeltes System für weitere Projekte unter Berücksichtigung individueller Eigenheiten weiterverwenden.

Rollback

Der Mehraufwand zur Entwicklung einer solchen Plattform rechtfertigt sich auch durch die erreichte Stabilität und Qualität des Versorgungsprozesses. Sollte einmal etwas schief gelaufen sein oder ein Fehler gefunden werden ist der Ablauf zur Fehlerbehebung klar. Dazu sollte es möglich sein, die Produktivumgebung mit einer älteren Softwareversion zu versorgen um einen eventuell neuen Fehler kurzfristig wieder los zu werden.

Prozessgedanke

Durch die Gedanken, die sich ein Entwickler beim Erstellen einer solchen Software macht, stellt er auch sicher, dass er alle Schritte zur Versorgung bedacht hat und beim Deployment einhält. Insbesondere sind hiervon Datenbankänderungen betroffen, die häufig zu Fehlern führen, weil sie nicht konsequent bis ins Produktivsystem durchgereicht werden. Dies fällt bei einer automatischen Versorgung über mehrere Stages bereits vorm Produktiv-Release auf.

Fazit

Insgesamt gewährleistet der gesamte Prozess Sicherheit, Stabilität und ein anderes Bewusstsein der Entwicklung. Fortlaufend, versteht sich.