Tipps für Git und Bamboo im Continuous-Delivery-Prozess (Teil 2)

Wie lassen sich Git-Repositories möglichst Continuous-Integration-freundlich machen, sodass Git und Bamboo möglichst effizient zusammenspielen? Dieser Frage sind wir im ersten Artikel nachgegangen und haben drei Rezepte besprochen. Daran anknüpfend, diskutieren wir nun zwei weitere Tipps.

Trigger klug auswählen

In allen aktiven Branches nach dem CI-Vorgehen zu arbeiten, ist grundsätzlich eine gute Idee. Aber ist es auch eine gute Idee, alle Builds in allen Branches gegen alle Commits auszuführen? Eher nicht, und zwar deshalb: Nehmen wir ein Software-Haus mit mehreren hundert Entwicklern, von denen alle mehrmals am Tag Änderungen zum Repo pushen (zumeist Pushes in ihre Feature-Branches). Das sind eine Menge Build, und wenn wir unsere Build-Agents nicht instantan und ins Unendliche skalieren können, bedeutet das langes Anstehen in der Warteschleife.

Spielen wir mit ein paar Zahlen: Ein interner Build-Server beherbergt vielleicht um die 1.000 Build-Pläne. 150 Build-Agents sind implementiert, und wir nutzen Best Practices wie Artifact Passing und Test-Parallelisierung, um jeden Build so effizient wie möglich zu machen. Doch nach wie vor führt Building nach jedem einzelnen Push zu einem Flaschenhals.

Ist es nun wirklich nötig, wohl oder übel einfach eine weitere Bamboo-Instanz mit nochmals über 100 Agents aufzusetzen? Nein.

Wir können den Entwicklern die Option von Push-Button-Builds gewähren, statt Builds immer automatisch zu triggern. So kann eine gute Balance zwischen Teststrenge und Ressourcenschonung entstehen, und da in Branches die meisten Änderungen vorgenommen werden, ist dies eine große Möglichkeit für Einsparungen.

Viele Entwickler dürften die zusätzliche Kontrolle durch Push-Button-Builds mögen und sie ganz natürlich in ihre Workflows einbinden können. Einige werden sich lieber keine Gedanken darüber machen wollen, wann ein Build ausgeführt werden soll. Die Kombination beider Ansätze kann funktionieren. Das Wichtigste ist, Branches zuerst zu testen und sicherzustellen, dass wir einen sauberen Build haben, ehe wir upstream mergen.

Kritische Branches wie der master oder stabile Release-Branches sind eine andere Geschichte. Dort werden Builds automatisch getriggert, entweder durch Abfragen des Repos nach Änderungen oder durch das Senden einer Push-Benachrichtigung von Bitbucket an Bamboo. Theoretisch sollten alle Work-in-Progress-Arbeiten in Entwicklungs-Branches stattfinden, und die einzigen Branches, die in den master gelangen, sollten Entwicklungs-Branches sein, die hinein gemergt werden. Und dies sind die Code-Zeilen, aus denen wir Releases machen und aus denen Entwicklungs-Branches werden. Daher ist es so wichtig, dass wir frühzeitig Testergebnisse für jeden Merge erhalten.

Hooks statt Abfragen nutzen

Ein Repo alle paar Minuten auf Änderungen hin abzufragen, ist für Bamboo kein großes Thema. Aber wenn sich dies auf hunderte Builds und tausende Branches hoch skaliert und dutzende Repos involviert sind, summiert sich das schnell auf. Statt Bamboo Abfragen machen zu lassen, können wir Bitbucket auch anweisen, Bescheid zu geben, wenn Änderungen gepusht wurden und ein Build erforderlich ist.

Das tun wir normalerweise, indem wir unserem Repository einen entsprechenden Hook hinzufügen, aber die Integration zwischen Bitbucket und Bamboo erledigt all die zugrundeliegende Arbeit für uns. Sobald die Systeme miteinander verknüpft sind, funktionieren Repo-getriebene Build-Trigger 'out of the box', ohne dass wir Hooks oder spezielle Konfigurationen brauchen.

Repo-getriebene Trigger haben auch den Vorteil, dass inaktiv werdende Ziel-Branches nach und nach von der Bildfläche verschwinden. Wir müssen keine CPU-Zyklen unseres CI-Systems dafür verschwenden, zig oder hunderte verwaiste Branches abzufragen, oder unsere eigene Zeit damit vergeuden, Branch-Builds manuell abzustellen. (Wer dennoch Bamboo-Abfragen bevorzugt, kann in Bamboo immerhin einstellen, nach wie vielen Tagen der Inaktivität Branches ignoriert werden sollen.)

In kommenden Artikeln werden wir uns dann mit Continuous-Delivery-Workflows, dem Testen im CD-Prozess und dem Deployment-Prozess befassen.

Weiterführende Infos

Continuous Delivery in der Praxis: Deployment auf Knopfdruck und Release-Verwaltung mit Bamboo
Individuelle Software-Entwicklung: Workflows, Branching-Modelle und Continuous Delivery
Bamboo: Continuous Integration auf Enterprise-Skala
Continuous Deployment: Software-Entwicklung nach dem Lean-Startup-Konzept

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar