Dienstag, 21. Juni 2016

Continuous Delivery - offene Fragen und einige Antworten.

in meiner "nebenamtlichen Tätigkeit" als DevOps Engineer oder wie auch immer das heisst, bleiben immer wieder folgende offene Fragen an mir hängen. Ich schreibe sie hier auf - für mich selber - und als Diskussionsgrundlage.

Das Setup ist: Jekins, Jira, git mit Bitbucket, nexus



Developement Pipeline und Release-Management

Features werden innerhalb eines Scrum-Prozesses von Entwicklern ganz normal auf einem feature-Branch entwickelt. Sie passieren diverse Schwellen im den Developement-Pipeline: 

Quelle: http://fabric8.io/guide/cdelivery.html 

...und generieren dort feedback. Je nach Feedback dürfen die features nicht in der Pipeline weitergehen. 
Die Frage ist nun: 

  • wie kann ich verhindern, dass ein release gemacht wird, wenn ein feature einen roten Feedback hat? (z.B. Integraions-Tests müssen grün sein, bevor ein Release läuft. Nichts neues ist gemergt) (Antwort: Pre-Commit Verification, Infrastruktur fehlt bei uns.) 
  • wenn die Pipeline grün ist: wie kann ich verhindern, dass unterdessen nichts neues auf den Integrations-Branch (oder Trunk) eingecheckt wurde, bevor ich den release gemacht habe? (wer überwacht das?) (Das ist ok - Pipeline baut Artefakte, welche geprüft sind). 
  • wie kann ich in Jira anzeigen, welche Schwellen ein Feature schon passiert hat? 
  • wie kann ich in Jira anzeigen, welches Feature auf welchem Stage in welchem Release installiert ist? 
  • wenn ich dann einen Release mache: wie kommuniziert Jenkins dem Jira, welches feature in welchem Release gelandet ist? (automatische Release-Notes - Infrastruktur fehlt) 
  • was ist ein Release: ein Release im Sinn von Scrum nach ein paar Sprints - oder ein Release im Sinn von maven, wo kein -SNAPSHOT in der Version steht? (Jira-Versionen und Maven-Release-Versionen müssen synchron sein.) 


Branching-Modell: trunk-based Development

Immer wieder Dikussionen entstehen mit dem Unterschied von Modellen wie gitflow und trunk-based development

  • Genügt ein Hauptbranch, der immer "grün" ist? Oder braucht es für jeden Releease, Bugfix etc. einen eigenen Branch, mit dem Rattenschwanz von Merg-Tasks? (ja!) 
  • Genügt ein Tag für einen Release? (ja!)
Auch immer wieder für Verwirrung sorgt: was wird auf Produktion installiert? Ein bestimmer Release (ein Artefakt in nexus), oder ein bestimmter Branch im git? (Bei unserem Setup ein Artefakt auf Nexus, das auf dem Hauptbranch getagt ist).

Antwort, update: Ich fahre momenten mit einem Mix von Trunk-Based-Development und pre-merge-verification sehr gut. Wichtig ist: "keep your main branch green",
Konkret: Die Entwickler sind dafür verantwortlich, auf ihrer lokalen Maschine einen Rebase oder merge from main-branch ihres Entwicklungs-Branch zu machen, und ihn local zu testen (jUnit und Selenium.) Danach wird ein Pull-Request erstellt, der von anderen Teammitgliedern manuell geprüft wird. Erst dann wird auf den Main-Branch gemergt, welcher dann sofort vom Jenkins-CI-Server integriert, auf DEV installiert und getestet wird. Mit diesem Ansatz erreichen wir eine sehr gute Code-Qualität, obwohl die Qualität der Selenium-Tests schlecht ist. Und als Nebeneffekt ist der Know-How-Transfer im Team besser.

Siehe dazu auch folgender Artikel (Vortrag an der ConDelivery in Mannheim):

...die Frageliste ist nicht abgeschlossen, und wird in nächste Zeit überarbeitet werden müssen... 


Keine Kommentare:

Kommentar veröffentlichen