Wie ist die kontinuierliche Integration in großen Unternehmen organisiert?

In meinem Unternehmen ist es üblich, keine Zwischenerstellung durchzuführen, um zu überprüfen, wie jeder Feature- / Bugfix-Zweig in dev zusammengeführt wird. Es gibt nur tägliche Builds, die immer viele Testfehler und Buildfehler auslösen. Mir wurde gesagt, dass es nicht zumutbar ist, für jede Zusammenführung über 1000 Entwickler zu erstellen.

Also habe ich gesucht, wie CI in Unternehmen organisiert ist, die so viele Entwickler oder mehr haben (Microsoft, Facebook), und nichts gefunden. Vielleicht können mir Insider das dann sagen?

Es ist im Grunde ein Skalierungsproblem. Sie unterteilen Ihre Arbeit in Module, bei denen es sich um unterschiedliche Projekte und / oder unterschiedliche Funktionen Ihres Produkts handeln kann.

Sie hätten Teams, die Sätze dieser Module abdecken. Jedes dieser Teams würde CI-Zyklen für seine Bereiche einrichten, und erst nachdem ihre jeweiligen Zyklen verstrichen wären, würde der Code an Master-Repos weitergeleitet, wo der Master-CI-Zyklus ausgeführt würde.

Der Master-CI-Zyklus unterscheidet sich höchstwahrscheinlich in folgenden Aspekten von CI-Zyklen auf Teamebene:

• CI-Zyklen auf Teamebene müssen nicht den Code des gesamten Unternehmens erstellen, sondern nur die Module, für die sie verantwortlich sind, und die abhängigen Module. Wenn es zwei Module gibt, die völlig unabhängig sind und sich in verschiedenen Teams befinden, sind sie nicht Teil des CI-Zyklus des anderen Teams.
• CI-Zyklen auf Teamebene können viel detailliertere automatisierte Tests enthalten als Master-CI-Zyklen. Der Master-CI-Zyklus verfügt über Sanity-Check-Tests und Regressionstests, die je nach Größe der Master-Lösung täglich oder sogar wöchentlich ausgeführt werden, da die Ausführung dieser Tests manchmal mehr als 24 Stunden dauern kann.

Mit diesem Ansatz müssen Sie einen automatisierten Push von lokalen Repos zu zentralem Repo bereitstellen, sobald der lokale CI-Zyklus abgelaufen ist, damit Ihre Entwickler nicht enorm viel Zeit damit verbringen, den Code auf zentrale Repos zu übertragen.

Zusätzlich zu dem, was @Vladimir_Stokic gesagt hat, bauen wir in einigen Teams (mein Team hat ~ 150 Entwickler) häufiger als alle 24 Stunden. Immer wenn ein Commit auftritt, starten wir einen 5-Minuten-Timer. Nach Ablauf der 5 Minuten werden alle Commits, die während des 5-Minuten-Intervalls aufgetreten sind, kombiniert und erstellt. Der Build ist normalerweise ein inkrementeller Build. Wir haben einen separaten Builder, der Unit-Tests für jeden auftretenden Build ausführt. Wenn nach Abschluss des Builds während des Builds weitere Commits aufgetreten sind (was je nach Änderung zwischen 1 und 45 Minuten dauert), werden alle ausstehenden Änderungen erstellt und so weiter. Wir haben auch einen nächtlichen (sauberen, vollständigen) Build, aber die Builds, die bei jedem Commit (ungefähr) durchgeführt werden, sagen uns sehr schnell, ob Tests fehlschlagen.