Babysitter für Ihr Continuous Integration System

Eine meiner Rollen in meinem Team ist die Build-Person . Ich bin dafür verantwortlich, unsere Build-Skripte zu pflegen / zu aktualisieren und sicherzustellen, dass wir auf dem Continuous Integration Server reibungslos aufbauen. Normalerweise stört mich dieser Job nicht, obwohl ich mich oft fühle, als würde ich ständig auf dem CI-Server babysitten.

Dieser Job kann manchmal ärgerlich sein, denn wenn der Build abbricht, muss ich die Story, an der ich arbeite, fallen lassen und den Build-Fehler untersuchen. Build-Fehler passieren täglich in unserem Team. Manchmal erstellen Entwickler einfach nicht lokal, bevor sie einen Commit ausführen, sodass Tests auf dem CI-Server fehlschlagen. In dieser Situation möchte ich schnell zu der Person gelangen, die das "Bad Commit" hatte, damit der Build nicht zu lange unterbrochen bleibt. Manchmal (viel seltener) liegt auf dem CI-Server ein seltsamer Zustand vor, der behoben werden muss.

Ich weiß, dass viele ausgereifte Teams Continuous Integration einsetzen, aber es gibt nicht viel Material zu guten Praktiken.

Zeigen meine Probleme, dass unsere kontinuierliche Integration nicht sehr ausgereift ist oder gehört dies einfach zum Job?

Welche guten Praktiken sollten befolgt werden? Was zeichnet eine ausgereifte kontinuierliche Integration aus ?

Aktualisieren

Anstatt ein paar Kommentare zu beantworten, werde ich stattdessen ein Update machen. Wir haben einen einzigen, einfachen Befehl, der genau das tut, was der Build-Server beim Erstellen der App tut. Es wird kompiliert, alle Unit / Integration und einige schnelle UI-basierte Tests ausgeführt.

Wenn man die Antworten aller liest, hat man das Gefühl, dass wir zwei große Probleme haben könnten.

1. Der CI-Server beschwert sich nicht laut genug, wenn ein Build fehlschlägt.
2. Entwickler fühlen sich nicht dafür verantwortlich, dass ihr Commit erfolgreich durchgeführt wird.

Was die Dinge in meinem Team schwieriger macht, ist, dass wir ein großes Team haben (über 10 Entwickler) UND ein paar Offshore-Teammitglieder, die sich verpflichten, wenn wir nicht einmal bei der Arbeit sind. Da das Team groß ist und wir festgestellt haben, dass häufige, kleine Einsätze bevorzugt werden, haben wir manchmal wirklich viel Aktivität an einem Tag.

In erster Linie: Jede Person ist für den Erstellungsprozess verantwortlich . Es hört sich so an, als wären die Mitglieder Ihres Teams noch nicht ausgereift ... Niemand kommt davon, Code zu schreiben und ihn an den CI-Server weiterzuleiten, in der Hoffnung, dass er funktioniert. Vor dem Festschreiben des Codes sollte dieser auf dem lokalen Computer getestet werden. Sie sollten sicherstellen, dass der Code, den Sie einchecken, den Build nicht beschädigt. Natürlich gibt es Fälle, in denen der Build unbeabsichtigt unterbrochen wurde (z. B. wenn eine Konfigurationsdatei geändert wurde oder versehentlich ein fehlerhaftes Festschreiben durchgeführt wurde).

Die meisten CI-Server (ich habe nur Hudson verwendet) senden eine automatisierte E-Mail, in der die Commits aufgeführt sind, die zum Absturz des Builds geführt haben. Der einzige Teil Ihrer Rolle besteht darin, hinter ihnen zu stehen und hart auszusehen, bis der Verdächtige das repariert, was sie kaputt gemacht haben.

Ihr Team hat eines falsch verstanden:

Die Verantwortung für den Build- Server ist nicht gleichbedeutend mit der Verantwortung für den Build .

