Schließen

Continuous integration, explained

Steigere mit schnellerem Feedback die Agilität deines Teams. Weil du nicht schneller sein kannst als deine Tests.

Nothing builds–or destroys–agility like a team's commitment to continuous integration (CI). That might sound ominous (especially if your team has yet to embrace CI), but there's good news. Regardless of the technologies a team uses, chances are there's a continuous integration and automated test framework that will work for their code base. Here's what you need to know before you dive into the detail.

Continuous integration articles

[CONTINUED]

Was ist Continuous Integration?

Continuous Integration ist die routinemäßige Integration von Code-Änderungen in den Haupt-Branch eines Repositorys sowie das Testen von Änderungen so früh und so häufig wie möglich. Im Idealfall integrieren die Entwickler ihren Code jeden Tag, wenn nicht sogar mehrmals täglich.

Automated testing, continuous delivery, and continuous deployment

It is important to distinguish continuous integration from automated testing as well as continuous delivery and continuous deployment. While those development practices relate to each other, they differ essentially by how the code gets deployed to production.

Automated testing

Automated tests are tests that can be run without the need of human intervention in a repeatable way, at any time. You typically have to write down a script to test some assertions or validate the behaviour of your application. The script is then run by a machine which provides the results as an output. Automated testing is a key part of CI, but it is not enough by itself.

Continuous Delivery

You practice continuous delivery when your codebase is always deployable, ready to go to production in one click. While it is recommended to deploy to production as soon as you get a green build, you may decide to slow down the releases on purpose for business reasons.

Continuous Deployment

Continuous deployment happens when every change to the main branch that passes the CI tests gets pushed to production without the need for human interaction. This often results in many deployments per day which provide fast feedback to the development team.

Vorteile der Continuous Integration

Investing in CI results in fast feedback on code changes. Fast as in "within minutes" fast. A team that relies primarily on manual testing may get feedback in a couple hours, but in reality, comprehensive test feedback comes a day–or several days–after the code gets changed. And by that time more changes have occurred, making bug-fixing an archeological expedition with developers digging through several layers of code to get at the root of the problem.

Das ist definitiv nicht schnell.

Agile Teams liefern schnell hochwertige Software aus – ohne Death-March-Projekte oder Heldentaten. Möglich wird das durch CI.

Gesicherte Qualität durch Continuous Builds und automatisierte Tests

Wie viele von uns haben schon den neuesten Quellcode heruntergeladen und festgestellt, dass er nicht kompiliert werden kann oder einen schwerwiegenden Fehler enthält? Das ist der Tod der Produktivität!

Es gibt zwei Verfahrensweisen, um diese Situation zu vermeiden:

Continuous Builds: Das Projekt wird aufgebaut, sobald die Änderung erfolgt ist. Idealerweise ist das Delta zwischen jedem Build ein einziger Änderungssatz.

Test automation: Programatic validation of the software to ensure quality. Tests can initiate actions in the software from the UI (more on that in a moment), or from within the backend services layer.

Stell dir diese zwei Verfahrensweisen wie Erdnussbutter und Marmelade vor: Beides schmeckt allein schon gut, ist aber zusammen unschlagbar! Bei Continuous Integration werden Continuous Builds mit einer Testautomatisierung kombiniert, um sicherzustellen, dass jeder Build auch die Qualität der Codebasis auswertet.

