© svetabelaya/Shutterstock.com
Erfolgreich Softwareprojekte modernisieren – Teil 2

Einführung einer Build Pipeline


Der vorangegangene Artikel der Serie befasste sich mit dem Faktor Mensch. Neben der dort angesprochenen Modernisierung von innen heraus müssen sich die Entwicklerinnen zwangsläufig mit der Software in der Form befassen, in der sie gerade vorliegt. Fehler müssen behoben, Funktionalitäten umgesetzt und die Software ihren Benutzerinnen zur Verfügung gestellt werden.

Dass Menschen Fehler unterlaufen, ist normal. Und so ist es auch bei der Entwicklung von Software unvermeidbar, dass beim Beheben von Fehlern und der Umsetzung neuer Funktionalitäten neue Fehler eingeführt werden.

Fehler früh erkennen und beseitigen

Die Fehler gehen mit Kosten einher, die umso höher sind, je später sie entdeckt werden. Erreicht fehlerhafte Software ein Produktivsystem, führt sie dort nicht unbedingt zu einem schnell erkannten und teuren Komplettausfall. Viele Fehler werden oft nur dann entdeckt, wenn Logging, Monitoring oder ebenso mitteilsame wie aufmerksame Benutzerinnen der Software darauf hinweisen. Andere Fehler bleiben wiederum komplett unbemerkt und schlagen sich allenfalls in einer geringen wirtschaftlichen Leistung des Softwareprojekts nieder, die mithin als normal angesehen wird.

Je weniger Informationen zu einem Fehler zur Verfügung stehen, desto schwieriger wird es sein, diese Fehler zu reproduzieren. Entsprechend aufwendig gestaltet sich dann die Ursachenfindung und -behebung.

Um über die gesamte Lebensdauer eines Softwareprojekts wirtschaftlich arbeiten zu können, muss das Ziel also sein, Fehler so früh wie möglich zu erkennen, um sie dann so schnell wie möglich beseitigen zu können. Im Idealfall werden Fehler bemerkt und beseitigt, bevor sie in ein Produktivsystem übertragen werden.

Sinnvoll ist es daher, die Software in mehreren ineinander verschachtelten Feedbackschleifen zu entwickeln (Abb. 1)

moeller_modernisierung_2_1.tif_fmt1.jpgAbb. 1: Verschachtelte Feedbackschleifen

Hierbei durchläuft die Software verschiedene Entwicklungsumgebungen. Werden in einer Umgebung Fehler an der Software festgestellt, müssen sie von den Entwicklerinnen behoben werden, bevor die Software in die nächste Umgebung und schließlich in Produktivsysteme übertragen wird.

Entwicklungsumgebungen

Als „develop“ (oder „dev“) wird hierbei die projektspezifische, lokale Entwicklungsumgebung auf dem Computer einer Entwicklerin bezeichnet. Diese Umgebung sollte durch Ausführen einiger weniger Befehle jederzeit eingerichtet und hochgefahren werden können. Im Zweifel sollte diese Umgebung auch funktionsfähig sein, wenn die Entwicklerin gerade keine Internetverbindung hat. Die Lebensdauer dieser Entwicklungsumgebung endet, wenn eine Entwicklerin die Arbeit an diesem Projekt unterbricht oder beendet.

Als „testing“ wird eine isolierte Umgebung bezeichnet, auf der Software automatisierten Tests ausgesetzt wird. Diese Umgebung muss automatisiert eingerichtet werden. Die Einrichtung kann ausgelöst werden, wenn eine Entwicklerin Änderungen von ihrer lokalen Entwicklungsumgebung zu einem Versionskontrollsystem wie Bitbucket, GitHub oder GitLab überträgt. Pusht sie Commits in eine Branch oder öffnet auf diesem Versionskontrollsystem einen Pull Request, wird hier die Testumgebung eingerichtet und die Güte der vorgenommenen Änderungen geprüft. Darüber hinaus kann eine Testumgebung auch automatisiert über Schedules eingerichtet werden, damit der Status eines Softwareprojekts in regelmäßigen Abständen geprüft werden. Die Lebensdauer dieser Umgebung endet, wenn die Software die automatisierten Tests durchlaufen hat oder die Ausführung gescheitert ist.

Als „staging“ wird eine einer Produktivumgebung weitestgehend nachempfundene Umgebung bezeichnet. In dieser Umgebung kann Software mit realen Daten (zum Beispiel einer veralteten Kopie von Livedaten) manuell und teilautomatisiert getestet und abgenommen werden. Im Unterschied zur Produktivumgebung wird die Software in diesen Systemen so konfiguriert, dass sie nicht mit externen Produktivsystemen kommuniziert. Bei solchen Tests sollte es vermieden werden,...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang