Wie kann eine kontinuierliche Integration für sehr große Projekte / Teams skaliert werden?

Herkömmlicherweise überwachen CI-Systeme nur die Qualität des Codes in einem Integrationszweig und signalisieren, wenn Regressionen auftreten. Für Reparaturen ist menschliches Eingreifen erforderlich.

Mit zunehmender Anzahl von Entwicklern, die an derselben Branche arbeiten, steigt das Risiko von Brüchen / Blockierungen. Schließlich wird ein Punkt erreicht, an dem durchschnittlich zu dem Zeitpunkt, an dem ein Bruch behoben wird, ein neuer auftritt - der Fortschritt auf dem Zweig wird praktisch vernachlässigbar.

Die Aufteilung in mehrere Teams, die jeweils an einem separaten Integrationszweig arbeiten und zu einem späteren Zeitpunkt zusammengeführt werden, kann hilfreich sein, verlängert jedoch die Projektdauer erheblich, da die erforderliche Integration lediglich für einen späteren Moment verzögert wird, während Abwanderung / Lärm / technische Abteilung hinzugefügt werden Die teilweise Integration aus einzelnen Branchen verschmilzt. Die Kosten steigen auch aufgrund von CI-Setups für jede Niederlassung, jede mit ihren eigenen Build- / QS-Ressourcen usw. Und die Gesamtqualität ist nicht unbedingt besser.

Skalierbarkeit ist bestenfalls zweifelhaft.

Gibt es eine Methode, um so große Projekte tatsächlich skalieren zu lassen?

Ja, aber es geht darum, die Dinge, die Sie in Ihrer Frage erwähnen, so weit wie möglich zu verhindern. Sie haben Recht, dass es nur so viele Entwickler gibt, die an demselben Code arbeiten können, bevor die Dinge nicht mehr verwaltet werden können. Sie benötigen jemanden oder etwas, das einen Überblick über alle Änderungen hat und sicherstellt, dass die Integration ordnungsgemäß funktioniert und keine Regression auftritt. Dies ist schwer zu skalieren, wenn alles in einem Repository geschieht.

Bevor Sie mit der Arbeit beginnen, müssen Sie die Funktionen so trennen, dass sie später ohne großen Aufwand integriert werden können. Dies bedeutet, dass Sie die Funktionalität in Teile aufteilen möchten, die unabhängig sind oder zumindest so wenig Abhängigkeiten wie möglich aufweisen. Wie Sie dies tun, hängt stark von dem Produkt ab, das Sie entwickeln. In der Vergangenheit wurde die Funktionalität durch die Erstellung verschiedener Bibliotheken getrennt. Der Nachteil dabei ist, dass Sie eine gute Methode zum Verwalten dieser Bibliotheken benötigen. Alte Windows-Versionen hatten zum Beispiel ein schlechtes Bibliotheksverwaltungssystem, das die berüchtigte DLL-Hölle verursachte . Heutzutage sind Mikrodienste ein beliebter Weg, dies zu tun, obwohl dies auch Nachteile hat (z. B. Kommunikationsaufwand, mehr zu überwachende Dienste).

Wenn eine Trennung aufgrund der Funktionalität schwierig ist, kann eine andere Option darin bestehen, die Entwicklung rechtzeitig zu trennen. Anstatt dass mehrere Teams gleichzeitig an vielen verschiedenen Funktionen arbeiten, haben Sie 1 Team, das jeweils nur an einer oder wenigen Funktionen arbeitet.

Wenn eine Trennung der Arbeit nicht möglich ist, benötigen Sie Tools und Tests, die sicherstellen, dass die Dinge aufeinander abgestimmt sind. Automatisierte Unit- und Integrationstests können hier eine große Hilfe sein, aber letztendlich gibt es Grenzen, wie groß ein Projekt oder Team sein soll.

Mit zunehmender Anzahl von Entwicklern, die an derselben Branche arbeiten, steigt das Risiko von Brüchen / Blockierungen. Schließlich wird ein Punkt erreicht, an dem durchschnittlich zum Zeitpunkt der Behebung eines Bruchs ein neuer auftritt

Während der erste Teil des Satzes wahrscheinlich statistisch korrekt ist, stimme ich dem zweiten nicht zu.

CI- und Integrationszweige können GIGO (Garbage-In-Garbage-Out) nicht besiegen. Wenn die Entwickler keine Disziplin haben, werden Sie in einem angehaltenen Zweig enden, aber Tests für Integrationszweige sollten nur als Lat-Barriere fungieren, nicht als erste.

Entwickler sollten geeignete Codierungsstandards, Codeüberprüfungen, lokale Komponententests und möglicherweise Verzweigungstests vor der Integration verwenden, um Kollisionen weniger wahrscheinlich zu machen.

Ich arbeite täglich an einem solchen System mit Hunderten von Mitwirkenden und überraschenderweise ist es ungewöhnlich, dass es hängt.

Ich habe nicht genügend Daten, aber es kann sein, dass die Kosten hoch sind. Andererseits ist es schwierig, die alternativen Kosten für späte Integration und Fehler zu beurteilen.

Ein anderer Ansatz besteht darin, auf ein anderes, nicht traditionelles CI-System umzusteigen , das Regressionen verhindern kann , indem die beleidigenden Kandidatenänderungen vor ihrem Festschreiben identifiziert und zurückgewiesen werden, anstatt Regressionen zu erkennen und auf die Wiederherstellung zu warten, während die Entwicklung in der Verzweigung blockiert ist. Ich nenne ein solches System gerne ein nicht blockierendes CI-System .

Für eine solche Garantie reicht es nicht aus, nur die vom Entwickler ausgeführten Anforderungen für die Überprüfung vor dem Festschreiben zu erhöhen, um die Regression der Zweige zu reduzieren. Dies kann tatsächlich zu einer Erhöhung der Regressionsrate führen : längere Überprüfungszeiten => höhere Anzahl von Änderungen, die gleichzeitig isoliert überprüft werden (ohne sich gegenseitig zu berücksichtigen) => höheres Risiko für Funktionskonflikte und Interferenzen. Ich erkläre dies etwas ausführlicher in der Erweiterung der Pre-Commit-Überprüfungsabdeckung, um unseren Mythos der Zweigstabilität zu verbessern .

Das CI-Tool muss natürlich auch skalierbar sein. Und solche Tools gibt es, siehe Gibt es ein CI-Tool, das keine Regressionen in der Qualitätsstufe der Branche garantiert?

^{Offenlegung: Ich bin mit dem in den obigen Links genannten Unternehmen verbunden.}