Wie implementiere ich den manuellen Schritt am Ende der kontinuierlichen Lieferung?

13

Die akzeptierte Antwort auf meine Frage zu "In welcher Beziehung steht die kontinuierliche Integration zur kontinuierlichen Bereitstellung? " Erklärt auch den kleinen Unterschied zwischen kontinuierlicher Bereitstellung und kontinuierlicher Bereitstellung . Es scheint mit der Antwort auf eine Frage wie "Wie möchten Sie in der Produktion bereitstellen?" Zu tun zu haben, wobei dies die (exklusiven) Optionen sind, aus denen Sie auswählen können:

Auto (automatisch).
Handbuch.

Ich kann mir nicht vorstellen, dass es auf der anderen Seite der DevOps-Wand einen armen "Operator" geben wird, der etwas tun muss, das der Bedeutung dieses "Handbuchs" entspricht ... Meine Fragen:

Ist mein Hinweis (in meiner Frage) auf "Verteilen" im Vergleich zu "Installieren" in der Nähe einer möglichen Implementierung eines solchen "manuellen" Dings? Hier ist ein relevantes Zitat meiner verwandten Frage:

Verteilen Sie auf eine bestimmte Zielumgebung über FTP (wenn Standardkopien die Lücke nicht schließen können), aber aktivieren Sie sie noch nicht im Ziel. Das ist es, was der kontinuierlichen Lieferung ähnlich sein sollteoder nicht?

Installation (oder Aktivierung ) in einer bestimmten Zielumgebung, kombiniert mit Dingen wie Bindungen, Stopp- / Startvorgängen usw. Was sollte einer kontinuierlichen Bereitstellung ähnlich seinoder nicht?

Was sind andere mögliche Implementierungen davon?

continuous-delivery continuous-deployment

— Pierre.Vriens
quelle

Für AWS-Bereitstellungen habe ich ein Upload- / Bereitstellungsskript erstellt, auf das nur der Teammanager Zugriff hat. Für die Bereitstellung in der Produktion muss der Teammanager das Skript ausführen.

— Turtle

Es tut uns leid, dass Sie Ihre Träume gebrochen haben, aber wir haben immer noch ein "Deploy" -Team, das DB-Updates für Db2-iSeries mit ARCAD startet und dann auf den Tomcart-Servern an jedem zweiten Donnerstag zwischen 20:00 Uhr und Mitternacht Versionen in der Produktion bereitstellt.

— Leider

5

Persönlich betrachte ich die distributionWeitergabe der Software an ein Ziel nur als Zwischenschritt einer Bereitstellung - die Installation / Aktivierung dieser Software ist erforderlich, um diese Bereitstellung abzuschließen.

Für mich hört das delivery(wie in continuos delivery) auf, wenn die zu implementierende Software erstellt und für die Implementierung verfügbar gemacht wird (dh für die Verteilung, Installation und Aktivierung).

Um Ihre erste Frage zu beantworten: Nein, ich würde Distribution und Installation nicht als den manuellen Schritt betrachten, der die kontinuierliche Bereitstellung von der kontinuierlichen Bereitstellung unterscheidet.

Ja, in einigen (hoffentlich seltenen) Fällen ist dieser manuelle Schritt nur die endgültige menschliche Entscheidung für den Einsatz in der Produktion. Dies spiegelt das kulturelle Misstrauen in der Prozessautomatisierung und den mentalen Komfort wider, die Entscheidung für den Einsatz von einem Menschen zweimal zu überprüfen und zu unterzeichnen (vorausgesetzt) Verantwortung dafür), selbst wenn diese Entscheidung ausschließlich auf der Grundlage eines Algorithmus getroffen wird, der automatisiert werden kann (wie das Zählen der Ergebnisse von Pass / Fail-Tests).

Im Allgemeinen spiegelt es jedoch lediglich die Tatsache wider, dass die Entscheidung zur Durchführung des Einsatzes in der Produktion nicht einfach das Ergebnis eines automatisierten Algorithmus ist. Hier einige Beispiele für solche Fälle:

Die automatisierte Entscheidung wird überschrieben
- Die Bereitstellung kann auch dann abgemeldet werden, wenn nicht alle Qualitätskriterien erfüllt sind (wir alle wissen, dass dies nicht nur ein theoretischer Fall ist).
- Die Bereitstellung findet aus irgendeinem Grund statt, auch wenn alle Kriterien erfüllt sind (z. B. aufgrund von Auswirkungen auf das Market Timing).
Der automatisierte Algorithmus ist (noch) nicht implementiert / implementiert
Der Algorithmus umfasst die Überprüfung einiger Kriterien in Abhängigkeit von menschlichen Entscheidungen (z. B. Ergebnisse manueller Tests).
Die Bereitstellung erfolgt nach zusätzlichen Kundenprüfungen in einer Drittanbieterumgebung

Daher würde ich den manuellen Schritt nicht einfach als Implementierungsproblem betrachten.

— Dan Cornilescu
quelle

Merci (oeps: danke), dass Sie Ihre Ansichten dazu teilen. Sieht so aus, als hätten wir eine andere Auffassung von "Verteilung". Lassen Sie mich also ein Szenario hinzufügen: Sie haben ein Zeitfenster von 1 Stunde, damit ein Online-Banking-System an einem frühen Sonntagmorgen 150.000 aktualisierte ausführbare Dateien "aktiviert". Und wenn aus welchen Gründen auch immer ein Rollback erforderlich wäre, dann ist keine Aushandlung möglich, um dieses Fenster zu erweitern. Möchten Sie wirklich Ihre Zeit mit "Verteilen" verschwenden, anstatt die dafür erforderliche Zeit für "Nur für den Fall, dass ein Rollback erforderlich ist" zu verwenden? Überlegen Sie zweimal: Wenn es länger als 1 Stunde dauert, werden Sie entlassen ???

— Pierre.Vriens

Das ist meiner Meinung nach nur ein Optimierungs- oder Implementierungsdetail der Bereitstellung selbst, das in Ihrem Fall anwendbar ist (aber das macht es nicht zur Regel). Nur weil Sie einen Teil Ihrer Bereitstellung ausführen, bevor Sie die alte SW-Ausführung tatsächlich beenden, bedeutet dies nicht, dass die entsprechende Arbeit Teil der Bereitstellungsphase ist. Dies bedeutet auch nicht zwangsläufig, dass Sie die Bereitstellung nach dem Start auch abschließen müssen. Die SW wird effektiv bereitgestellt (dh verfügbar / bereit für die Bereitstellung), auch wenn Sie sie nicht tatsächlich bereitstellen.

— Dan Cornilescu

2

Eine zusätzliche Überlegung, wenn Sie etwas veröffentlichen, von dem Sie erwarten, dass es von anderen Projekten verwendet wird, hat auch die Bedeutung "Veröffentlichen, damit andere es verwenden".

Stellen Sie sich einen Workflow vor, in dem Sie eine Bibliothek in einem allgemeinen Artefakt-Repository bereitstellen. Dieser Teil des Prozesses ist möglicherweise darauf zurückzuführen, dass Sie eine andere Komponente bereitstellen, für die dieses Artefakt zum Zeitpunkt der Erstellung erforderlich ist, oder es handelt sich lediglich um eine Aktualisierung einer allgemeinen Bibliothek. Unabhängig davon endet der Lebenszyklus dieses Artefakts nicht notwendigerweise damit, dass es für den Verbrauch durch andere verfügbar gemacht wird. Die Bereitstellung dieses Artefakts im Artefakt-Repository ist jedoch möglicherweise die letzte Phase in der Arbeit der Entwickler, nachdem sie beschlossen haben, a zu kürzen neue Release-Version und bevor andere die neue Version sicher verbrauchen können.

— hvindin
quelle