Atlassians Continuous-Integration-Server Bamboo ist in der neuen Version ausgeliefert worden. Mit ressourcenschonenden Triggern aus Stash, der Möglichkeit, Deployment-Projekte zu klonen, und der Option, Agents direkt bestimmten Projekten, Plänen und Jobs zuzuweisen, unterstützt Bamboo 5.6 Continuous Integration auf Enterprise-Skala. Das sind die Highlights.
Einfache Trigger via Stash
Jedes große Software-Unternehmen ist anders, aber eines haben sie gemeinsam: viele, viele Code-Repositories. Zumeist kommt es zu Builds, wenn der CI-Server an Repos Änderungen feststellt. Und hier kommt die Performance des CI-Systems ins Spiel: Jede Minute hunderte Repos abzufragen, geht an die Ressourcen.
Teams, die Bamboo und Stash verknüpfen, lassen dieses Problem nun hinter sich. Stash benachrichtigt Bamboo, sobald eine Änderung in ein Repository gepusht wurde. Keine Abfragen, keine Webhooks, keine spezielle Repository-Konfiguration sind erforderlich.
Viele Teams, die Bamboo und Stash gemeinsam nutzen, dürften von diesem neuen Trigger bei den meisten (oder sogar allen) Builds profitieren. Eine Bulk-Update-Funktion für Trigger ist verfügbar und ermöglicht es, Git zu skalieren, ohne die Server-Last zu skalieren.
Klonen für Deployments
Eine große Unterstützung für skalierbare CI ist das Klonen für Deployments. Bamboo 5.6 unterstützt das Klonen kompletter Deployment-Projekte oder das Klonen der Deployment-Tasks und -Einstellungen für eine einzelne Umgebung.
Geht es darum, Continuous-Delivery-Pipelines für eine Menge von Applikationen zu konstruieren? Teams können ein Basis-Deployment-Projekt aufsetzen und es als klonbares Template nutzen. Eine neue Testumgebung soll einem bestehenden Projekt hinzugefügt werden? Man klont einfach die Konfigs für eine bestehende Umgebung und alle Aufgaben, Variablen, Trigger usw. werden rüber kopiert – die Zeit fürs Aufsetzen reduziert sich um die Hälfte oder mehr.
Agent-Zuweisung
Das Bamboo-Team ist bei der Weiterentwicklung von Bamboo auf einige zentrale Herausforderungen von Kunden eingegangen. Bei wirklich kritischen Builds können es sich Teams nicht leisten, diese in der Warteschlange stehen zu lassen; es soll sichergestellt werden, sie in dem Moment, in dem sie getriggert werden, auszuführen. Größere Kunden haben mitunter das Problem, dass sie neue Server angeschafft haben, die als Build-Agents genutzt werden sollen – und wenn sie gebraucht werden, führen sie gerade Builds von anderen Projekten aus.
Bamboo 5.6 schlägt zwei Fliegen mit einer Klappe und löst beide Probleme. Jeder Agent lässt sich speziellen Projekten, Plänen und Jobs auf der CI-Seite zuweisen oder spezifischen Projekten und Umgebungen auf der Deployment-Seite. Und das ist beliebig kombinierbar und dadurch ausgezeichnet für Continuos-Delivery-Pipelines. Ein Build-Plan und all die Umgebungen, in die er deployt wird, können exklusiv von einem einzelnen Agent bedient werden (oder auch von mehreren dezidierten Agents, wenn Build-Jobs parallel laufen sollen).
Bamboo einführen und/oder lizenzieren? Wir sind Ihr Partner!
Interessieren Sie sich für Bamboo von Atlassian als Integrations-Server? Wir sind offizieller Atlassian-Vertriebspartner und einer der größten Atlassian Experts Partner weltweit: Gerne beraten wir Sie und unterstützen Sie bei der Lizenzierung. Bitte sprechen Sie uns an.
Ausführliche Infos über Bamboo, seine Features und sein Lizenzmodell in unserer Infothek
Bamboo: Wie viele Build Agents braucht mein Projekt?
Continuous Integration: Zehn Argumente für Bamboo
Tipps für Bamboo in DVCS-Teams