Die Person, die den Code eincheckt, ist dafür verantwortlich, dass er "funktioniert" (für einen gewissen Wert der Arbeit). Der einzige Grund für einen Build-Server besteht darin, in diesem Prozess einen Überblick zu gewinnen. Jeder Build-Server, der es wert ist, kann die Person (en), die seit dem letzten Build Code eingecheckt hat (sowie alle anderen Interessenten), über die folgenden Informationen informieren:

• Build pleite!
• Was beim Bauen schief gelaufen ist!
• Was hat sich seit dem letzten Build geändert?

Dies geschieht sehr häufig per E-Mail. Es ist wichtig, dass dies nach jedem Check-in recht schnell geschieht.

Die Person kann dann sehen, was schief gelaufen ist, und das Problem beheben. Der Build-Server benachrichtigt dann alle Interessierten, dass der Build wieder normal ist. Dies sollte von alleine geschehen, ohne dass andere Personen, außer den Check-in-Schuldigen, involviert sind.

Zur Beantwortung Ihrer Frage: Eine ausgereifte CI-Umgebung erfordert NICHT die Einbeziehung eines Hausmeisters in den normalen Betrieb.

Auch wenn "seltsame Bedingungen" sehr häufig vorkommen, finden Sie heraus, woran es liegt, und machen Sie das System robuster.

Ändern Sie den Prozess. Wenn ein Commit den Build bricht, setzen Sie diesen Commit automatisch zurück und benachrichtigen Sie den Entwickler, der ihn brach. Es ist dumm, zuzulassen, dass ein Fehler eines Teammitglieds den Rest des Teams verlangsamt. Anstatt Integrationsbuilds automatisch ausführen zu lassen, lassen Sie die Entwickler den Integrationscomputer überprüfen. Wenn der Build erfolgreich ist, können sie ein Commit ausführen. Kontinuierliche Integration bedeutet nicht, dass Sie nach Belieben Junk-Mails einchecken und diese von jemandem für Sie reparieren lassen.

Die "Golden Branch" -Strategie funktioniert nur, wenn ein Gatekeeper für den Golden Branch vorhanden ist.

Ein DVCS wie Git könnte helfen; Anstatt ein Commit durchzuführen, kann der Entwickler lediglich ein Änderungsset zur Integration an den CI-Server senden, und der Server kann dann versuchen, das Änderungsset zu integrieren. Wenn die Integration erfolgreich ist, wird der Änderungssatz zusammengeführt, und wenn nicht, wird er abgelehnt.

Ein häufig auftretendes Problem ist, dass Entwickler keine lokalen Builds ausführen können, die genau die gleichen Schritte wie ein CI-Build aufweisen. Das heißt, der CI-Server ist so konfiguriert, dass er zusätzliche Schritte wie Einheiten- / Integrationstests, Abdeckung usw. enthält, die nicht lokal ausgeführt werden können. Unweigerlich werden Entwickler von einem der Schritte gebissen, die sie vor Ort nicht ausführen können, und werden sich fragen, warum sie überhaupt vor dem Einchecken die Mühe machen, ein Release vor Ort zu erstellen.

Ich behalte meinen gesamten Build in sich und lasse den CI-Server einfach einen Release-Build starten, für den keine fremden Konfigurationen / Schritte definiert wurden. Entwickler können einen Release - Build lokal vor ausführen , um Check-in dem alle Schritte enthält , die durch die CI Build ausgeführt wird , und weit mehr sicher sein , dass nichts bricht , wenn sie tun Check-in.

Zu den zusätzlichen Vorteilen dieses Ansatzes gehören:

• Es ist einfach, zwischen CI-Servern zu wechseln, da Sie nicht viel Zeit in die Konfiguration überflüssiger Schritte investiert haben
• Das gesamte Build-Time-Tool befindet sich in der Quellcodeverwaltung. Dies bedeutet, dass alle Entwickler genau das gleiche Toolset zum Erstellen Ihres Systems verwenden
• Zusätzlich zu dem obigen Punkt ist es einfach, das Bauwerkzeug auf kontrollierte Weise zu ändern

PS. Das ganze Babysitter-Konzept ist lächerlich, aber andere haben das behandelt.

