Ich habe immer Builds nach jedem Commit gestartet, aber bei diesem neuen Projekt haben mich die Architekten gebeten, die Frequenz auf "alle 15 Minuten einen Build" zu ändern, und ich kann einfach nicht verstehen, warum das ein guter Grund gegen "ist aufbauend auf jedem Commit ".
Zunächst einige Details:
- Objective-C (iOS 5) -Projekt
- 10 Entwickler
- Jeder Build dauert ca. 1 Minute und beinhaltet Build- und Unit-Tests.
- Der Integrationsserver ist ein Mac Mini, daher ist die Rechenleistung hier kein wirkliches Problem
- Wir verwenden Jenkins mit dem XCode-Plugin
Meine Argumente waren, dass Sie, wenn Sie bei jedem Commit bauen, sofort sehen können, was schief gelaufen ist, und Ihre Fehler direkt korrigieren können, ohne die anderen Entwickler zu oft zu stören. Außerdem wird unser Tester auf diese Weise weniger von UT-Fehlern gestört. Seine Argumente waren, dass Entwickler von "Build Error" -Mails überflutet werden (was nicht ganz richtig ist, da Jenkins so konfiguriert werden kann, dass nur für den ersten fehlerhaften Build eine Mail gesendet wird) und dass Metriken nicht ordnungsgemäß durchgeführt werden können, wenn die Häufigkeit stimmt der Builds ist zu hoch.
Wie ist Ihre Meinung dazu?
quelle
Antworten:
Ein schnelles Fehlschlagen ist ein gutes Prinzip - je früher Sie wissen, dass der Build beschädigt ist, desto eher kann das fehlerhafte Commit identifiziert und der Build behoben werden.
Auf jedem Commit aufzubauen ist das Richtige.
Das Erstellen alle 15 Minuten kann sinnlos sein, wenn das Projekt innerhalb eines solchen Zeitraums ein hohes Commit-Volumen aufweist. Das Aufspüren des fehlerhaften Commits würde länger dauern und ist möglicherweise schwer zu bestimmen (es kann auch vorkommen, dass mehrere Commits unterschiedliche Eigenschaften haben) Bau abbrechen). Es besteht auch die Möglichkeit, dass Sie in ruhigen Zeiten (nachts?) Eine Wiederherstellung durchführen, obwohl keine Änderungen vorgenommen wurden.
Wenn der Build so oft abbricht, dass es ein Problem darstellt, sollten Sie das Team über die Wichtigkeit, den Build nicht abzubrechen, und über Techniken informieren, die dies verhindern (häufiges Abrufen, Einchecken, Kompilieren und Ausführen von Komponententests) vor Ort etc ...).
quelle
Es ist buchstäblich sinnlos, alle 15 Minuten einen Build zu erstellen, wenn sich nichts geändert hat. Aber es gibt auch keinen Nachteil, afaik, Jenkins werden nur beim Scheitern und dann beim Erfolg per E-Mail benachrichtigt und nicht alles dazwischen (z. B. 10 Scheitern).
Wir machen es bei jedem Commit. Wir fragen das Repository jedoch alle fünfzehn Minuten ab und prüfen, ob Änderungen vorliegen, auf die sich Ihre Kollegen beziehen.
Sie erwarten, dass Ihre 10 Entwickler mehr als einmal alle fünfzehn Minuten einen Commit durchführen? Das klingt eher nach einer hohen Einschätzung. 10 Entwickler bedeutet, dass nach jeweils 150 Minuten dieselbe Person erneut einen Commit ausführt, das sind also 2,5 Stunden. An einem durchschnittlichen Tag macht jeder Entwickler also drei Commits. Persönlich mache ich ein Commit ~ 2 Tage ... manchmal mehr, manchmal weniger.
quelle
Entwickler werden mehr mit E-Mails überflutet, wenn dies nur alle 15 Minuten geschieht. Das liegt daran, dass es nicht mit Sicherheit wissen wird, wer den Build gebrochen hat und somit mehr Leute verschickt.
Wenn es sich bei Metriken wirklich um ein Problem handelt - was ich nicht sagen kann, weil ich nicht weiß, mit welchen Metriken es ihrer Meinung nach ein Problem gibt -, können Sie jederzeit einen anderen Job zum Sammeln der Metriken ausführen.
quelle
Möglicherweise sollte die Anforderung " höchstens einmal pro 15 Minuten erstellt werden". Dies kann bei Projekten mit sehr häufigen Commit-Aktivitäten (dh mehreren Commits innerhalb weniger Minuten) und möglicherweise langen Build-Zeiten sinnvoll sein. Natürlich hängt es auch davon ab, wie die Builds verwendet werden. Für Tester kann es etwas verwirrend sein, innerhalb von 15 Minuten mehrere Builds zu erhalten ...
Aber ich stimme zu, dass es keinen Sinn macht zu bauen, wenn sich nichts geändert hat.
quelle
Einige Entwickler möchten Commits auf eine Weise ausführen können, bei der die Dateien, die zu einer Funktionsänderung gehören, nicht in einer einzigen atomaren Prozedur festgeschrieben werden. Sie benötigen zwei oder drei Minuten, um ein "logisches Commit" durchzuführen, das aus einigen "physischen Commits" besteht. Dies ist normalerweise der Fall, wenn Ihre Entwickler direkt ein Commit für ein zentrales Repository ausführen und kein DVCS verwenden.
In diesem Fall empfiehlt es sich, Ihren CI-Server nach dem letzten Festschreiben einige Zeit warten zu lassen, bevor Sie mit einem neuen Build beginnen. Aber 15 Minuten scheinen eine sehr hohe Zahl zu sein, 5 Minuten oder weniger sollten ausreichen.
Oder, besser (!), Versuchen Sie, Ihre Entwickler dazu zu bringen, nur in kleinen Portionen zu arbeiten, nur eine Sache zu einem Zeitpunkt, was es viel einfacher macht, nur "funktionale vollständige" physische Festschreibungen zu machen. Dann funktioniert ein Build nach jedem Commit problemlos.
quelle
Selbst wenn Sie Jenkins so eingerichtet haben, dass es auf einem Commit der Quellcodeverwaltung für ein Projekt oder eine seiner Abhängigkeiten aufbaut, hindert dies einen Entwickler nicht daran, das Artefakt-Repository bereitzustellen, ohne sich zunächst der Quellcodeverwaltung zu unterziehen. Wenn sie eine unkoordinierte API-Änderung oder einen Fehler in Abhängigkeit vom Artefakt-Repository bereitstellen, kann dies Ihren Build unterbrechen, ohne den Jenkins-Job auszulösen. Ich persönlich würde gerne so schnell wie möglich davon erfahren.
Idealerweise würden Sie für jedes Commit einen Zeitplan erstellen, um nach Situationen zu suchen, die ich gerade beschrieben habe. Dies würde konzeptionell bedeuten, dass Sie mindestens einmal alle 15 Minuten erstellen .
Wenn Sie Ihre Jenkins-Jobs so eingerichtet haben, dass sie auf Bereitstellungen von Abhängigkeitsartefakten ausgeführt werden (und wenn Sie dies tun ... Bravo), können Sie die geplante Erstellung prüfen, wenn Ihre Komponententests solide sind (dh sie testen die Abhängigkeiten nicht) und Ihre Integrations- / Funktionstests gehören nicht zum Job von Jenkins.
Was das Problem der "Flut mit E-Mails" angeht, finde ich es gut, wenn E-Mails bei einem kaputten Build überflutet werden. Stellen Sie sicher, dass Sie Entwickler zwingen, auf die E-Mail mit einer Beschreibung zu antworten, und Sie werden feststellen, dass Ihre kaputten Builds weit untergehen. Vertrauen Sie mir.
quelle
Sie sagten, Sie können ihre Argumentation nicht verstehen, also müssen Sie sie fragen. Raten Sie nicht einfach, was sie wollen, und versuchen Sie, dies umzusetzen, und setzen Sie erst recht nicht das um, wonach sie gefragt haben, ohne zu verstehen, warum sie danach gefragt haben.
Zur Beantwortung der allgemeinen Frage kommt es jedoch auf die von Ihnen verwendete Entwicklungsphilosophie an. Wenn erwartet wird, dass jedes Commit funktioniert, sollte jedes Commit getestet werden. Wenn Sie ein DVCS mit der Philosophie verwenden, dass jeder Push funktionieren sollte, testen Sie jeden Push.
Im Allgemeinen ist es besser, den Leuten etwas zu erzählen, was sie nicht wissen, als zu wiederholen, was sie wissen. Wenn sie beispielsweise die Anzahl der redundanten E-Mails reduzieren möchten, ändern Sie die E-Mail-Einstellungen und nicht die Erstellungshäufigkeit.
quelle