Anfang diesen Jahres haben wir den Schritt gewagt und unsere Projekte von Jenkins zu Bamboo migriert. Im folgenden Artikel möchte ich einfach meine Meinung dazu teilen.

Einführung

Jenkins (bzw. Hudson) ist in der JAVA-Welt ja irgendwie der State-of-the-Art-CI-Server. So ziemlich jeder Entwickler der etwas mit Continuous Integration (CI) zu tun hat, kennt und nutzt ihn meistens auch. Daneben gibt es aber jede Menge Alternativen, z.B. CruiceControl oder TeamCity.

Auch Atlassian stellt ein eigenes Werkzeug bereit: Bamboo.

Ich kenne Jenkins jetzt schon eine kleine Ewigkeit und habe es Lieben und Nutzen gelernt. Für mich war es lange Zeit “das Tool” für CI.

Es ist frei verfügbar, es gibt jede Menge Plugins und man kann damit ungefähr alles machen. Auf der anderen Seite ist es wenig ansehnlich, die Konfiguration überladen und die Berechtigungsstruktur bzw. Prozessstruktur lässt sich auch nicht so gut und einfach abbilden.

Bamboo

Ich kannte Bamboo schon grob vom Hörensagen, hatte aber bisher keinen besonderen Grund mich damit zu beschäftigen. Zusätzlich wirkten die etwas seltsame Organisationsstruktur, sowie der Preis doch abschreckend.

Welche Vorteile bietet Bamboo?

Von dem Wechsel zu Bamboo musste ich selbst erst überzeugt werden. Warum sollte man soviel Geld für ein Tool ausgeben, wenn es doch Jenkins gibt? Mittlerweile bin ich aber großer Bamboo-Fan und würde es jederzeit Jenkins vorziehen.

Neben dem professionellen Atlassian-Support und dem Marketplace mit seinen vielen Add-Ons, sind für mich die wichtigsten Vorteile:

Plan Branches und Variablen

Das wohl genialste Feature sind Plan Branches in Kombination mit der Möglichkeit Variablen für die Pläne zu definieren. Kurz gesagt, man definiert einen Plan nur einmal, verwendet dabei Variablen für die einzelnen Aufgaben und erzeugt dann davon Branches mit anderen Konfigurationen, z.B.

Automatisch, wenn ein neuer Branch ins Repository kommt, oder
Manuell für verschiedene Versionen des Hauptprodukts.

Somit können wir beispielsweise sehr schnell feststellen, ob eines unserer Plugins noch gegen die aktuellste Version von Confluence gebaut werden kann.

Archivierung und Verwendung von Artefakten

Bei Bamboo ist es möglich, ähnlich wie bei Jenkins, Artefakte nach einem Build zu archivieren. Der entscheidende Vorteil ist allerdings, dass man diese Artefakte sehr einfach in anderen Projekten, insb. Deployment Projekten, wieder verwenden kann. Das funktioniert auch über Plan Branches hinweg, d.h. wird ein Plan Branch gebaut und es gibt einen Plan Branch mit gleichem Namen in einem anderen Projekt, dann wird automatisch das korrekte Artefakt verwendet.

Deployment Projekte

Bamboo besitzt ein explizites Konzept für Deployments. Innerhalb jedes Deployment Projekts kann man verschiedene Umgebungen angeben, z.B. Confluence 4, Confluence 5 oder TuA und Produktion. Der Vorteil daran ist, dass man die Verteilung von Artefakten sehr gut getrennt vom eigentlichen Build verwalten kann.

Die Oberfläche

Die Oberfläche empfand ich als schwierigste Hürde mit Bamboo loszulegen. Es gibt eine etwas gewöhnungsbedürftige Hierarchieebene von Projekt über Plan (die Jobs in Jenkins), Stage, Job und Task (die Build Schritte in Jenkins). Daneben gibt es nochmal Deployment Projects mit Environments und Tasks … Diese Struktur musste natürlich irgendwie abgebildet werden.

Findet man sich darin aber einmal zurecht, dann macht die Verwendung von Bamboo sehr viel Spaß und die Akzeptanz der Nutzer steigt deutlich an.

Berechtigungen

In vielen Unternehmen spielt die feine Vergabe von Berechtigungen eine besondere Rolle. In Bamboo kann man Berechtigungen einfach und feingranulär verteilen. So ist es zum Beispiel möglich, dass alle Entwickler zwar auf Integrationssysteme deployen dürfen, aber nur Mitglieder aus dem Testteam auf TuAs und Systemadministratoren auf Produktivsysteme.

Integration in Atlassian Toolstack

Wenn sowieso schon viele interne Systeme von Atlassian kommen, dann ist Bamboo der richtige Partner und integriert sich wunderbar mit JIRA, Stash und Source Tree. So sieht man in Stash z.B. ob es erfolgreiche (oder fehlgeschlagenen) Builds für einen Commit gibt.

Fazit

Der Wechsel zu Bamboo war für uns die richtige Entscheidung und wir profitieren davon:

Die Integration in den Atlassian Toolstack hilft einen besseren Überblick zu gewinnen,
Besonders für die Entwicklung von Atlassian-Add-Ons hat Bamboo sein Stärken, aber auch klassiche (Java-)Projekte lassen sich gut damit bauen und verteilen.
Subjektiv betrachtet, scheint die Akzeptanz viel höher zu sein, als bei Jenkins. Scheinbar kommen unsere Entwickler mit Bamboo leichter zurecht
Persönlich bin ich sehr von Bamboo begeistert. Es lässt sich viel einfacher Konfigurieren und Verwenden als Jenkins. Zugegebenermaßen hätte ich das am Anfang nicht gedacht.