Wie migriert man von "Arcane Integration" zu Continuous Integration?

Question

Im Moment hat ein Projekt, an dem ich arbeite, einen Grad an Komplexität erreicht, der mehr als nur ein paar Schritte erfordert (eigentlich ist es obskur geworden!), um ein vollständiges/brauchbares Produkt herzustellen. Und leider haben wir nicht mit einer Continuos Integration Denkweise begonnen, so dass, wie Sie sich vorstellen können, seine Art von schmerzhaft manchmal, und an anderen kann ich leicht einen halben Tag verschwenden, um eine saubere/getestete Build zu bekommen.

Wie jedes große Projekt besteht es aus vielen Komponenten in vielen verschiedenen Sprachen (nicht nur Java oder C# im Enterprise-Stil zum Beispiel) sowie aus vielen grafischen und textuellen Ressourcen. Das Problem ist nun, dass ich, wenn ich nach Continuos Integration suche, immer Best Practices und Techniken finde, die davon ausgehen, dass man ein neues Projekt von Grund auf beginnt. Da es sich jedoch nicht um ein neues Projekt handelt, habe ich mich gefragt, welche guten Ressourcen es gibt, um proaktiv mit der Migration von Arcane Integration zu Continuos Integration zu beginnen :)

Vielen Dank im Voraus!

Answer 1

Hier ist es in zwei einfachen (hah) Schritten.

1. Entscheiden Sie sich für den wiederholbaren Aufbau:
   1. Verwenden Sie die Versionskontrolle, checken Sie den gesamten Code ein.
   2. Festlegung und Dokumentation aller für die Erstellung verwendeten Tools (insbesondere der Compiler-Version). Ein wiederholbarer Bereitstellungs- und Einrichtungsprozess für diese Tools muss vorhanden sein.
   3. Ermitteln und dokumentieren Sie eindeutig alle Ressourcen, die für die Erstellung erforderlich sind, aber nicht eingecheckt werden (Installationen von Drittanbietern, Service Packs usw.). Verfügen Sie über einen wiederholbaren Bereitstellungs- und Einrichtungsprozess für diese Abhängigkeiten.
2. Vor der Übergabe an die Versionskontrolle müssen die Entwickler
   1. ihre Arbeitskopie zu aktualisieren
   2. erfolgreich bauen
   3. automatisierte Tests durchführen und bestehen

Diese Schritte können nacheinander durchgeführt werden, sozusagen als Pfad, dem man folgen kann. Jede Stufe bringt Vorteile mit sich. Wenn Sie zum Beispiel überhaupt keine Versionskontrolle verwenden, ist es schon ein großer Fortschritt, den Code in die Versionskontrolle zu bringen (ohne irgendetwas anderes). Wenn es keine automatisierten Tests gibt, können die Entwickler sie auch nicht ausführen - aber sie können immer noch die vorherigen Übertragungen erhalten und den Compiler dazu bringen, ihre Arbeit zu überprüfen.

Wenn Sie das alles schaffen, kommen Sie an einen schönen, gesunden Ort.

Das Ziel sind wiederholbare Build-Prozesse und Entwickler, die wissen, wie sich ihre Änderungen auf den Build und andere Entwickler auswirken.

Dann können Sie die Früchte Ihrer Arbeit ernten, indem Sie für eine bessere Einhaltung der Vorschriften sorgen:

• Entwickler etablieren eine häufige Commit-Gewohnheit. Code, der sich in der Arbeitskopie befindet, sollte nie älter als 1 Tag sein.
• Der automatisierte Build-Prozess überwacht die Versionskontrolle auf Check-Ins und stellt die Ergebnisse an einem Ort bereit, an dem die Benutzer sie akzeptieren können (z. B. in einer Testumgebung, auf einer Vorschau-Website oder einfach nur als .exe-Datei an einem Ort, an dem der Benutzer sie finden kann).

Answer 2

Genauso, wie man einen Elefanten isst (ein Bissen nach dem anderen) ;-) Kontinuierliche Integration erfordert einen automatisierten Build. Beginnen Sie damit. Automatisieren Sie die Erstellung der einzelnen Teile. Ant oder NAnt ist eine großartige Möglichkeit, dies zu tun. Lassen Sie die Konstruktion jeder Komponente eine NAnt-Aufgabe sein. Dann kann Ihr gesamter Systemaufbau diese einzelnen Aufgaben zusammenfassen.

