Heute geht es um Continuous Delivery. Es handelt sich dabei wie bei der Continuous Integration um einen automatisierten Prozess, der den Arbeitsalltag übersichtlicher und leichter macht. Wie Delivery schon sagt wird hierbei die Auslieferung der Software betrachtet. Wie man der Überschrift entnehmen kann, gibt es kein fertiges System, sondern eine praktische Anleitung in welche Richtung man gehen kann und vor allem wie man losgeht.
Im Laufe der Entwicklung muss man seine Software sehr häufigen ausrollen. Da gibt es das CI System, ein Demonstrationssystem, vielleicht noch Präsentations- und Testsysteme und am Schluss auch noch das Live-System.
Ein CI System erfordert schon, dass es eine Automatisierung gibt, damit man sein Produkt im aktuellen Zustand ansehen kann. Diese Skripte lassen sich zumeist auch gleich für die internen System adaptieren und somit bleibt eigentlich nur das Staging und das Live-System etwas außen vor, wenn diese nicht intern betrieben werden.
Ich habe schon einige Male die Situation gesehen, dass diese Deployment-Skripte Shell-Skripte sind, deren Aufruf nur eine beschränkte Personengruppe ausführt. Sei es Unwissenheit, wo die Skripte eigentlich genau liegen und wie diese funktionieren, oder einfach nur Ungewissheit, was das Skript tut, das einmal der Shell-Guru entwickelt hat. Dieser Zustand ist nicht optimal und es gilt eine Verbesserung zu finden.
Hier kommt der Hudson/Jenkins ins Spiel. Das Deployment zu dem CI-Server wird ja (hoffentlich) von diesem System durchgeführt, also kann man auch gleich weitere Deployments über spezielle Jobs triggern. In einem konkreten Fall wurden hierfür einfach Tasks angelegt, die zeitlich getriggert sind (bspw. für die Demonstration im Scrum-Prozess) oder die nur manuell angestoßen werden.
Da wir Shell-Skripte vorliegen haben nutzen wir einfach die Möglichkeit Shellskripte vom Hudson/Jenkins aufrufen zu lassen. Diese lassen sich übrigens mittels ssh auch remote anstoßen.
Was gewinnt man dadurch?
Dem Entwickler werden Bedenken genommen, da man nun eigentlich nur auf einen Startknopf drücken muss. Somit kann das Deployment eigentlich von jedem angestoßen werden. Und das heißt die Deployment Aufgabe kann im Team verteilt werden.
Wie verhindert man Doppeldeployments (etwa 2 verschiedene Builds deployen auf den gleichen Server)?
Um das Ausführen von Jobs zu verhindern, die nicht parallel ausgeführt werden dürfen, aber ansonsten unabhängig voneinander sind, kann man „Locks and Latches“ benutzen. Dieses Plugin stellt ein Lock zur Verfügung, an das man die zu verknüpfenden Jobs bindet. So kann genau einer ausgeführt werden.
Gibt es weitere Vorteile?
Die Zeit für das Deployment kann man mitschneiden und basierend darauf die voraussichtliche Dauer für das nächste Deployment angeben. Auch kann man dann die einzelnen Schritte des Deployment-Shell-Skripts auf den Hudson/Jenkins auslagern. Bspw Emailversand, wenn das Deployment erfolgreich war oder fehlschlug.
Durch die crontab-Funktion des Hudson kann man auch die Skripte an Daten und Uhrzeiten koppeln. Und auch die gesamte Benachrichtigungs-und Trigger-Infrastruktur des Hudson/Jenkins verwenden.