Leserbrief

Sehr geehrte Damen und Herren,

Wolf Schlegel


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.Weiterhin ist bei uns die Vorgabe, dass ein Product Owner sein Feature am Entwicklerrechner abnimmt, damit der Develop jederzeit released werden kann. Wenn das nicht möglich ist, dann darf der Merge erst erfolgen, wenn der Product Owner die Freigabe gibt.Zum Thema Automatisierung von Releases: Zweifelsfrei ist das eine wichtige Grundregel für Continuous Delivery – automatisieren was immer sinnvoll möglich ist. Aber ebenso wichtig ist ein Artefaktformat, das den Übergang von Development zu Operations definiert. Sinnvoll und bei uns praktikabel ist ein Distributionspaket, hier RPM. Jeder Service und jedes zu deployende Stück Software (auch eine JavaScript-Anwendung) werden als RPM delivered. Den Hinweis auf Chef oder Puppet finde ich irreführend, weil es dazu verleitet, Bastellösungen zu bauen. Chef oder Puppet sind keine Developer-Werkzeuge, sondern ...

Leserbrief

Sehr geehrte Damen und Herren,

Wolf Schlegel


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.Weiterhin ist bei uns die Vorgabe, dass ein Product Owner sein Feature am Entwicklerrechner abnimmt, damit der Develop jederzeit released werden kann. Wenn das nicht möglich ist, dann darf der Merge erst erfolgen, wenn der Product Owner die Freigabe gibt.Zum Thema Automatisierung von Releases: Zweifelsfrei ist das eine wichtige Grundregel für Continuous Delivery – automatisieren was immer sinnvoll möglich ist. Aber ebenso wichtig ist ein Artefaktformat, das den Übergang von Development zu Operations definiert. Sinnvoll und bei uns praktikabel ist ein Distributionspaket, hier RPM. Jeder Service und jedes zu deployende Stück Software (auch eine JavaScript-Anwendung) werden als RPM delivered. Den Hinweis auf Chef oder Puppet finde ich irreführend, weil es dazu verleitet, Bastellösungen zu bauen. Chef oder Puppet sind keine Developer-Werkzeuge, sondern ...

Neugierig geworden?


    
Loading...

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