Zunächst sollten Entwickler Builds nicht regelmäßig unterbrechen - sie sollten die Tests lokal erstellen und ausführen, bevor sie sich für den CI-Zweig verpflichten. Es sollte ein Zeichen der Schande sein, den Build zu brechen, und es ist wichtig, dies durchzusetzen. Ich habe es durch das Posten von Statistiken geschafft, und ich habe gesehen, dass andere Teams einen "Build Bag" haben, in den Sie jedes Mal, wenn Sie den Build brechen, einen Dollar investieren. Am Ende des Projekts geht das Geld in Richtung Bier.

Wenn Scham / persönlicher Stolz nicht funktioniert, müssen Sie möglicherweise auf schwerere Dinge umsteigen (z. B. drohende Kündigung). Das Abbrechen des Builds vor dem Aufbruch für den Tag sollte ein schwerwiegendes Vergehen sein. Und jeder Entwickler sollte eine Build-Status-Benachrichtigung auf seinem Desktop haben. Das Beste daran ist, dass es kleinere Commits fördert, die sowieso bevorzugt werden.

Das heißt, der Build bricht manchmal ab (z. B. aus Gründen der CI-Konfiguration). Und manchmal machen die Leute Mist und gehen für den Tag, wenn der Build kaputt ist. Aus diesem Grund sollten Sie einen Prozess anstreben, der ein schnelles und einfaches Zurücksetzen auf bekannte gute Versionen ermöglicht. Wenn Sie immer zum letzten guten Build zurückrollen können (und die zurückgerollte Version an allen erforderlichen Stellen bereitgestellt werden soll), können Sie im schlimmsten Fall eines kaputten Builds, bei dem der Schuldige für den Abend abgereist ist, einen Rollback ausführen zurück zur letzten guten Version und ihn / sie morgens anschreien.

Ich kann das Continuous Delivery-Buch nicht genug empfehlen . Wenn Sie eine Anleitung zur Reifung Ihres CI-Prozesses suchen, probieren Sie es aus.

Ich habe von einer Sache gehört, die Microsoft (vielleicht?) Tut, nämlich die Rolle eines Babysitters, der sich im Team bewegt. Die Art und Weise, wie sie dies tun, ist, dass wenn jemand den Build bricht (was wahrscheinlich das Einchecken von etwas beinhaltet, das seine Tests nicht besteht), sie die Rolle übernehmen. Dadurch sind die Menschen auf sehr direkte Weise für die Folgen ihres Handelns verantwortlich. Und da es eine etwas nervige Aufgabe ist, ermutigt es sie, den Build nicht noch einmal abzubrechen.

Die Person, die derzeit für den Build verantwortlich ist, könnte einen speziellen Hut haben. Es könnte eine Zeremonie für die Übergabe geben.

Beachten Sie, dass, wie Thorbjørn sagt, die Verantwortung für den Build nicht mit der Verantwortung für den Build-Server identisch ist. Die Verantwortung für den Server kann permanent bei einem oder mehreren Mitgliedern des Teams liegen, während die Verantwortung für den Build wechselt.

Nun, abgesehen von den Details des Prozesses, werde ich mich dem Chor der Leute anschließen, die Bestürzung über Entwickler ausdrücken, die einchecken, ohne einen Build und Test ausgeführt zu haben. Inakzeptabel!

Wenn Sie einige Mitglieder des Teams haben, die mit größerer Wahrscheinlichkeit den Build brechen (und aufgrund meiner eigenen Erfahrung denke ich hauptsächlich an die Mitglieder in einem anderen Land), und wenn Sie eine nette moderne Quellcodeverwaltung wie Mercurial verwenden oder Git, Sie könnten sie in einen anderen Zweig als den Rest des Teams einchecken lassen, einen separaten CI-Prozess für diesen ausführen und Änderungen von diesem Zweig nach einer erfolgreichen Erstellung automatisch in den Trunk zusammenführen lassen (beachten Sie, dass dies erforderlich wäre) Führen Sie einen zweiten Build aus und testen Sie ihn nach dem Zusammenführen, bevor Sie das Zusammenführen einchecken!). Da das automatische Zusammenführen nicht immer erfolgreich ist, muss der Zweig möglicherweise manuell bearbeitet werden, was sehr schmerzhaft sein kann. Könnte weniger schmerzhaft sein, als den Code für den Rest des Teams eingecheckt zu haben.

