Continuous Deployment und Git
Möchte man einen Produkt oder Projekt in der Versionskontrolle vernünftig verwalten kommt man früher oder später zur Frage welche Struktur man verwenden sollte. Zwei Anforderungen an die Struktur sind in den meisten Fällen vorhanden:
- Die aktuell bearbeiteten Aufgaben sollen zeitnah auf einem System testbar sein.
- Versionen sollen durchgängig und nachvollziehbar auf einer Staging- Landschaft verfügbar sein.
Für diese Anforderungen eignet sich der Einsatz von Gitflow.
Gitflow
Häufig wird in Projekten oder in der Produktentwicklung Gitflow als Mechanik für das Release-Management eingesetzt. Gitflow ermöglicht ein strukturiertes Vorgehen für die meisten im Betrieb und der Entwicklung auftretenden Anforderungen. Feature und Bugfix branches separieren den Code vom Branch für die Entwicklung. Der Master-Branch reflektiert nur tatsächliche Versionen. Besonders dringliche Änderungen nennt man in Gitflow ‚Hotfixes‘. Hotfixes zweigt man direkt vom Master-Branch ab, die resultierenden Änderungen fließen dann sowohl in die Weiterentwicklung als auch direkt auf den Release Branch ein.
Build Management
Wie aber sieht ein geeignetes Build Management aus, wenn man möglichst automatisiert seine Entwicklung testen, und Releases ausliefern möchte? Das Build Artefakt einer Version wird durch z.B. Bamboo gebaut. Anschließend deployed man dasselbe Build Artefakt, welches auf der Test Stage getestet wurde, auch auf das Produktivsystem. Dadurch ist sichergestellt, dass genau die getestete Version auf das Produktivsystem deployed wird. Aus diesem Vorgehen ergibt sich, dass man getrennte Systeme für die in Entwicklung befindlichen Arbeiten und für den Zweig, der die tatsächlichen Releases enthält, betreiben muss.
Release Management
Das Deployment auf die Development Stage wird vom Merge des Pull-Request einer abgeschlossenen Aufgabe ausgelöst. Ebenso kann ein neues Release erstellt werden, indem man einen Pull Request auf den Master merged. Während sich auf dem Development System also immer unterschiedliche Entwicklungsstände deployen lassen hat man auf der Release-Schiene immer eine konkrete Version. Der CI Server baut diese Version und deployed sie anschließend automatisch auf das Testsystem. Nach einem ausreichendem Test deployed man die Version dann auf Knopfdruck auf das Produktiv System.
Alternativ kann auch jeder Release- oder Bugfix- Branch auf ein provisioniertes System deployed werden. Bamboo unterstützt z.B. sowohl AWS als auch Docker von Haus aus. Ein System ad-hoc zu erstellen macht vor allem dann Sinn, wenn es viele Beteiligte gibt die gleichzeitig auf einem System testen müssen. Eine einzelne Development Stage ist dann zu oft von Änderungen und anschließenden neuen Deployments betroffen.
Wir sind Ihr Atlassian-Partner!
Sie möchten Atlassian Tools neu einführen oder besser ausschöpfen? Ihre Mitarbeiter möchten sich gern mehr um ihr Geschäft kümmern anstatt um Aktualität und Struktur Ihrer Atlassian Landschaft? Sie möchten dass Ihre Tools an Ihren Entwicklungsprozess angepasst werden? Mit unserer langjähriger Erfahrung unterstützen wir Sie gern bei der Einführung und beim Betrieb oder Erweiterungen Ihrer Atlassian Produkte. Sprechen Sie uns unverbindlich an.
