Der Releaseprozess des Teams

Abgeschlossen

Der erste Schritt auf dem Weg zu einem DevOps-Ansatz ist die Beurteilung Ihrer aktuellen Situation. Dies bedeutet, dass Folgendes analysiert werden muss:

• Ihre vorhandenen Artefakte wie Bereitstellungspakete und NuGet sowie Ihre Containerrepositorys.
• Ihre vorhandenen Testverwaltungstools
• Ihre vorhandenen Arbeitsverwaltungstools
• Empfehlungen für Migrations- und Integrationsstrategien.

Beurteilen wir also die Situation des Tailspin-Teams, und sehen wir uns an, wie DevOps hier helfen kann.

Nachdem Irwin der Produktmanager den Raum verlassen hat, sagt Amita: „Wir brauchen Hilfe. Ich weiß nicht, wann diese Fixes fertig sein sollen, aber ich weiß, dass es bald ist. Wir haben nicht die Ressourcen für eine schnelle Abwicklung. Außerdem muss die neue Space Game-Website auf Eis gelegt werden, bis wir diese Probleme behoben haben. Und die Veröffentlichung des Spiels rückt immer näher.“

Andy schaut Mara an. „Da prasselt in deinen ersten Wochen schon eine Menge auf dich ein.“

„Das ist schon in Ordnung“, antwortet Mara. „Vielleicht kannst du mir erklären, wie ihr sowas normalerweise handhabt. Wie wird ein Spiel von der Entwicklung in die Produktion verschoben?“

„Gute Frage“, sagt Andy. „Ich weiß allerdings nicht, ob wird das so einfach beantworten können. Aber wir können es versuchen.“

Das Team entscheidet sich, in ein Café zu gehen und das Thema informell zu besprechen. Sie versuchen, gemeinsam herauszufinden, warum es so viele Probleme gibt.

Bei einem Kaffee versucht Mara, zuzuhören und alles aufzunehmen. Es gibt viele unstrukturierte Informationen. Ihre ersten Eindrücke des Teams sind die folgenden:

• Sie verwenden einen Wasserfallmodell. Die Geschäftsführung legt die Prioritäten fest. Entwickler schreiben Code und übergeben den Build ans QA. Beim QA wird der Code getestet und anschließend an die IT-Betriebsabteilung zur Bereitstellung gegeben.
• Bei einem kleinen Team wäre der Wasserfallansatz möglicherweise sinnvoll, aber in diesem Fall sind die Ziele nicht immer eindeutig und scheinen sich oft zu ändern.
• Tests werden erst relativ spät im Prozess durchgeführt. Das bedeutet, dass es schwieriger und aufwendiger ist, Fehler zu beheben und Änderungen vorzunehmen.
• Es gibt keine klare Definition von Fertig. Jedes Teammitglied ist einer anderen Auffassung. Es gibt kein übergeordnetes Geschäftsziel, über das sich alle einig sind.
• Es gibt Code in einem zentralisierten Versionskontrollsystem. Viele Tools und Skripts sind nur in Netzwerkdateifreigaben vorhanden.
• Es gibt viele manuelle Vorgänge.
• Die Kommunikation ist unstrukturiert und verläuft via E-Mail, Word-Dokumente und Tabellen.
• Feedback wird nur unregelmäßig und inkonsistent gegeben.
• Immerhin scheinen sich die Teammitglieder zu verstehen, und sie sind offen für Verbesserungen.

Mara sieht sich ihre Notizen an und stellt fest, dass sie die Informationen organisieren muss. Wenn Sie die Informationen organisiert, können die Prozesse leichter beurteilt werden. Sie ist davon überzeugt, dass ein DevOps-Ansatz viele der Probleme des Teams lösen kann. Sie muss nur noch eine Möglichkeit finden, ihre Ideen dem Team vorzustellen.

Für einen DevOps-Ansatz müssen Sie oft zunächst die bestehenden Prozesse nachvollziehen können. Dann kann beurteilt werden, was schon gut funktioniert, was nicht gut funktioniert und was als erstes verbessert werden sollte.

Mara fragt: „Hat schon mal jemand eine Wertstromanalyse durchgeführt?“

Andy verdreht die Augen, Amita seufzt und Tim sagt: „Wir brauchen nicht noch mehr Papierkram.“

Mara sagt: „Kann ich verstehen. Überlasst das einfach mir.“

Alle sind froh, dass die Neue sich darum kümmert, und kehren zu ihrer Arbeit zurück.