Wie Jonathan Khoo sagte, sollten Sie alle für den Build-Server und das Build-Skript verantwortlich sein. Es gibt drei Gründe:

1. Im Moment liegt ein "Bus von 1" vor, was bedeutet, dass das gesamte Wissen über den Build-Server und die Build-Skripte verloren geht, wenn Sie von einem Bus überfahren werden.
2. Die Skripte, die Sie (zu Recht oder zu Unrecht) geschrieben haben, hatten nur Ihre Eingabe. Genau wie bei jedem Code ist die Wissensbasis, die darauf angewendet werden kann, umso breiter, je mehr Personen involviert sind.
3. Schließlich, wenn etwas schief geht, spürt nur Sie den Schmerz. Schmerz ist eine gute Sache, aber nicht, wenn er isoliert ist. Im Moment haben Sie es mit dem Schmerz zu tun, aber wenn alle anderen den Schmerz hatten, würden Sie feststellen, dass sie den Code vor dem Festschreiben möglicherweise strenger testen.

Ich bin selbst sehr mit CI befasst und tappe in die Falle, derjenige zu sein, der die Skripte verwaltet, aber hier sind ein paar Dinge, die Sie tun können, um das zu mildern.

1. Erstellungsskripte sollten nicht nur auf den CI-Servern, sondern auch auf lokalen Entwicklungscomputern ausgeführt werden. Sie sollten dieselben Ausgaben produzieren, dieselben Tests ausführen und aus denselben Gründen fehlschlagen. Auf diese Weise können Entwickler das Skript ausführen, bevor sie ihren Code festschreiben.
2. Wenn jemand den Build bricht, machen Sie ihn mithilfe von Popups, E-Mails, Blinklichtern, Geräuschen usw. in der Taskleiste öffentlich. Dies dient nicht nur dazu, die Teammitglieder in Verlegenheit zu bringen, sondern bietet auch allen anderen Teammitgliedern die Möglichkeit, aufzuspringen und zu arbeiten helfen.
3. Vermeiden Sie für eine Weile, den Build zu reparieren. Lassen Sie es von jemand anderem tun. Wenn sonst niemand aufspringt, warten Sie, bis schlimme Dinge geschehen, und nutzen Sie es als Lernziel für das gesamte Team, um zu verstehen, warum der CI-Server wichtig ist.
4. Versuchen Sie, Ihren Build-Server und Ihre Entwicklungscomputer so weit wie möglich frei von installierten Komponenten von Drittanbietern zu halten, und halten Sie insbesondere den GAC sauber. Verlassen Sie sich darauf, dass sich Komponenten von Drittanbietern im Projektbibliotheksordner befinden. Dies hilft, fehlende Komponenten schneller zu identifizieren.

Die Sichtbarkeit wird Ihnen helfen. Alle Teammitglieder müssen wissen, dass es ein aktives Problem gibt, das sie beheben sollten. E-Mail-Benachrichtigungen sind nützlich, aber wenn ein Entwickler beschäftigt ist und nicht sofort darauf reagiert, wird er es wahrscheinlich vergessen und die E-Mail wird in einem riesigen Benachrichtigungsstapel landen.

Sie können versuchen, Tools wie Catlight oder BuildNotify zu verwenden . Sie zeigen den aktuellen Status der wichtigen Builds im Tray-Bereich. Jedes Mal, wenn der Entwickler auf die Uhr schaut, wird er feststellen, dass ein Build kaputt ist, der repariert werden muss.

Catlight zeigt auch, wer den Build zuerst abgebrochen hat und übt sozialen Druck auf diese Person aus, da das gesamte Team dies bei jedem fehlgeschlagenen Build sieht.

