© svetabelaya/Shutterstock.com
Kolumne: DevOps Stories

Kolumne: DevOps Stories


Nur noch wenige Stunden bis zum Sprint Review. Das MusicStore-Team arbeitet intensiv daran, letzte Stories fertigzustellen.

Martin: „Tschakka, Erster!“

Christian: „Hä?“

Martin: „Ich habe meinen Feature Branch in den Master gemergt. Das war ein hartes Stück Arbeit. Ihr müsst bei euren Branches aufpassen. Ich habe vor allem in den Services für den Recommender und die Timeline einiges geändert.“

Christian: „Super, ich auch. Und wenn ich das richtig verstanden habe, hat Lukas dort auch einiges geändert.“

Lukas: „Ja, habe ich.“

Christian: „Und Martin ist noch stolz drauf, dass wir jetzt die Merge Hell haben! Danke, Martin. Wir haben noch zwei Stunden bis zum Review und dürfen das jetzt unter Hochdruck zusammenpuzzeln.“

Martin: „Sorry, aber das Feature war echt knifflig. Ich habe ja beinahe den ganzen Sprint für die Entwicklung gebraucht.“

Ruben: „Der Build nach deinem Merge ist gerade gelaufen. Ich hätte erwartet, dass einiges an Tests dazukommt. Die Anzahl der Testfälle ist aber fast gleich geblieben.“

Martin: „Ich habe doch gesagt, dass das Feature knifflig war. Für zusätzliche Tests hatte ich keine Zeit!“

Ruben: „In unserer Definition of Done steht doch aber, dass es für jede Klasse Tests gibt.“

Martin: „Die gibt es ja auch. Nur halt nicht für die neuen Funktionen.“

Christian: „Na, das ist doch sowieso egal. Ein Teil der vorhandenen Tests schlägt seit ungefähr einer Woche fehl, und das interessiert hier auch niemanden.“

Martin: „Aber ich musste doch das Feature fertigmachen, damit wir es im Review zeigen können ...“

Lukas: „Wie möchtest du das Feature denn im Review zeigen? Die Tests schlagen fehl und der Build ist rot. Der neue Code ist also nicht auf der Demo-Environment deployt worden.“

Martin: „Ups, stimmt. Wollen wir dann die Tests fürs Review ausschalten und danach wieder an?“

Christian: „Was ein Quatsch. Dann können wir deinen Kram gleich von Hand auf der Umgebung deployen!“

Martin: „Aber dann hätten wir doch keine Continuous Integration mehr.“

Ruben: „Haben wir die denn jetzt?“

Continuous Integration heißt ...

Rubens Frage ist absolut berechtigt. Ja, das Team hat einen Continuous-Integration-Server, der auf Änderungen im Versionskontrollsystem reagiert, den Build durchführt und im Erfolgsfall das entstandene Artefakt auf eine Umgebung deployt. Aber bringt dieser Prozess dem Team im aktuellen Zustand irgendeinen Erkenntnisgewinn?

Continuous Integration (CI) soll uns helfen, möglichst schnell Feedback zu Änderungen am Sourcecode zu bekommen. Wir sollen Probleme direkt entdecken und beheben, solange die Behebung noch relativ einfach ist. Obwohl das MusicStore-Team einen CI-Server einsetzt, sorgt der aktuelle Zustand s...

Neugierig geworden? Wir haben diese Angebote für dich:

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