Ich denke, jede Meinung darüber, wie Sie Builds verwalten, hängt davon ab, was Sie in Ihrem Prozess schätzen und das ist nicht klar aus Ihrer Frage.
Als beiseite; Die meisten Build-Systeme benötigen keinen eindeutigen Build für jedes Commit. Wenn Sie innerhalb Ihres Abfrageintervalls mehrere Commits für die Entwicklung haben, sollten Sie sie alle als einen Build testen/bereitstellen können. Das könnte gut oder schlecht für dich sein.
Continuous Integration
Continuous Integration sollten Sie einen glattere und schnelleren Entwicklungsprozess mit der Gewissheit, dass Ihr Projekt in einem lösbaren Zustand ist (oder zumindest seine eigenen Tests vorbei, hoffentlich das ist das gleiche). Ich habe festgestellt, dass manuelle Builds routinemäßig nicht dasselbe Qualitätsniveau durchsetzen. Es ist allzu leicht, brechende Änderungen zu begehen, die "wissen", dass es vor dem nächsten manuellen Build behoben wird, das dann immer weiter wegrutscht oder wenn ein Build scheitert, ist plötzlich unklar, welche von mehreren Änderungen den Fehler verursacht hat. Für die kontinuierliche Integration würde ich nicht nur automatisierte Builds Ihres Entwicklungszweiges erwarten, sondern auch automatisierte Builds aller Feature-Zweige, die zeigen, dass sie Ihre Tests bestehen, bevor sie in die Entwicklung einfließen.
In vielen Umgebungen ist es möglich, dass die Kosten für einen CI-Build im Vergleich zu den Kosten für die Entwicklerzeit vernachlässigbar sind. Zum Beispiel schaue ich mir gerade ein Projekt an, das in den letzten 4 Jahren ungefähr 5 aktive Committer und nur 12 Builds pro Tag aufweist. Es ist nicht einfach, Tests schnell und zuverlässig durchzuführen, aber es sollten viele Builds (gleichzeitig bei Feature-Zweigen) laufen.
Es gibt Umgebungen, in denen der Prozess zum Testen eines Builds nicht billig oder schnell sein kann, z. Sie müssen Hardwaretests oder Leistungstests durchführen, die Stunden dauern. In diesen Fällen benötigen Sie einen anderen Ansatz, aber Sie sind wahrscheinlich auch nicht in der Lage, kontinuierliche Integration zu üben, und Ihre Entwicklungs-/Verzweigungsstrategie sollte dies widerspiegeln.
Kontinuierliche Lieferung
kontinuierliche Lieferung geht einen Schritt weiter und verkürzt die Zykluszeit von der Entwicklung auf Veränderungen Erreichen Ihrer Benutzer durch alle diejenigen, die Bereitstellung von lösbaren aufbaut. Wenn es einen manuellen Schritt beim Freigeben (oder Zurücksetzen) dieser Builds gibt, dann sollten Sie Ihren Prozess nicht als "Continuous Delivery" bezeichnen.
Sie können einen sehr guten automatisierten Bereitstellungsvorgang durchführen, ohne dass dieser fortlaufend ist. Kontinuierliche Lieferung kann für einige Produkte sehr wertvoll sein, kann aber auch störend sein und für andere schlecht sein. Zum Beispiel werden wir derzeit kontinuierlich in einer Consumer-Web-App eingesetzt. Wir pflegen auch Backend-Operations-Tools, bei denen wir konservativer vorgehen, wann wir neue Funktionen veröffentlichen (oder zumindest wenn neue Funktionen aktiviert werden), da Änderungen an diesen Tools neue Workflows einführen können, die nicht ohne Warnung in der Schicht von jemandem erscheinen sollen .
tl; dr
alles automatisieren, nicht langsam Ihr Team nach unten, indem Sie versuchen, die Anzahl der baut klein zu halten.