Softwareentwicklung ist Teamarbeit. Die sich immer mehr verbreitenden agilen Vorgehensmodelle sind das beste Beispiel dafür. Dabei wird beispielsweise ein Sprint bzw. eine Iteration gemeinsam geplant, sich täglich über den Fortschritt ausgetauscht und abschließend gemeinsam reflektiert. Am Ende des Sprints steht ein Softwareprodukt zur Verfügung, welches neue Features und Verbesserungen enthält und von den Kunden genutzt werden kann. Soweit die Theorie. Häufig ist die automatische Auslieferung neuer Softwareversionen mit dem Kopieren der Ergebnisse eines zentralen Server Builds auf ein Netzlaufwerk oder einen Webserver für Entwicklungsabteilungen beendet. Bis dahin ist diese Vorgehensweise als Continuous Integration in vielen Entwicklungsteams implementiert. Danach sind oft diverse manuelle Schritte notwendig, um anschließend die Qualitätssicherung durchführen zu können, welche die Codeänderungen mit manuellen und automatischen Tests auf unterschiedlichen Systemen und Umgebungen verifiziert. Continuous Delivery erweitert Continuous Integration um diese bisher zu wenig beachteten Aktivitäten. Neben diesen vorwiegend technischen Aspekten wird die notwendige Kommunikation zwischen Entwicklungsabteilungen und IT-Administration bzw. Konfigurationsmanagement allzu oft vernachlässigt oder findet überhaupt nicht statt. Hierfür hat sich in den letzten Jahren unter dem Codenamen DevOps die gegenseitige Annäherung von Entwicklung und Betrieb etabliert, wodurch Continuous Delivery tatsächlich erst realisierbar wird. Der Artikel arbeitet die wesentlichen Bestandteile von Continuous Delivery heraus, die damit einhergehende, notwendige Kooperation zwischen Entwicklung und Betrieb und gibt einen Überblick über die zur Realisierung notwendigen Schritte. Der Fokus liegt hierbei auf der konzeptionellen Ebene, technische Beispiele erfolgen unter Verwendung des Microsoft Team Foundation Servers.
Jetzt anfragen