Einführung in Continuous Integration – Anwendungsentwickler-Podcast #92

Eine Einführung in die kontinuierliche Integration – Continuous Integration – gibt es in der zweiundneunzigsten Episode des Anwendungsentwickler-Podcasts.

Probeabo bei Audible (Affiliate)

Inhalt

Voraussetzungen

  • Völlig unabhängig von Programmiersprache oder Plattform.
  • Theoretisch auch ohne separate Software umsetzbar, aber einfacher mit etablierten Lösungen wie Jenkins, Team Foundation Server, Travis CI, Teamcity oder CruiseControl.
  • Alle Artefakte (Code, Oberflächen, Konfiguration usw.) müssen in der Versionsverwaltung liegen.
  • Ein automatischer Build des Projekts muss möglich sein (z.B. mit Gradle oder MS Build).
  • Der Build sollte möglichst schnell sein.
  • Die Funktionalität sollte mit automatischen Tests abgedeckt sein.
  • Entwickler müssen häufig – mindestens täglich – committen.

Vorteile

  • Das Projekt ist jederzeit auf dem neusten Stand automatisiert baubar.
  • Vermeidung von „Works on my Machine“.
  • Vermeidung langer Integrationsphasen vor Deployments.
  • Erziehung der Entwickler zu kleinen Commits, sauberem Code und automatisierten Tests.
  • Projektbeteiligte bekommen jederzeit kurzfristiges Feedback zum Projektstand.
  • Statische Codeanalyse ist möglich.
    • Einhaltung von Code-Konventionen, z.B. mit Checkstyle.
    • Finden/Verhindern von Bugs, z.B. mit FindBugs.
    • Codeabdeckung durch Tests, z.B. mit JaCoCo.
    • Visualisierung von Abhängigkeiten, z.B. mit JDepend.
    • Trends können erkannt werden.
  • Artefakte können automatisch im Repository abgelegt werden.
  • Automatisches Deployment in eine Testumgebung kann stattfinden.

Mögliche Erweiterungen

  • Verschiedene Strategien für die Versionierung möglich, z.B. Feature Branches oder Feature Toggles.
  • CI ist die Basis für Continuous Delivery und Continuous Deployment.

Literaturempfehlungen

Für Jenkins gibt es inzwischen eine eigene Konferenz, deren Videos größtenteils bei Confreaks verfügbar sind: Jenkins User Conference.

Links

Probeabo bei Audible (Affiliate)

Polyglot Clean Code Developer
About the Author
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

7 comments on “Einführung in Continuous Integration – Anwendungsentwickler-Podcast #92

  1. Anne sagt:

    Kleine Anmerkung zur Plattformunabhängigkeit / Mächtigkeit des Jenkins:
    Wir arbeiten (je nach Abteilung) mit C#, PHP, Java und Javascript, mit jeweils komplett verschiedenen Frameworks (ASP.NET, Hibernate, Symfony, Typo3, Spring, Magnolia, Angular, etc…), Buildtools (Bower, Maven, BuildIt) und Testssuites drunter (JUnit, NUnit, PHPUnit, Karma, Selenium,…).
    Alle unsere Projekte laufen auf demselben Jenkins (verteilt auf verschiedene Build-Nodes). Meines Wissens gab es hier noch nie größere Probleme oder Konflikte.

    Bei uns ist der Jenkins sogar so eingestellt, dass kurz nach jedem Commit der entsprechende Build angestoßen wird. Damit gibt es Projekte, die von frühs 8 bis abends 18 permanent immer wieder neu gebaut werden.
    Zusammen mit der Policy „Check nix ein, das nicht funktioniert“, hat man so regelmäßig einen Release-fähigen Zustand.

    Für einige Projekte haben wir inzwischen auch ein Continuous Delivery eingebaut, also dass automatisch ein Deployment mit getriggert wird.

  2. Stefan Macke sagt:

    Danke für die Ergänzung! Gut zu wissen, dass auch in der Praxis so viele verschiedene Plattformen über den Jenkins bedient werden.

    Den Build nach jedem Push haben wir auch aktiviert. Dabei ist es halt nur wichtig, dass der Build recht flott läuft. Unser Hauptsystem braucht teilweise 30 Minuten. Das ist für „schnelles“ Feedback etwas langsam :-/ Aber die „normalen“ Java- und .NET-Projekte sind ratzfatz durch 🙂

  3. Anne sagt:

    30 Minuten sind bei uns die kleinen Projekte. „Mein“ aktuelles Projekt braucht ~ 1 1/2 h, unser längstes ~ 4 1/2.
    Wobei man fairerweise dazu sagen muss, dass die langen Buildzeiten primär durch die GUI-Tests (Selenium) entstehen. Grad mal bei „meinem“ Projekt nachgesehen: Die Unittests dauern 11 Minuten, die GUI-Tests 1h 20 min.

  4. Christian sagt:

    Die Unittests dauern 11 Minuten, die GUI-Tests 1h 20 min.

    Wie umfangreich sind denn die Projekte (insbesondere die kleinen)? Und wie viele Tests gibt es da?

  5. Anne sagt:

    @Christian
    „Mein“ Projekt hat ~ 5200 Tests, davon ~ 4200 Unittests.
    Eines unserer kleinsten hat ~500 Tests, wobei ich dort grad nicht sagen kann, wieviel davon Unittests sind.

  6. Anne sagt:

    EDIT: Ziemlich viele Tests fahren den Spring- oder Web-Context hoch, was die Zeiten auch nochmal massiv erhöht im Vergleich zu simplen JUnit-Tests.

  7. Stefan Macke sagt:

    Uhhh… ja, das kostet! Die Oberflächentests sind bei uns auch super langsam…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax