it-swarm.com.de

Einfache Erklärung der kontinuierlichen Integration

Wie würden Sie Continuous Integration definieren und welche spezifischen Komponenten enthält ein CI-Server?

Ich möchte jemandem in der Marketingabteilung erklären, was kontinuierliche Integration ist. Sie verstehen die Quellcodeverwaltung - d. H. Sie verwenden Subversion. Aber ich möchte ihnen richtig erklären, was CI ist. Der Wikipedia-Artikel definiert es nie richtig, der Martin Fowler-Artikel gibt nur Folgendes an, was im Grunde eine Tautologie ist, gefolgt von einer vagen Erklärung der 'Integration':

Kontinuierliche Integration ist eine Softwareentwicklungspraxis, bei der Mitglieder eines Teams ihre Arbeit häufig integrieren. In der Regel wird jede Person mindestens täglich integriert, was zu mehreren Integrationen pro Tag führt. Jede Integration wird durch einen automatisierten Build (einschließlich Test) überprüft, um Integrationsfehler so schnell wie möglich zu erkennen.

Update : Ich habe ihnen dieses Bild geschickt, ich konnte kein einfacheres finden.

enter image description here

Update 2 : Feedback vom Marketing-Mitglied (für die Zeit, als es 3 Fragen gab):

Ich mag eigentlich alle 3 Antworten - aus verschiedenen Gründen. Ich möchte mich einloggen, um ihnen allen zu danken!

Offensichtlich kann er nicht - also danke in seinem Namen :)

Update 3 : Ich habe beim Betrachten des Wikipedia-Artikels festgestellt, dass er die Prinzipien enthält, die, wenn Sie nur die nehmen Überschriften, ist eine ziemlich gute Liste:

  1. Pflegen Sie ein Code-Repository
  2. Automatisieren Sie den Build
  3. Machen Sie den Build selbsttestend
  4. Jeder verpflichtet sich jeden Tag zur Grundlinie
  5. Jedes Commit (zur Baseline) sollte erstellt werden
  6. Halte den Build schnell
  7. Test in einem Klon der Produktionsumgebung
  8. Machen Sie es sich einfach, die neuesten Ergebnisse zu erhalten
  9. Jeder kann die Ergebnisse des neuesten Builds sehen
  10. Bereitstellung automatisieren
32
icc97

Wenn jemand die Dateien ändert, aus denen das Softwareprodukt besteht, und dann versucht, sie einzuchecken (mit anderen Worten, versucht, zu integrieren die Änderungen in den Hauptproduktcode), möchten Sie sicherstellen, dass die Softwareprodukt kann weiterhin erfolgreich erstellt werden.

Normalerweise gibt es ein externes System namens CI-Server, das entweder regelmäßig oder bei jeder Änderung die Quelldateien aus der Versionskontrolle abruft und versucht, das Produkt zu erstellen (kompilieren/testen/paketieren) ). Wenn der CI-Server einen Build erfolgreich ausführen kann, wurden die Änderungen erfolgreich integriert.

Der CI-Server muss auch in der Lage sein, zu senden, wenn der Build fehlgeschlagen ist oder erfolgreich war, damit Systeme wie Jenkins (einer der heute am häufigsten verwendeten CI-Server) E-Mails/Texte sowie eine Dashboard-ähnliche Weboberfläche mit einem senden können Eine Reihe von Informationen über aktuelle und frühere Builds, wer Code eingecheckt hat, wann Dinge kaputt gegangen sind usw. (Auf Ihrem Bild oben wäre dies der Feedback-Mechanismus .)

CI ist wichtig, da es sicherstellt, dass Sie kontinuierlich ein funktionierendes Produkt haben. Dies ist wichtig für alle Entwickler, die an dem Softwareprodukt arbeiten, sowie für alle Personen, die Zugriff auf tägliche Versionen des Softwareprodukts wie QA haben möchten.

27
c_maker

Ich denke, für Ihre Marketingabteilung ist es nicht wichtig , wie CI funktioniert , sondern , was CI für neue Versionen von Ihnen bedeutet Software .

CI bedeutet im Idealfall, dass Sie jeden Tag eine neue möglicherweise freigebbare Version Ihrer Software erstellen können, die bereit ist, Ihrem Kunden präsentiert oder verkauft zu werden, wobei einige neue Features, Funktionen oder Bugfixes hinzugefügt werden. Das bedeutet nicht, dass Sie jeden Tag die neue Version liefern müssen , aber Sie können, wenn Sie möchten.

Wenn Sie beispielsweise einen neuen Funktionsumfang haben, der offiziell für die Version "2015" Ihrer Software veröffentlicht werden soll, und Teile dieses Funktionsumfangs bereits heute codiert und integriert sind, können die Marketingmitarbeiter die aktuelle Version Ihrer Software übernehmen Software und zeigen Sie sie - mehr oder weniger sicher - auf der nächsten Konferenz im Jahr 2013. Ohne CI mussten sie Ihr Team um ein ungeplantes Einfrieren des Codes bitten. Jedes Teammitglied musste die halbherzige Funktion, an der es arbeitet, in die integrieren Möglicherweise verfügen sie nicht über genügend automatische Tests und raten, was auf der Konferenz passieren wird. Die "Alpha-Version" Ihrer 2015er-Version birgt ein viel höheres Absturzrisiko, insbesondere wenn die neuen Funktionen demonstriert werden.