Von dort aus können Sie Aufgaben für die Bereitstellung, für Unit-Tests usw. hinzufügen. Wenn Sie eine CI-Technologie verwenden möchten, können Sie diese mit Ihrem NAnt-Build verbinden.

Answer 3

Ich würde damit beginnen, zunächst alle Schritte aufzuschreiben, die Sie für die manuelle Erstellung und Prüfung benötigen. Danach haben Sie zumindest einen Leitfaden für die alte Methode, und wenn Sie alles aufschreiben, haben Sie die Möglichkeit, es als vollständigen Prozess zu betrachten.

Dann suchen Sie nach Teilen für das Drehbuch.

Im Idealfall wollen Sie einen Build und Test von einem Code-Commit auslösen und nur die geänderten Teile neu bauen und testen, vielleicht mit einem vollständigen Build und Test pro Nacht oder Woche. Sie benötigen Protokolldateien oder Datenbankeinträge und Berichte über den Erfolg oder Misserfolg des Builds.

Sie werden vorgefertigte Produkte und Open-Source-Baukästen suchen und bewerten wollen. Sie können sicherlich alle Skripte und Berichte selbst schreiben, aber das wird eine Weile dauern und Sie werden wahrscheinlich mit einem Berichtssystem enden, das gerade gut genug ist, da Ihre Aufgabe darin besteht, das Produkt zu programmieren, nicht das Build-System :-)

Answer 4

Ich würde vermuten, dass eine Migration nicht wirklich eine Option ist - halbherzige Lösungen werden die Situation nur verschlimmern.

Mein Ansatz wäre, einen kreativen Ingenieur zu nehmen, der den Bauprozess versteht, sich mit ihm zusammenzusetzen und zu sagen: "Reparieren Sie das". Geben Sie ihm ein oder zwei Wochen Zeit.

Das Endziel wäre ein Prozess, der von Anfang bis Ende mit einem einzigen make-Befehl läuft.

Ich empfehle auch ein automatisiertes "Setup"-Verfahren, bei dem Sie einfach einen Checkout durchführen und eine Batch-Datei von einer Netzwerkfreigabe ausführen, um alle Ihre Tools zu installieren und zu erstellen. Die Zeitersparnis, die sich daraus ergibt, ist enorm, wenn Sie neue Programmierer einstellen. Die meisten Projekte benötigen ein bis drei Tage, um auf einem neuen Computer eingerichtet zu werden - und es ist immer der "neue" Programmierer, der nicht weiß, was vor sich geht, wenn er die Installationen auf seinem eigenen System durchführt...

Answer 5

Kurz gesagt: schrittweise

Wählen Sie einen Rahmen, der für die verschiedenen Projekte geeignet ist.

Fügen Sie dem Rahmenwerk nach und nach Komponenten hinzu.

Wenn Sie mit dem Framework nicht vertraut sind, sollten Sie zunächst einige der einfacheren Komponenten in Angriff nehmen, um das Risiko von Fehlern zu verringern.

Wenn Sie das Framework verstehen, sollten Sie zuerst einige der schwierigeren und/oder häufig verwendeten Komponenten in Angriff nehmen, damit Ihr Team (und die Geschäftsleitung) die Vorteile frühzeitig erkennen und die Bemühungen stärker unterstützen.

Stellen Sie sicher, dass Sie einen Plan haben, der Folgendes umfasst tous Ihrer Komponenten, denn erst dann kommt der volle Nutzen zum Tragen.

Nehmen Sie Ihr Team mit; stellen Sie sicher, dass Sie einen Konsens darüber haben, dass dies wertvoll sein wird, oder die Leute werden es nicht beibehalten, wenn sich die Komponenten ändern.