Continuous Delivery mit QA-Pipelines

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Continuous Delivery (CD) bezeichnet eine Sammlung von Techniken, Prozessen und Werkzeugen, die den Softwarelieferprozess verbessern. Techniken wie Testautomatisierung, kontinuierliche Integration (Continuous Integration) und kontinuierliche Installation erlauben die Entwicklung qualitativ hochwertiger Software, die durch automatisierte Release-Erstellung auf Entwicklungs-, Test-, Integrations- und Produktivumgebung eingespielt werden kann. Die Automatisierung der Test- und Lieferprozesse ermöglicht es, schnell, zuverlässig und wiederholbar zu liefern und Erweiterungen und Fehlerkorrekturen mit geringem Risiko und niedrigem manuellem Aufwand in die Produktivumgebung oder zum Kunden zu bringen. Continuous Delivery wird primär in der Agilen Softwareentwicklung eingesetzt. Eine Einführung von Continuous Delivery erfordert eine Umsetzung von DevOps.

Deployment Pipeline

Stages einer Continuous Deployment Pipeline

Ein zentraler Begriff des CD ist die Deployment Pipeline[1] als Lean Poka Yoke: eine Menge von Validierungen, die eine Software auf ihrem Weg vom Check-in des Codes bis zur Veröffentlichung bestehen muss. Dabei wird von den folgenden Stages[2] einer Deployment Pipeline gesprochen, durch die jede Code-Änderung in der Versionsverwaltung durchlaufen muss und geprüft wird:

  • In der Commit Stage wird sichergestellt, dass das System auf technischem Level funktioniert. Falls nötig, wird dazu der Programmcode mit einem Buildserver (beispielsweise Apache Ant oder Apache Maven) kompiliert und paketiert. Anschließend wird die Software mit automatisierten (Modul-)Tests auf technische einwandfreie Funktionalität geprüft und der Code einer statischen Codeanalyse (beispielsweise mit SonarQube zur Qualitätssicherung unterzogen. Mit einem Tool zur kontinuierlichen Integration (z.B.: Jenkins oder Travis CI) lässt sich der Prozess der Commit Stage überwachen und orchestrieren.
  • In der Automatisierte Tests Stage wird die Software mit Akzeptanz- und Performancetests auf einem funktionalen und nicht-funktionalen Level geprüft. Dabei wird untersucht, ob sich die Software so verhält, wie es der Nutzer erwartet und ob die Spezifikationen des Kunden erfüllt werden. Außerdem werden Messungen zur Untersuchung der Codequalität durchgeführt um die Qualität des Codes zu sichern. Dies kann mit eigens geschrieben Analysen oder mit einem Werkzeug zur Codeanalyse wie SonarQube durchgeführt werden.
  • Durch manuelle Tests wie User Accecptance Tests oder exploratorische Tests wird in der Manuellen Test Stage sichergestellt, dass Fehler, die durch automatisierte Tests nicht entdeckt worden sind, behoben werden können, bevor die Software ausgeliefert wird.
  • Konnten alle vorherigen Stages positiv durchlaufen werden so wird in der Release Stage die Software in der Produktionsumgebung den Benutzer ausgeliefert.

Je nach Projekt und Anforderungen werden die einzelnen Stages und Schritte variieren. Die Deployment-Pipeline sollte mit den Anforderungen an das Projekt wachsen und sich entsprechend mit entwickeln.[1]

Vorteile

Mehrere Vorteile durch den Einsatz von Continuous Delivery in einem agilen Entwicklungsprozess sind gegenüber einem klassischen Softwareentwicklung- und Testing-Prozess bekannt:[3]

  • Beschleunigung der Release-Zyklen: Automatisiertes Testing und Deployment verkürzt die Zeit von der Entwicklung zum Release
  • Entwicklung des richtigen Produkts: Eng definierte Sprints und kürzere Zyklen sorgen dafür, dass die Entwickler direkteres Feedback zu gut definierbaren Features vom Produkt-Testern und dem Kunden bekommen
  • Verbesserte Produktivität und Effizienz: Enorme Zeiteinsparung für Entwickler, Tester etc. durch automatisierte CD Pipeline
  • Verlässlichere Releases: Automatisierte Tests und Sicherheitsmechanismen der CD Pipeline senken die Fehlerquote in einem Release
  • Verbesserte Produkt-Qualität: Direktes Feedback an den Entwickler durch die Tools der Pipeline bei fehlerhaften Commits sorgt für eine bessere Software- und Produkt-Qualität
  • Gesteigerte Kundenzufriedenheit: Kurze Release-Zyklen und direktere Ergebnisse für den Kunden sorgen für gesteigertes Vertrauen und Zufriedenheit

Herausforderungen

Neben vielen Vorteilen für Entwickler, Vertrieb etc. bringt der Einsatz einer CD Pipeline einige Herausforderungen mit sich:[3]

  • Da die meisten Projekte sehr bestimmte Anforderungen haben, muss oft eine angepasste Pipeline entwickelt werden. Die Einrichtung kann sehr aufwändig sein, bisher sind wenige betriebsfertige Lösungen am Markt.
  • Entwickler, die zu einem CD-Prozess wechseln und lange Veröffentlichungszyklen gewohnt sind, müssen ihre Entwicklungstechniken anpassen.
  • Jede Version in der Versionsverwaltung soll zu jeder Zeit lieferbar sein. Entwicklungsmuster wie Featuretoggles helfen dabei, Code früh zu versionieren, auch wenn er noch nicht zur Verwendung durch den Endanwender gedacht ist. Andere Techniken wie Branching werden nicht überflüssig, müssen jedoch an den Prozess angepasst werden.

Quality Assurance

Eines der Hauptziele beim Einsatz von CD ist die Qualitätssicherung (QS) (vgl. engl. Quality Assurance (QA)) und die Steigerung der allgemeinen Qualität des Produkts. Die Steigerung der Qualität des Codes und des Produkts wird in einer CD-Pipeline durch die Kombination bewährter Arbeitsweisen [4] erreicht:

Continuous Integration

Continuous Integraftion [5] (CI) (dt. Kontinuierliche Integration) wird in der Commit Stage durchgeführt und bezieht sich auf die Arbeitsweise des Entwicklers, stets die folgenden Schritte durchzuführen um Fehler und Konflikte zu vermeiden:

  1. Aktuellen Stand des Repositories klonen
  2. Codeänderungen durchführen
  3. Lokal Build und Tests durchführen
  4. Code lokal updaten
  5. Lokal erneut Build und Tests durchführen
  6. Code commiten und dem Repository zuführen
  7. Build und automatisierte Tests auf CI Server durchführen

Die Codequalität kann durch die Arbeitsweise nach CI direkt verbessert werden, da in kurzen Zyklen gearbeitet und frühzeitig getestet wird. Bugs und Konflikte werden früher erkannt und können direkt behoben werden. Durch einen CI Server ist gewährleistet, das es nicht zu Problemen aufgrund unterschiedlicher Entwicklungsumgebungen kommt.

Continuous Measurement

Zur Überprüfung und Verbesserung des Codes werden in einer CD-Pipeline kontinuierliche Messungen (eng. Continuous Measurement) und Analysen durchgeführt. Die Codeanalysen laufen automatisiert in der Automatisierte Tests Stage ab. Grenzwerte für die unterschiedlichen Codeanalysen stellen sicher, das bei Überschreitungen die Entwickler darauf hingewiesen werden und die eventuell Pipeline abbricht. Welche Code-Analysen durchgeführt ist abhängig von Programmiersprache und Anforderungen. Für eine Java-Anwendungen könnten beispielsweise Test auf Lines-of-Code basieren, Statische Code-Analysen durchgeführt und die Komplexität des Codes geprüft werden. Außerdem ist es sinnvoll auf sogenannte Code-Smells zu prüfen.

Durch die automatisierte und kontinuierliche Analyse des Codes kann überprüft werden, ob sich bestimmte Werte im Laufe der Entwicklung einer Software verbessern oder verschlechtern.

Continuous Improvement

Damit die vorigen Schritte zur Qualitätssicherung diese steigern, sollte der Ansatz des Continuous Improvement, also der kontinuierlichen Verbesserung, im Workflow und in der Pipeline integriert werden. Um eine kontinuierliche Verbesserung des Produkts zu erreichen, werden die Metriken der Code-Analyse und die Ergebnisse der automatisierten Builds und Tests ausgewertet. In itterativen Schleifen kann der gesamte Prozess beginnend mit Code-Änderungen optimiert werden um Code-Smells und andere Fehler durch beispielsweise Refactoring zu beheben.

Ein Qualitäts-Manager überwacht die Prozesse und greift gegebenenfalls ein. Ist kein Qualitäts-Manager vorhanden, verinnerlichen alle Beteiligten der CD-Pipeline und des Produkts den Ansatz des Continuous Improvement um gemeinsam die Qualität zu steigern.

CD Pipeline am Beispiel ARSnova

ARSnova ist ein Abstimmungssystem, das erlaubt, Informationen interaktiv zu sammeln. Ein Vortragender kann mithilfe von ARSnova mit seinem Publikum besser interagieren. Das Publikum kann zu einem Thema anonym abstimmen und Fragen beantwortet. ARS steht für Audience Response System und Nova für die Explosion von Sternen und beschreibt dadurch die Wahlmenge, die ein User durch die Benutzung des Systems haben kann.

Zur Verbesserung und Optimierung von ARSnova, ist eine kontinuerliche Integration (CD continuous deployment) durchzuführen. Dadurch werden die Entwickler die Möglichkeit haben, zu innovieren, zu verbessern sowie Bugs zu fixen und in Bezug auf die Zielgruppe die Funktionalitäten des Systems anzupassen, um die Anforderungen zu erfüllen und die allgemeine Qualität des Produktes zu steigern. ARSnova wird mit dem JavaScript Framework Sencha Touch 2 im Frontend und mit der objektorientierte Programmiersprache Java Technologies im Backend entwickelt.

Tools

Vagrant

Vagrant ist eine frei verfügbare Open Source Technologie zur Erstellung, Entwicklung, Verwaltung und Einrichtung von virtuellen Umgebungen auf Basis von virtuellen Maschinen. Als Virtualisierungslösung kann Oracle's freie Lösung Virtualbox verwendet werden und die Systemkonfigurationstools Chef und/oder puppet. Die Konfiguration der virtuellen Maschine ist in einem Vagrantfile hinterlegt.

Umgebung & Setup

Zur Weiterentwicklung von ARSnova muss zuerst die aktuelle Version von Vagrant installiert werden. Diese kann durch das Herunterladen von der offiziellen Webseite und durch Ausführung des Vagrant setup auf dem eigenem Rechner erfolgen. Ebenso wird Virtualbox benötigt, um ARSnova lokal aufsetzen zu können.

ARSnova wird als Vagrant-Konfiguration im GitLab der THM zur Verfügung gestellt und muss auf dem lokal geklont werden.

Vagrant wird per Kommandozeile gestartet:

$ vagrant up

Der Initialisierungsprozess dauert beim ersten Starten der virtuellen Maschine recht lange, da zunächst alle Abhängigkeiten heruntergeladen werden müssen. Dabei wird die neue virtuelle Maschine vollständig eingerichtet und alle Services gestartet. Eine detailierte Anleitung zur bereitsgestellten Vagrant-Box für ARSnova findet sich im GitLab-Repository

Relevante Projektteile sollten geforkt und die Einrichtung eines neuen Branches zur Weiterentwicklung des entsprechenden Projekts in GitLab THM-Gießen erfolgen. Die vorgelegten Spezifikationen zur Weiterentwicklung des ARSnova-Projekts können mit verschiedenen Entwicklungswerkzeugen implementiert werden, nämlich mit Eclipse, Webstorm als auch Intellij usw.

Jenkins

Jenkins bezeichnet sich als ein webbasiertes erweiterbares Open Source Projekt zur kontinuierlichen Integration von Komponenten in einem Anwendungsprogramm. Jenkins wurde in Java entwickelt und ist plattformunabhängig. Zahlreiche Entwicklungstools werden dabei unterstützt (Git, JUnit etc.). Jenkins ist für alle Betriebsysteme verfügbar und unterstützt die ständige Integration aller Teile eines Softwareprojektes, und stellt die Qualität und Lauffähigkeit des Projekts sicher.

Installation und Setup

Die Installation von Jenkins ist für die Weiterentwicklung an ARSnova nicht notwendig, da es auf dem virtuellen Server bereit eingerichtet ist. Diese kann unter http://localhost:8080 auf eigenem Rechner zugegriffen werden und steht als Services zur Verfügung. Weiterhin muss Git bereits lokal vorhanden sein. Um Jenkins einzusetzten, muss zuerst ein neuer Job angelegt werden. Dies ist unter dem Hauptmenü als "Neuen Job anlegen" zu finden.

Der Pfad zum Git Repository muss dem neuen Jenkins-Job mitgeteilt werden. Jenkins ist so zu konfigurienen, dass es nach einem bestimmten Zeitraum oder nach einem bestimmten Ereignis (Commit) ein Build Prozess gestartet wird. Dies ist mithilfe von bestimmten Befehlen durchzuführen.

Für mehr Informationen stehen die folgenden Tutorials zur Verfügung:

SonarQube

SonarQube ist ein Werkzeug zur statischen Code-Analyse. Es untersucht Quellcode im Hinblick auf unterschiedliche Qualitätsparameter. Die Analysen umfassen unter anderem die folgenden Aspekte:

Dabei greift SonarQube auf bewährte Werkzeuge wie PMD, Checkstyle, Findbugs, Surefire und Cobertura zurück. Das Tool unterstützt neben Java (durch Plugins) auch weitere Sprachen wie z.B. Groovy, Flex, PHP, PL/SQL, C#, Cobol, .Net, Erlang und Visual Basic 6. Darüber hinaus ist SonarQube über eine Plugin-API erweiterbar. (Bestehende Plugins können über die Plugin Library eingesehen werden.)

Weitere Informationen sind in Code-Qualität optimieren mit SonarQube zu finden.

Integration in den Workflow und Prozess-Ablauf

Konfiguration

Um Jenkins für den ersten Start bereit zu machen, sind nur wenige Einstellungen vorzunehmen.

Jenkins mainmenu.PNG

Dazu geht man im Hauptmenu auf Jenkins verwalten.

Jenkins configure.PNG

Anschließend klickt man auf System konfigurieren, um die Einstellungen für das JDK sowie Ant bzw. Maven vorzunehmen.

Jenkins jdk.PNG

Das JDK kann entweder per lokalen Pfad durch Setzen der JAVA_HOME Variable hinzugefügt werden oder man kann eine beliebige Version per Dropdown auswählen und diese automatisch über das Internet installieren lassen.

Jenkins maven.PNG

Die Konfiguration von Maven ist ähnlich einfach. Es wird die gewünschte Version von Maven ausgewählt und im Anschluss automatisch heruntergeladen und entpackt.

Prozess-Ablauf

Als erstes wird für das ARSnova Projekt ein neuer Job erstellt. Ein Job ist nichts anderes als eine Aufgabe die Jenkins zu erledigen hat. Dies kann nur das Kompilieren des Source Codes sein oder aber das Durchführen von Tests, Erstellung von technischer Dokumentation (z. B. Javadoc). In der Regel findet man in einem Projekt verschiedene Jobs, die aber abhängig sind (z. B. Deployment Job findet erst nach erfolgreichem Testen statt).

Im Anschluss wird ein passender Name gewählt. Ebenfalls wählt man aus, um was es sich handelt. In diesem Beispiel ein Maven Projekt. Jenkins erstellt für jeden Job einen Ordner im Workspace. Der Workspace ist zu finden unter der Jenkins Installation im Ordner workspace. Wenn man auf ein CVS System verzichtet muss man die Projektdateien (Source Code) im Workspace in den entsprechenden Job kopieren bzw. einfügen. Da der Source Code bei diesem Beispiel auf einem Git Server liegt wählen wir git und geben die entsprechende Repository URL ein. Wenn eine Authentifizierung benötigt wird, wird man darauf hingewiesen und man kann die Benutzerdaten eingeben.

Nun ist es noch notwendig, den Pfad zu der POM Datei (POM - Projekt Object Model) anzugeben. Die meist pom.xml benannte Datei beinhaltet die Konfiguration des Projekts. Ebenso muss ein Goal bestimmt werden. Goals (Pendant zu Target in Ant) sind Kommandos von Maven Plugins oder auch beschrieben in der pom.xml Datei. pom.xml Einstellung und Goals Zu sehen ist das Hauptmenu eines Jobs. Man kann manuell das Projekt bauen und erfolgreiche sowie fehlerhafte Builds anhand des Verlaufs erkennen.

Die Projektdokumentation Jenkins als CI Werkzeug vom Computer Software Investigation (CSI) der Hochschule Osnabrück liefert weitere Jenkins-Konfigurationen mit weiteren Projekten.

Literatur

  • Jez Humble, David Farley: Continuous Delivery. Reliable Software Releases Through Build, Test, and Deployment Automation (= Addison-Wesley Signature.) Addison-Wesley, Upper Saddle River 2010, ISBN 978-0-321-60191-9.
  • Eberhard Wolff: Continuous Delivery. Der pragmatische Einstieg. dpunkt, Heidelberg 2014, ISBN 978-3-864-90208-6.
  • Michael Hüttermann: DevOps for Developers. Integrate Development and Operations, The Agile Way. Apress, New York 2012, ISBN 978-1-4302-4569-8.

Einzelnachweise

  1. 1,0 1,1 Jez Humble, Chris Read, Dan North. The Deployment Production Line. In: Joseph Chao u. a. (Hrsg.): Agile Conference, 2006. IEEE Computer Society, Washington 2006, ISBN 0-7695-2562-8, DOI 10.1109/AGILE.2006.53
  2. Jez Humble, David Farley: Continuous Delivery. Reliable Software Releases Through Build, Test, and Deployment Automation (= Addison-Wesley Signature.) Addison-Wesley, Upper Saddle River 2010, ISBN 978-0-321-60191-9.
  3. 3,0 3,1 Lianping Chen. Continuous Delivery: Huge Benefits, but Challenges Too. Software, IEEE , vol.32, no.2, pp.50,54, Mar.-Apr. 2015 doi: 10.1109/MS.2015.27
  4. Janus, A.; Dumke, R.; Schmietendorf, A.; Jager, J.. The 3C approach for Agile Quality Assurance. Emerging Trends in Software Metrics (WETSoM), 2012 3rd International Workshop on , vol., no., pp.9,13, 3-3 June 2012 DOI: 10.1109/WETSoM.2012.6226998
  5. Martin Fowler. Continuous Integration. 2006

Weblinks