And remember: to fully realize the benefits, a team must also have the discipline to pause development and address breakages right away. The energy a team invests (and make no mistake: it's an investment) in writing tests and configuring the automation is all for naught if builds are allowed to languish in a broken state. Protecting the investment in CI and protecting the quality of the code base are one and the same thing. 

Testverfahren bei Continuous Integration: Unit-Tests, API-Tests und funktionale Tests

CI wird in zwei Hauptphasen durchgeführt. Im ersten Schritt wird sichergestellt, dass der Code kompiliert werden kann. (Oder bei interpretierten Sprachen werden einfach alle Teile zusammengezogen.) Im zweiten Schritt wird sichergestellt, dass der Code gemäß dem Design funktioniert. Die sicherste Methode dafür ist eine Reihe von automatisierten Tests, die alle Ebenen des Produkts überprüfen. 

Unit-Tests

Vorteile: Einfach zu schreiben, schnelle Ausführung, enge Modellierung der Architektur der Codebasis

Nachteile: Unit-Tests überprüfen nur die Kernkomponenten der Software. Sie spiegeln keine Benutzer-Workflows wider, die oft die Zusammenarbeit zwischen mehreren Komponenten beinhalten.

Da ein Einheitentest aufzeigt, wie der Code funktionieren sollte, können sich Entwickler mithilfe von Einheitentests über den aktuellen Stand dieses Codebereichs informieren. 

API-Tests

Gute Software ist modular, was eine klarere Trennung der Arbeiten über mehrere Anwendungen hinweg ermöglicht. APIs sind die Endpunkte, an denen verschiedene Module miteinander kommunizieren. API-Tests überprüfen diese, indem sie Aufrufe von einem Modul zum anderen ausführen.

Benefits: Generally easy to write, run fast, and can easily model how applications will interact with one another.

Nachteile: In einfachen Bereichen des Codes können API-Tests einige Unit-Tests imitieren.

Da APIs die Schnittstellen zwischen Teilen der Anwendung sind, sind sie besonders nützlich bei der Vorbereitung auf ein Release. Sobald ein Build eines Release-Kandidaten alle API-Tests bestanden hat, kann das Team diesen viel zuversichtlicher an Kunden ausliefern.

Funktionstests

In funktionalen Tests werden größere Bereiche der Codebasis bearbeitet und Benutzer-Workflows modelliert. In Webanwendungen interagieren beispielsweise HTTPUnit und Selenium direkt mit der Benutzeroberfläche, um das Produkt zu testen.

Vorteile: Bugs werden sicherer gefunden, weil Benutzeraktionen imitiert werden und die Interoperabilität mehrerer Komponenten getestet wird.

Drawbacks: Slower than unit tests, and sometimes report false negatives because of network latency or a momentary outage somewhere in the technology stack.

Teams stellen oft fest, dass die Ausführungsgeschwindigkeit der automatisierten Tests nachlässt, je näher sie dem tatsächlichen Benutzer-Workflow kommen. HTTPUnit ist schneller, da es sich nicht um einen Webbrowser mit vollem Funktionsumfang handelt. Selenium kann nur so schnell wie der Webbrowser ausgeführt werden, bietet aber den Vorteil, gleichzeitig über mehrere Webbrowser ausgeführt werden zu können. Trotz dieser Vorbehalte sind funktionale Tests höchst wertvoll und stellen viel schneller Feedback bereit, als menschliche Tester es könnten.

Wo wir gerade beim Thema sind ...

Einige Tester sehen automatisierte Tests als existenzielle Bedrohung an. Diese Denkweise greift zu kurz und könnte nicht weiter von der Wahrheit entfernt liegen. Tester werden von der Schinderei wiederholter Testaufgaben befreit und können Zeit mit Risikoanalysen, Testplanung und dem Ausbau anderer Kompetenzen verbringen – z. B. das Programmieren lernen! 

Für eine schnelle Continuous Integration sorgen

Bei Atlassian möchten wir, dass Entwickler Innovationen vorantreiben und unsere Codebasis ordentlich bleibt. Wir legen großen Wert darauf, die "innere Feedback-Schleife" des Entwicklers zu verkürzen – d. h. die Zeit, die erforderlich ist, um Änderungen aufzubauen und Testergebnisse zu erhalten.

Die Ausführung automatisierter Tests kann sich schnell summieren und die Build-Dauer verlängern. Eine Strategie besteht darin, automatisierte Tests parallel auf mehreren Servern oder "Build-Agents" auszuführen, damit der CI-Server tatsächlich 2, 20 oder sogar 200 Tests gleichzeitig ausführt. Bei Cloud-Technologien kann die CPU-Leistung leicht skaliert werden, um die Anforderungen des Entwicklerteams zu erfüllen, wenn die Test-Suite wächst. Aber die CPU-Leistung ist nicht unbegrenzt. Teste jeden Bereich des Codes vollständig, aber nicht wiederholt. Redundante Tests verlängern die Build-Dauer (und verschwenden CPU-Leistung). Je schneller Entwickler grünes Licht bekommen, umso schneller können sie mit dem nächsten Element im Backlog fortfahren. 

Branching und CI: ein himmlisches Paar!

Viele Teams vermeiden das Branching wegen problematischer Merges. Aber mit neueren Technologien in der Versionskontrolle wie Git wurde sowohl das Branching als auch das Mergen vereinfacht. Um sicherzustellen, dass der Hauptentwicklungszweig ("Master" im Git-Jargon) integer bleibt, solltest du denselben Grad der Continuous Integration auf allen Entwicklungs- und stabilen Versions-Branches ausführen. Wenn der Build auf einem Branch durchgeht, kann das Team zuversichtlich sein, dass dieser Code in den Upstream gemergt werden kann.

With branching, continuous integration, and test automation, teams can be productive and innovative while still protecting code quality. If you're ready to take the next steps, check out our step-by-step guide to getting started with CI.

Das ist agile Entwicklung in Hochform: die regelmäßige Bereitstellung funktionierender Software mit minimalen technischen Schulden ohne Beeinträchtigung der Genialität.

Dan Radigan
Dan Radigan

Agile Methoden haben mich sowohl beruflich als auch persönlich stark beeinflusst, da ich gelernt habe, dass durch Agilität die besten Erfahrungen entstehen, sowohl beim Code als auch im Leben allgemein. Meine Leidenschaft sind Technologie, Fotografie und Motorradfahren – gerne in Kombination. Folge mir auf Twitter! @danradigan