In einer Entwicklungsumgebung entsteht schnell die Anforderung, dass man wissen will, in welcher Version nun wirklich Feature X integriert wurde oder Bug X gelöst wurde. Selbstverständlich gehört ein vernünftiges Versions- und Releasemanagement dazu, aber für die internen „Snapshot-Releases“ ist in der Regel nur die Build- und Revisionsnummer eindeutig. Folgerichtig benötigt man geeignete, automatische Workflows um sowohl zu jedem Build die betreffenden Tickets als auch bei jedem Ticket die betreffenden Builds zu ermitteln und anzuzeigen. Gleichzeitig hat dies den Nebeneffekt, dass diese Informationsverlinkung indirekt auch archiviert wird.
Prinzipiell gilt:
- Von einem Continues Integration (CI) Build Server lässt sich theoretisch jede Art von Script starten.
- Jedes Ticketsystem, sogar jene ohne API, lassen sich via HTTP ansprechen.
Es dürfte aber wohl klar ersichtlich sein, dass die Verwendung von fertigen Plugins und offiziellen APIs dringend empfohlen wird. Je nach verwendeten Produkten gibt es bereits fertige Lösungen und Plugins. Wir wollen dies nun am Beispiel von Jenkins und JIRA zeigen.
Neben dem natürlich existierenden Weg, mittels eines Shellscripts die JIRA REST API zu verwenden, kann man sich das Leben mit den JIRA-Plugins von Hudson/Jenkins wesentlich einfacher machen. Alternativ bietet Atlassian für JIRA aber auch noch eine SOAP und eine XML-RPC-Api an.
Plugin 1: Jenkins JIRA Plugin
Das schon länger existierende JIRA Plugin wird in der globalen Konfiguration von Jenkins konfiguriert. Die Konfiguration einer JIRA-Instanz mittels URL, Benutzer und Passwort sollte selbsterklärend sein. Anschließend kann man in einer Job-Konfiguration (unter Post Build) die Einstellung aktivieren, dass dieser Job alle betreffenden Tickets kommentiert. Wichtig: Es muss für jeden Job einzeln aktiviert werden.
Der Workflow, der dahinter steckt, sieht folgendermaßen aus:
- Für jeden Build ermittelt Jenkins alle neuen Changesets auf Basis der Differenz der Revision des letzten und des aktuellen Builds.
- Aus jeder Changeset-Nachricht werden die JIRA-Ticket-IDs in Relation zur Nachricht herausgefiltert.
- In jedes Ticket wird vermerkt, wann Jenkins welches Changeset in welchem Projekt mit welchem Build integriert hat. Dies geschieht derzeit per simplen Kommentar.
- Der Vorgang wird bei einem späteren Vorgang wiederholt, falls der Build nicht erfolgreich (failed) war.
Plugin 2: Jenkins JIRA Issue Updater Plugin
Dieses etwas neuere Plugin hängt sich als ein so genannten Post Step in einen Job. Es wird vollständig im Job konfiguriert und es gibt keine globale Konfiguration.
Die Idee, die hinter diesem Plugin steckt:
- Suche mittels einer in JQL (Jira Query Language) geschrieben Anfrage eine Menge an Tickets aus.
- Aktualisiere diese Auswahl mit einem anderen JQL Update-Ausdruck.
Plugin 3: Jenkins JIRA Build Result Reporter
Mit diesem Plugin schließlich kann man — wen der interne Prozess so etwas verlangt — bei jedem fehlerhaften Build automatisch ein Ticket erzeugen lassen. „Jenkins“ erzeugt dabei sowohl ein neues Ticket und kommentiert Fortschritte eines fehlerhaften Builds auch in das (zuletzt eröffnete) Ticket. Sobald ein Build wieder erfolgreich ausgeführt werden konnte, wird das Ticket automatisch geschlossen.