Seite 4: CI-Prozess + Fazit

Inhaltsverzeichnis

Continuous Integration als Prozess

Continuous Integration ist allerdings nicht mit der Installation und Konfiguration eines Produkts erledigt. Es muss Bestandteil des Prozesses und auch Teil der Entwicklungstätigkeit werden. Jeder im Unternehmen sollte schließlich wissen, wo er den aktuellen Stand und auch zurückliegende Stände der Softwareprodukte findet. Benachrichtigungen sollten so konfiguriert sein, dass ein Entwickler sofort erfährt, dass seine Änderungen zu einem Fehler geführt haben. Das gesamte Entwicklerteam muss in den Prozess integriert sein, damit Fehler schnell zu beheben sind. Nicht zuletzt sollte jeder Entwickler aufmerksam sein, ob Veränderungen an der Codebasis eine Anpassung des Continuous-Integration-Prozesses erfordern.

Vor allem muss jeder Programmierer wissen, warum es wichtig ist, einen defekten Build so schnell wie möglich zu reparieren. Dazu sollten die Entwickler von Anfang an bei der Einführung von Versionskontrolle und Continuous Integration beteiligt sein. Dadurch erreicht man ein tieferes Verständnis, was schließlich die Bereitschaft fördert, sich am Prozess aktiv zu beteiligen.

Continuous Deployment

Die bis hier aufgebaute Infrastruktur sorgt dafür, dass sich alle Softwareprojekte bei Änderungen komplett übersetzen und integrieren lassen. An letzter Stelle steht noch die automatisierte Installation der Produkte auf Testsysteme. Zum einen lässt sich damit Zeit für Handarbeit einsparen, zum anderen ist dadurch sichergestellt, dass die Testsysteme in einem definierten Zustand sind. Das erleichtert Softwaretestern einerseits die Arbeit, da es sie von Routineaufgaben befreit. Andererseits ermöglicht es ihnen, bei ihren Tests in einem definierten Zustand zu beginnen.

Auch der Vertrieb kann von Continuous Deployment profitieren. Denn nun verliert die Kundenpräsentation ihre Schrecken: Die Frage, ob die Entwickler es auch dieses Mal schaffen, ein lauffähiges Demosystem zu installieren, stellt sich nicht mehr, wenn der Prozess automatisiert ist.

Fazit

Die ersten Schritte beim Umgang mit einem Brownfield-Projekt sorgen dafür, eine reproduzierbare Umgebung zu schaffen und wiederkehrende Tätigkeiten zu automatisieren. Continuous Integration gibt eine sofortige Rückmeldung darüber, ob sich der aktuelle Stand des Projekts übersetzen und integrieren lässt. Fehlerträchtige und lästige Handarbeit wird reduziert. Das sind erforderliche Voraussetzungen für Eingriffe in den Quellcode.

Die Einführung von Versionskontrolle und Continuous Integration spannt ein Sicherheitsnetz auf, das die eingangs geschilderten Ängste unbegründet erscheinen lässt. Doch bevor Entwickler den Code modifizieren, sollten Projekte das Sicherheitsnetz noch um automatisierte Tests erweitern. Sie geben dem Entwickler die Gewissheit, dass er durch seine Änderungen nichts zerstört hat. Um das automatisierte Testen im Kontext von Brownfield-Projekten geht es im nächsten Teil der Serie.

Stefan Lieser
ist freiberuflicher Berater/Trainer/Autor aus Leidenschaft. Seine Schwerpunkte liegen im Bereich Clean Code Developer sowie Domain Driven Design.

Ralf Westphal
ist Microsoft MVP für Softwarearchitektur und freiberuflicher Berater, Projektbegleiter und Trainer für Themen rund um .NET-Softwarearchitekturen

Literaturhinweise

Versionskontrolle

• Steve Berczuk, Brad Appleton;, Software Configuration Management Patterns; Addison-Wesley, 2002
• Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf, 2006
• Travis Swicegood; Pragmatic Version Control Using Git; Pragmatic Bookshelf, 2008

Continuous Integration

• Paul M. Duvall, Steve Matyas, Andrew Glover; Continuous Integration: Improving Software Quality and Reducing Risk; Addison-Wesley, 2007

(ane)