Eine Einführung in Continuous Delivery, Teil 2: Commit Stage

Inhaltsverzeichnis

Mit Continuous Delivery erhalten Entwicklungsteams jederzeit einen Überblick über die Qualität der Software. Erfüllt der aktuelle Softwarestand die funktionalen und nichtfunktionalen Anforderungen, kann dieser innerhalb kurzer Zeit in Produktion gehen. Doch wie sehen die konkreten Schritte hin zu einer Continuous Delivery Pipeline aus?

Eine Continuous Delivery Pipeline besteht aus mehreren miteinander verketteten Teststufen, die mit automatisierten Tests die Qualität des aktuellen Softwarestandes überprüfen. Die erste dieser Stufen ist die sogenannte Commit Stage, in der die Software gebaut und ihre Funktionen mit Unit-Tests überprüft werden.

Mehr Infos

Eine Einführung in Continuous Delivery

• Teil 1: Grundlagen
• Teil 2: Commit Stage
• Teil 3: Acceptance Test Stage
  

In der anschließenden Acceptance Test Stage untersucht man weitergehende Anforderungen an die Software mit Integrations-, Akzeptanz- und Systemtests. Um von den Tests aufgedeckte Regressionen exakt einer einzelnen Änderung zuordnen zu können, löst man die Continuous Devlivery Pipeline direkt nach jeder Änderung am Sourcecode aus und generiert so zeitnah und kontinuierlich Feedback für die Entwickler. Schlägt eine der Teststufen fehl, wird der weitere Durchlauf dieses Softwarestandes durch die Pipeline abgebrochen. Kann der Softwarestand hingegen alle Teststufen erfolgreich passieren, steht einer Installation in der Produktion grundsätzlich nichts mehr im Wege.

In diesem Artikel beschreiben die Autoren den Aufbau der ersten Teststufe, der Commit Stage. Ihr Ziel ist es, eine erste Qualitätskontrolle mit Unit-Tests durchzuführen und im Erfolgsfall die Binärartefakte aller Softwarekomponenten zu einem sogenannten Bundle zusammenzuschnüren. Dieses Bundle wird in den weiteren Teststufen auf einer Testumgebung installiert und für das Ausführen der Tests benutzt. Bei Erfolg kann man exakt das gleiche Bundle, das die automatisierten Tests erfolgreich durchlaufen hat, unverändert auf dem Produktionssystem installieren. Dafür speichert man die in der Commit Stage erzeugten Bundles in einem Repository, um sie von dort aus wiederzuverwenden.

Insgesamt führt die Commit Stage die folgenden Aufgaben aus:

• Build (kompilieren, falls nötig)
• Ausführen der Unit-Tests
• Paketierung und Bündlung der Artefakte
• Upload des Bundles ins Binärartefakt-Repository
• Erzeugen von Feedback über mögliche Regressionen für die Entwickler

Dabei liegen diesen Aufgaben zwei wichtige Prinzipien zugrunde:

• Jeder Softwarestand wird innerhalb der Pipeline nur ein einziges Mal gebaut – nämlich genau hier in der Commit Stage.
• Jede erfolgreiche Commit Stage produziert ein Software-Bundle – einen installierbaren Release-Kandidaten.

Was ist aber zu tun, um eine solche Commit Stage für eine Continuous Delivery Pipeline aufzubauen? Um ein erstes Gefühl für die dazu notwendigen Schritte zu entwickeln, soll diese Aufgabe für ein einfaches Beispielprojekt in einer vorbereiteten virtuellen Maschine nachvollzogen werden. Dazu ziehen die Autoren ein einfaches Beispielprojekt heran, das zeigt, wie man hierfür die Commit Stage einer Continuous Delivery Pipeline aufbaut.

Als Beispielprojekt kommt eine kleine Java-EE-Webanwendung ("MusicDB") zum Einsatz, die gerade einmal genug Features enthält, um vielleicht einen einfachen Oberflächentest damit auszuführen. Die Software ist als ein einfaches Maven-Projekt angelegt und lässt sich im Tomcat ausführen.

Für die Umsetzung der obigen Aufgaben der Commit Stage setzen Softwareprojekte üblicherweise einen Build- oder CI-Server (Continuous Integration) ein. Im Beispiel kommt dafür Jenkins zum Einsatz, allerdings lassen sich die Aufgaben auch mit anderen Produkten (etwa Bamboo und Teamcity) in ähnlicher Weise umsetzen. Der Einfachheit halber sind alle sonst auf mehrere Rechner verteilten Komponenten der Continuous Delivery Pipeline in der bereitgestellten virtuellen Maschine vereint. Dort findet sich zum einen das Entwicklungssystem mit einem installierten Eclipse, zum anderen dient die gleiche Maschine als zentrales Versionskontrollsystem (VCS) und als Build-Server.

Nach dem Start der VM liegt der Sourcecode in Eclipse bereit. Der Zugriff auf die laufende Anwendung im lokalen Tomcat, auf das VCS und den installierten Jenkins-Server kann einfach über die Links auf der Startseite des Browsers geschehen.