Anfang die­sen Jahres haben wir den Schritt gewagt und unsere Projekte von Jenkins zu Bamboo migriert. Im fol­gen­den Artikel möchte ich ein­fach meine Meinung dazu teilen.

Einführung

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

Auch Atlassian stellt ein eige­nes 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 ver­füg­bar, es gibt jede Menge Plugins und man kann damit unge­fähr alles machen. Auf der ande­ren Seite ist es wenig ansehn­lich, die Konfiguration über­la­den und die Berechtigungsstruktur bzw. Prozessstruktur lässt sich auch nicht so gut und ein­fach abbilden.

Bamboo

Ich kannte Bamboo schon grob vom Hörensagen, hatte aber bis­her kei­nen beson­de­ren Grund mich damit zu beschäf­ti­gen. Zusätzlich wirk­ten die etwas selt­same Organisationsstruktur, sowie der Preis doch abschreckend. 

Welche Vorteile bie­tet Bamboo?

Von dem Wechsel zu Bamboo musste ich selbst erst über­zeugt wer­den. Warum sollte man soviel Geld für ein Tool aus­ge­ben, wenn es doch Jenkins gibt? Mittlerweile bin ich aber gro­ßer Bamboo-Fan und würde es jeder­zeit Jenkins vorziehen. 

Neben dem pro­fes­sio­nel­len Atlassian-Support und dem Marketplace mit sei­nen vie­len Add-Ons, sind für mich die wich­tigs­ten Vorteile:

Plan Branches und Variablen

Das wohl geni­alste Feature sind Plan Branches in Kombination mit der Möglichkeit Variablen für die Pläne zu defi­nie­ren.  Kurz gesagt, man defi­niert einen Plan nur ein­mal, ver­wen­det dabei Variablen für die ein­zel­nen Aufgaben und erzeugt dann davon Branches mit ande­ren Konfigurationen, z.B.

• Automatisch, wenn ein neuer Branch ins Repository kommt, oder 
• Manuell für ver­schie­dene Versionen des Hauptprodukts.

Somit kön­nen wir bei­spiels­weise sehr schnell fest­stel­len, ob eines unse­rer Plugins noch gegen die aktu­ellste Version von Confluence gebaut wer­den kann.

Archivierung und Verwendung von Artefakten

Bei Bamboo ist es mög­lich, ähn­lich wie bei Jenkins, Artefakte nach einem Build zu archi­vie­ren. Der ent­schei­dende Vorteil ist aller­dings, dass man diese Artefakte sehr ein­fach in ande­ren Projekten, insb. Deployment Projekten, wie­der ver­wen­den kann. Das funk­tio­niert auch über Plan Branches hin­weg, d.h. wird ein Plan Branch gebaut und es gibt einen Plan Branch mit glei­chem Namen in einem ande­ren Projekt, dann wird auto­ma­tisch das kor­rekte Artefakt verwendet.

Deployment Projekte

Bamboo besitzt ein expli­zi­tes Konzept für Deployments. Innerhalb jedes Deployment Projekts kann man ver­schie­dene Umgebungen ange­ben, z.B. Confluence 4, Confluence 5 oder TuA und Produktion. Der Vorteil daran ist, dass man die Verteilung von Artefakten sehr gut getrennt vom eigent­li­chen Build ver­wal­ten kann.

Die Oberfläche

Die Oberfläche emp­fand ich als schwie­rigste Hürde mit Bamboo los­zu­le­gen. Es gibt eine etwas gewöh­nungs­be­dürf­tige Hierarchieebene von Projekt über Plan (die Jobs in Jenkins), Stage, Job und Task (die Build Schritte in Jenkins). Daneben gibt es noch­mal Deployment Projects mit Environments und Tasks … Diese Struktur musste natür­lich irgend­wie abge­bil­det werden.

Findet man sich darin aber ein­mal zurecht, dann macht die Verwendung von Bamboo sehr viel Spaß und die Akzeptanz der Nutzer steigt deut­lich an.

Berechtigungen

In vie­len Unternehmen spielt die feine Vergabe von Berechtigungen eine beson­dere Rolle. In Bamboo kann man Berechtigungen ein­fach und  fein­gra­nu­lär ver­tei­len. So ist es zum Beispiel mög­lich, dass alle Entwickler zwar auf Integrationssysteme deployen dür­fen, aber nur Mitglieder aus dem Testteam auf TuAs und Systemadministratoren auf Produktivsysteme.

Integration in Atlassian Toolstack

Wenn sowieso schon viele interne Systeme von Atlassian kom­men, dann ist Bamboo der rich­tige Partner und inte­griert sich wun­der­bar mit JIRA, Stash und Source Tree. So sieht man in Stash z.B. ob es erfolg­rei­che (oder fehl­ge­schla­ge­nen) Builds für einen Commit gibt.

Fazit

Der Wechsel zu Bamboo war für uns die rich­tige Entscheidung und wir pro­fi­tie­ren davon:

• Die Integration in den Atlassian Toolstack hilft einen bes­se­ren Überblick zu gewinnen,
• Besonders für die Entwicklung von Atlassian-Add-Ons hat Bamboo sein Stärken, aber auch klas­si­che (Java-)Projekte las­sen sich gut damit bauen und verteilen.
• Subjektiv betrach­tet, scheint die Akzeptanz viel höher zu sein, als bei Jenkins. Scheinbar kom­men unsere Entwickler mit Bamboo leich­ter zurecht 😉
• Persönlich bin ich sehr von Bamboo begeis­tert. Es lässt sich viel ein­fa­cher Konfigurieren und Verwenden als Jenkins. Zugegebenermaßen hätte ich das am Anfang nicht gedacht.

Sicherlich ist Bamboo nicht für jeden was, ich kann aber jedem emp­feh­len es ein­mal aus­zu­pro­bie­ren. Es lohnt sich.