33
Doc Brown

Sie können nicht wissen, was CI ist, wenn Sie nicht wissen, was wir früher getan haben. Stellen Sie sich ein System mit 3 Teilen vor. Es gibt eine Benutzeroberfläche, die Daten sammelt und in die Datenbank stellt. Es gibt ein Berichtssystem, das Berichte aus der Datenbank erstellt. Und es gibt eine Art Server, der die Datenbank überwacht und E-Mail-Benachrichtigungen sendet, wenn bestimmte Kriterien erfüllt sind.

Vor langer Zeit würde dies wie folgt geschrieben werden:

  1. Vereinbaren Sie das Schema für die Datenbank und die Anforderungen - dies würde Wochen dauern, da es perfekt sein musste, da Sie bald sehen werden, warum
  2. Weisen Sie den 3 Teilen 3 Entwickler oder 3 unabhängige Entwicklerteams zu
  3. Jeder Entwickler arbeitete wochen- oder monatelang an seinem Stück und testete es mit seiner eigenen Datenbankkopie.

Während dieser Zeit führten die Entwickler weder den Code des anderen aus, noch versuchten sie, eine Version der Datenbank zu verwenden, die vom Code eines anderen erstellt wurde. Der Verfasser des Berichts fügte lediglich eine Reihe von Beispieldaten hinzu. Der Alert Writer würde manuell Datensätze hinzufügen, die Berichtsereignisse simulieren. Und der GUI-Writer würde in der Datenbank nachsehen, was die GUI hinzugefügt hat. Mit der Zeit würden die Entwickler erkennen, dass die Spezifikation in irgendeiner Weise falsch war, z. B. keinen Index anzugeben oder eine zu kurze Feldlänge zu haben, und dies in ihrer Version "korrigieren". Sie könnten den anderen sagen, wer darauf reagieren könnte, aber normalerweise würden diese Dinge für später auf eine Liste gesetzt.

Wenn alle drei Teile vollständig codiert und von ihren Entwicklern getestet wurden und manchmal sogar von den Benutzern getestet wurden (indem ihnen ein Bericht, ein Bildschirm oder eine E-Mail-Benachrichtigung angezeigt wurden), kam die "Integrations" -Phase. Dies wurde oft mit mehreren Monaten budgetiert, ging aber immer noch über. Diese Änderung der Feldlänge durch Entwickler 1 würde hier entdeckt und würde Entwickler 2 und 3 erfordern, um große Codeänderungen und möglicherweise auch Änderungen an der Benutzeroberfläche vorzunehmen. Dieser zusätzliche Index würde sein eigenes Chaos anrichten. Und so weiter. Wenn einer der Entwickler von einem Benutzer angewiesen wurde, ein Feld hinzuzufügen, und dies tat, wäre es jetzt an der Zeit, dass die anderen beiden es ebenfalls hinzufügen müssten.

Diese Phase war brutal schmerzhaft und so gut wie unmöglich vorherzusagen. Also fingen die Leute an zu sagen: "Wir müssen uns öfter integrieren." "Wir müssen von Anfang an zusammenarbeiten." "Wenn einer von uns eine Änderungsanfrage stellt [so haben wir uns dann unterhalten], müssen die anderen davon wissen." Einige Teams begannen früher mit Integrationstests, während sie weiterhin separat arbeiteten. Und einige Teams begannen von Anfang an, den Code des anderen zu verwenden und die ganze Zeit auszugeben. Und das wurde zu kontinuierlicher Integration.

Sie denken vielleicht, ich übertreibe diese erste Geschichte. Ich habe einmal für ein Unternehmen gearbeitet, bei dem mein Kontakt mich zum Einchecken von Code herausgekaut hat, der unter den folgenden Fehlern litt:

  • ein Bildschirm, an dem er nicht arbeitete, hatte eine Schaltfläche, die noch nichts tat
  • kein Benutzer hatte das Bildschirmdesign abgemeldet (genaue Farben und Schriftarten; Existenz des Bildschirms, seine Funktionen und die Schaltflächen in der 300-Seiten-Spezifikation).

Es war seine Meinung, dass man Sachen erst dann in die Quellcodeverwaltung bringt, wenn sie fertig sind. Normalerweise hat er ein oder zwei Checkins pro Jahr durchgeführt. Wir hatten ein bisschen einen philosophischen Unterschied :-)

Wenn es Ihnen schwer fällt zu glauben, dass Teams um eine gemeinsam genutzte Ressource wie eine Datenbank herum getrennt werden, werden Sie nicht wirklich glauben (aber es ist wahr), dass der gleiche Ansatz für den Code gewählt wurde. Sie werden eine Funktion schreiben, die ich aufrufen kann? Das ist großartig, mach weiter, ich werde einfach fest codieren, was ich in der Zwischenzeit brauche. Monate später werde ich meinen Code "integrieren", damit er Ihre API aufruft, und wir werden feststellen, dass er explodiert, wenn ich null übergebe. Ich explodiere, wenn er null zurückgibt (und das tut er oft). Er gibt Dinge zurück, die zu groß sind Für mich kann es keine Schaltjahre und tausend andere Dinge bewältigen. Es war normal, unabhängig zu arbeiten und dann eine Integrationsphase zu haben. Jetzt klingt es nach Wahnsinn.

17
Kate Gregory