Leserbrief

Sehr geehrte Damen und Herren,


ich habe mich sehr gefreut, zu Continuous Delivery einen Artikel im Java Magazin 3.2012 zu lesen. Schließlich gibt es mehr als genug große Softwareprodukte, die an diesen Problemen scheitern. Ich finde den Artikel sehr interessant. Meiner Meinung nach beschreibt er fast alle notwendigen Konzepte, gibt aber aus meiner Sicht teils falsche Lösungsansätze. Deshalb möchte ich Ihnen meine Erfahrungen zum Thema mitteilen.

Kurz zu mir: Ich arbeite in einem größeren deutschen Internetunternehmen und bin dort mit verantwortlich für den Aufbau eines funktionierenden Continuous-Delivery-Systems; mein letztes Projekt war und ist eine GWT-Anwendung, an der zwischen 25 und 40 Entwickler arbeiten. Wir haben den Anspruch (mit jedem Projekt), jederzeit releasen zu können, ein releasefähiges Artefakt bei der GWT-Anwendung dauert 25 Minuten (fünf Minuten Merge + Version Bump, 20 Minuten auf den Build warten), das Release fünf Minuten. Wir releasen meist mindestens einmal täglich, je nach Feature- oder Bugfix-Situation.

In dem Abschnitt über Branching schreibt der Autor, dass Feature Branches CI und die dauerhafte Releasefähigkeit verhindern. Bei uns – und meiner Überzeugung nach – ist das Gegenteil der Fall. Wir verwenden überall Git und Github nach einem Branching Model, das unter [1] beschrieben ist. Die Essenz ist folgende:

  • Der Master Branch ist die Source für Releases. Jeder Commit (Merge) in diesen Branch führt zum Bauen eines RPMs. Hier wird nicht gearbeitet, nur hineingemerged.

  • Der Develop Branch ist quasi der „Trunk“ aus SVN-Zeiten. Dieser Branch ist im Jenkins als Mainstream eingetragen und wird kontinuierlich getestet. Auch in dem Branch wird nicht gearbeitet, sondern nur Feature Branches abgezweigt und zurückgemerged. Der Develop ist dafür prädestiniert, automatisch deployt auf einem internen Testserver zu laufen.

  • Diverse Branches werden genutzt, um Features zu entwickeln oder Bugs zu fixen. Innerhalb eines Feature Branches werden selbstredend Tests und die Dokumentation erweitert. Ein Merge erfolgt nur mit Review oder Pull Request.

Die Situation, dass ein Merge viel Zeit kostet, kann eigentlich nicht passieren, wenn jeder Entwickler (oder jedes Team), der an einem Branch arbeitet, oft den Develop pullt. Spätestens vor dem Merge in den Develop muss der Feature Branch den Develop pullen, damit ein Review sinnvoll möglich ist. Andernfalls wäre das Diff vollkommen unübersichtlich. Wenn es nun doch zu Konflikten kommt, dann sind sie im Feature Branch und verhinder...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang