Es ist klar: Kein Tool der Welt wird auf magische Weise dafür sorgen, dass Sie von heute auf morgen DevOps oder agile / lean Praktiken in Ihrem Unternehmen implementiert haben und diese meisterhaft beherrschen. DevOps fördert die Zusammenarbeit und Kommunikation zwischen Entwicklung und IT-Betrieb und ist keine Magie, sondern eher ein Kulturwandel.

Es gibt jedoch einige Tools und Technologien, welche die Zusammenarbeit zwischen den Teams unterstützen und für eine gewisse Automatisierung sorgen können. Atlassian hat einen informativen Leitfaden im Atlassian Blog mit geballtem Wissen und praktischen Ratschlägen rund um den Einsatz von Werkzeugen für DevOps veröffentlicht, den wir Ihnen nicht vorenthalten möchten. Diese Artikelreihe wird Ihnen zeigen, welche Tools für welche Teams sinnvoll sind und auf was Sie bei Erwerb und Lizenzierung achten sollten.

Obwohl viele Tools alle Phasen des Entwicklungszyklus auf die eine oder andere Weise beeinflussen, spielt kein Tool die Hauptrolle in allen Phasen. Wenn Sie sich also Gedanken über DevOps-Tools machen, dann ist es hilfreich, wenn Sie den gesamten Zyklus in die einzelnen Phasen unterteilen. Der Entwicklungszyklus lässt sich am besten wie folgt zerlegen: Planung, Build-Prozess, kontinuierliche Integration, Implementierung, Deployment und kontinuierliches Feedback.

Devops (1)

1. Planung: Vision und Design gemeinsam erarbeiten

Die Grundlagen der agilen Softwareentwicklung empfehlen Tools, die es Ihrem Entwicklungsteam ermöglichen, in Iterationen zu planen. Auf diese Weise fangen Sie früher an, von den Benutzern zu lernen und Sie können Ihr Produkt basierend auf diesem Feedback optimieren. Setzen Sie also auf Tools mit Sprint-Planungsfunktionen.

Eine weitere gute Praxis ist, kontinuierlich Nutzerfeedback zu sammeln, es in umsetzbaren Inputs zu organisieren und diese Aktionen für Ihre Entwicklungsteams zu priorisieren. Tools, die „asynchrones Brainstorming“ (wenn man so will) fördern, sind hier erste Wahl. Es ist wichtig, dass jedes einzelne Teammitglied alle Dinge teilen und kommentieren kann: Ideen, Strategien, Ziele, Anforderungen, Roadmaps und Dokumentation.

Und vergessen Sie auf keinen Fall die Integrationen. Wo auch immer Sie den Umfang Ihres Features oder eines Projekts festlegen, Sie sollten diese in User-Stories in Ihrem Entwicklungs-Backlog umwandeln.

Devops (2)

Weitere Informationen zu dieser Phase finden Sie in diesem Beitrag zum Thema agile Backlogs und deren Priorisierung.

Die Werkzeuge, die hierfür in Frage kommen:

2. Build-Prozess: Umgebungen für die Entwicklung festlegen

Während von Puppet und Chef in erster Linie nur die Teams im IT-Betrieb profitieren, verwenden Entwickler Werkzeuge wie beispielsweise Docker zur Bereitstellung von individuellen Entwicklungsumgebungen. Gegen virtuelle, wegwerfbare Repliken der Produktion zu programmieren hilft dabei, mehr Arbeit zu erledigen.

Irgendetwas stimmt mit dem Klassenpfad nicht? Die Maven-Installation ist plötzlich beschädigt? Infrastruktur als Code bedeutet, dass eine erneute Bereitstellung schneller ist, als eine Reparatur – und zuverlässiger ist es auch. Das bedeutet außerdem, dass Sie unterschiedliche Variationen Ihrer Entwicklungsumgebung nutzen können.

Wenn das gesamte Team auf identischen bereitgestellten Umgebungen arbeitet, dann ist „Auf meinem Rechner funktioniert es!“ nicht länger Ausnahme, sondern Regel.

Die Werkzeuge, die hierfür in Frage kommen:

Infrastruktur als Code

Entwickler erstellen modulare Anwendungen, weil diese zuverlässiger und wartungsfreundlicher sind. Warum wendet man diesen Gedanken nicht auch auf die IT-Infrastruktur an?

Devops (3)

Es kann schwierig sein, dieses Prinzip auch bei Systemen anzuwenden, da diese sich stets verändern. Dieses Problem lässt sich umgehen, indem Provisioning Code (also Code, mit dem ein System grundeingerichtet wird, zum Beispiel durch Installation der benötigten Software) genutzt wird. Dieser Bereitstellungs-Code kann auf Bare Metal-Ebene angewandt werden und erneut verwendet werden, um einen Server auf den Ausgangszustand zurückzusetzen.

Er kann in der Versionskontrolle abgelegt werden. Er kann geprüft werden. Er kann in die CI (Continuous Integration) eingebracht werden. Es können Peer-Reviews des Codes durchgeführt werden. Was auch immer Sie möchten.

Wenn institutionelles Wissen als Quelltext hinterlegt ist, dann schwindet die Notwendigkeit für Run-Books und interne Dokumentation. Dafür entstehen wiederholbare Prozesse und zuverlässige Systeme. Weniger reden, mehr arbeiten.

Die Werkzeuge, die hierfür in Frage kommen:

Kollaboratives Coding

Anstatt auf eine Änderungserlaubnis zu warten, bevor eine Software in Produktion genommen werden kann, können Sie die Codequalität und den Durchsatz mit Peer-Reviews in Form von Pull-Requests verbessern.

Sie fragen sich, was Pull-Requests sind? Pull-Requests informieren Ihr Team über Änderungen, die Sie in einem Entwicklungszweig innerhalb Ihres Repositories vorgenommen haben. Ihr Team kann dann die vorgeschlagenen Änderungen überprüfen und diese besprechen, bevor sie in den Hauptcode integriert werden.

Erfahren Sie mehr über Pull-Requests und deren Nutzen in der Praxis in diesem Artikel.

Die Werkzeuge, die hierfür in Frage kommen:

Aber wir halten fest und wiederholen: Kein Tool wird Ihr Team auf magische Weise in DevOps verwandeln. Im nächsten Teil betrachten wir die Themen Kontinuierliche Integration und Veröffentlichung – und welche Werkzeuge dafür geeignet sind.

Das interessiert Sie?

Dann sind wir als Atlassian Platinum Partner für Sie da.