Please enable JavaScript.
Coggle requires JavaScript to display documents.
Kapitel 06 Continuous Integration (CI) SE SS 17 h_da Prof. Dr. Kai Renz
Kapitel 06
Continuous Integration (CI)
SE SS 17 h_da Prof. Dr. Kai Renz
Motivation
Automatisierung
von
Test
Deployment
Build
Erhöhung der Qualität
Vermeidung von "Broken Windows"
Steigerung der Entwicklungs-Geschwindigkeit
Schnelleres Deployment
Schnelleres Feedback
Reduzierung von Risiken
Risiko, dass Entwicklungsstränge nicht zusammenpassen, wird minimiert
Continuous Integration Server
Testing Tools
nUnit :check:
Dependency Injection :check:
Mocking :check:
Selenium
FITnesse
Konfig-Management-Tools
git
svn
team foundation server
....
Build-Tools
gradle :check:
Einfacher als Maven
Nutzt (unter anderem) Maven als Repository
groovy basiert
DSL (Domain Spedific Language) mit Java Syntax
maven
Java basiertes Build-Tool
Versionen von
Artefakten (z.B. jar-files, etc.)
werden aus zentralen Repositories
in ein lokales Repository kopiert
Konfiguration erfolgt
durch
pom.xml
Datei
Alle Aktivitäten des Build-Managements werden vollständig unterstützt
Sehr
mächtig
, aber auch
komplex
https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
ant
Im Java -Umfeld beliebt.
make / cmake
Im C / C++ Umfeld weit verbreitet
Jenkins
Open Source Software für einen Continuous Integration Server
Verbindet
Konfig-Managament, Build, Test und Deployment
Sorgt für eine automatische Rückmeldung, ob ein Commit fehlerfrei baut
https://jenkins.io/
Java basiert
Integration
Voraussetzungen
The transition towards continuous integration requires an automated test suite, a main branch to which code is continually delivered, and a modularized architecture.
Nutzen eines Konfigurationsmanagement Tools
Alles, was man zum Build braucht, ist im Repository enthalten
Nur das Build-Ergebnis selbst ist in der Regel nicht enhalten
Eine
Main-Line für die Entwicklung des Projektes (trunk/master)
Ein
automatischer
Build
Ein Build muss
automatisch testbar
sein
Jeder Entwickler macht mindestens einmal am Tag einen Commit in den Master-Branch (Trunk)
Jeder Commit im Master-Branch (Trunk) muss auf dem Integrations-Server fehlerfrei bauen
Der Build muss
schnell
sein
(inklusive Tests)
Jeder muss den Zustand der Builds einfach sehen können
Sollte ein
Non-Event
sein
Soll regelmäßig stattfinden
Mindestens einmal am Tag durch jeden Entwickler
Beispiel
Startpunkt ist der
lokal ausgecheckte
letzte integrierte Quellstand
Durchführung von Änderungen und Ergänzungen am Quellcode
Anpassung und Ergänzungen bei den Unit-Tests
Lokales Testen (inklusive der neuen Tests)
Integration der lokalen Änderungen in den Master-Branch (Trunk)
a) Update der lokalen Kopie mit den Änderungen im Master-Branch (falls vorhanden)
b) Mergen und Fixen bei Integrationsproblemen
c) Wenn alles baut, dann commit der Änderungen in den Master-Branch
:!:
Wichtig
Build der Software auf dem Integrations-Server
Wenn Integrationsfehler auftreten, dann
müssen sie sofort behoben werden
!
Das ist in der Regel mit das Schwierigste bei der Einführung von CI
Alle Team-Mitglieder sind für den Build verantwortlich
Siren of Shame
Alternativer Ansatz: Man lässt den Integrations-Server auch Feature-Branches automatisch bauen und testen.
http://www.nurkiewicz.com/2013/02/breaking-build-is-not-crime.html
Die Änderung ist erst dann komplett integriert, wenn der Build auf dem Integrations-Server fehlerfrei funktioniert!
Weitere Themenfelder
Continuous Delivery
Continuous Deployment
Der automatisch getestete Build wird direkt in die Produktiv-Umgebung verteilt
Blue-Green-Deployment
https://martinfowler.com/bliki/BlueGreenDeployment.html
Technik zur schnellen, aber sicheren Auslieferung
Man betreibt zwei unabhängige Systeme (Blue/Green)
Neue Releases werden immer erst nur auf einem System eingespielt
Dev-OPS
Development
und
Operations
werden vom gleichen Team erledigt
Virtualisierung und Container
VMWare
Docker
Xen
KVM
Hyper-V
Entwicklung und Test auf einer möglichst gleichen Umgebung!
Gleiche Speichermenge
Gleiche Zahl CPU
gleiche Version OS
gleiche Version Datenbank, etc.
Testdaten sollten vom Umfang her zum Produtksystem passen!
Definition
Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible
M. Fowler
https://martinfowler.com/articles/continuousIntegration.html
Ist eine der
Extreme Programming XP
-Praktiken
Continuous Integration ist nicht dasselbe wie "Nightly Build"
Build zu festgelegten Zeiten kann dazu führen, dass Fehler beim Bauen erst mit einem Tag Verzögerung entdeckt werden.
Der Zeitaufwand zum Beheben ist dann in der Regel zu groß
https://continuousdelivery.com/