Eine Strategie besteht darin, viele kleine Zweige für viele kleine Projekte zu verwenden. Wenn dann jemand den Build bricht, bricht er den Build nur für sich. Sie erhalten die genervte E-Mail vom Build-Server, und es liegt an ihnen, sich darüber Gedanken zu machen.

Eine andere besteht darin, die Verantwortung der Menschen zu verbessern. Wenn Sie zum Beispiel so etwas wie Rietveld verwenden , können sich die Leute nicht verpflichten, ohne die Peer Review zu bestehen. (Der Prozess in der Praxis ist viel leichter als Sie denken. Aber er zwingt die Leute dazu, "Pipelines" zu erstellen und an mehreren Dingen gleichzeitig zu arbeiten.) Die Aufrechterhaltung des Builds liegt in der Verantwortung sowohl des Verfassers als auch der Prüfer. Wenn jemand entweder regelmäßig den Build bricht oder Dinge genehmigt, die den Build brechen, lassen Sie ihn keine endgültigen Genehmigungen für Commits erteilen. Kombinieren Sie dies mit einem Prozess, bei dem jeder Änderungen leicht rückgängig machen kann und der Build nicht so oft abbricht und nicht unterbrochen bleibt, sobald die Änderung vorgenommen wurde.

Ich werde hier mit dem Refrain brechen und sagen, dass es nicht so schlimm ist, den Build gelegentlich zu brechen, da es zeigt, dass tatsächlich gearbeitet wird. Ja, Entwickler sollten vor dem Festschreiben erstellen und testen, aber die Hauptlast für das Testen sollten die Entwicklungsautomatisierungstools, einschließlich des Continuous-Integration-Servers, tragen. Die Werkzeuge sind da, um benutzt zu werden, und wenn der Build nicht ab und zu abbricht, ist es nicht klar, dass Sie so viel Druck ausüben, wie Sie könnten. Ich bin jedoch der Meinung, dass der Build niemals für längere Zeit unterbrochen werden sollte, und würde sogar automatische Rollbacks oder einen mehrstufigen Festschreibungsprozess bevorzugen, wenn dies dazu beiträgt, die beiden Ziele des schnellen Feedbacks von zentralisierten, automatisierten Testeinrichtungen zu unterstützen. plus einen "grünen" Kofferraum.

Zu beachtende Dinge für Paare:

1. Ihr Team benötigt eine Reihe von Standards, die eingehalten werden müssen
2. Sie müssen das Management mit der Idee sauberen Codes vertraut machen und nach verbesserten Code-Praktiken streben.
3. Test test test! Testen Sie immer, bevor Sie einchecken.
4. Obwohl ich damit einverstanden bin, dass es in Ordnung ist, den Build zu unterbrechen, ist dies eine seltene und ich meine extrem seltene Gelegenheit, die akzeptabel wäre. Wenn dies täglich ist, würde ich nach der Tür suchen oder mit meinem Chef über Standards sprechen.

Insgesamt müsst ihr Standards auf der Grundlage von Best Practices aufstellen und aufschreiben und nicht eure Praktiken einzeln (offensichtlich funktionieren diese nicht). Sobald sich alle auf Standards geeinigt haben, beginnen Sie mit der Codeüberprüfung und der Durchsetzung von Standards. Es hört sich fast so an, als wäre das Management in den Urlaub gefahren und nie zurückgekommen. Das sind Dinge, die ehrlich gesagt für jeden Laden ziemlich einfach sind. Die Grundlage für guten Code sind gute Standards, die den Code des Teams und dessen Schreibweise bestimmen. Nur meine Gedanken. Ich bin kürzlich bei meinem neuen Job in eine ähnliche Situation geraten und habe mit meinem Chef gesprochen. Erklärt ihm, wir müssen XYZ vervollständigen, weil es ABC betrifft. Zwei Wochen später schrieb ich eine Liste der zu befolgenden Codestandards und präsentierte sie. Gefolgt von meinen Mitarbeitern, die dort Input gaben, und ungefähr 2 Monate später hatten wir Standards, die Tonnen von Problemen lösten.