Jak wdrożyć krok ręczny pod koniec ciągłej dostawy?

13

Przyjęta odpowiedź na moje pytanie dotyczące „W jaki sposób ciągła integracja odnosi się do ciągłej dostawy / wdrażania? ” Wyjaśnia również niewielką różnicę między ciągłą dostawą a ciągłym wdrażaniem . Wydaje się, że jest to związane z odpowiedzią na pytanie typu „Jak chcesz wdrożyć do produkcji, podczas gdy są to (ekskluzywne) opcje do wyboru:

Automatyczny).
Podręcznik.

Nie mogę sobie wyobrazić, że po drugiej stronie ściany DevOps będzie słaby „operator”, który będzie musiał zrobić coś, co odpowiada temu, co oznacza ten „podręcznik”… Moje pytania:

Czy moje odniesienie (w moim pytaniu) do „rozpowszechniania” kontra „instalowania” jest bliskie możliwej implementacji takiego „ręcznego”? Oto odpowiedni cytat mojego powiązanego pytania:

dystrybuować do jakiegoś środowiska docelowego, używając czegoś takiego jak FTP (jeśli standardowe kopie nie mogą wypełnić luki), ale nie aktywuj go jeszcze w celu. To powinno być podobne / bliskie ciągłej dostawy , czy nie?

zainstalować (lub aktywować ) w jakimś środowisku docelowym, w połączeniu z takimi rzeczami, jak powiązania, operacje stop / start itp. To powinno być podobne / bliskie ciągłego wdrażania , czy nie?

Jakie są inne możliwe jego wdrożenia?

continuous-delivery continuous-deployment

— Pierre.Vriens
źródło

Dla wdrożeń AWS stworzyłem skrypt wysyłania / wdrażania, do którego ma dostęp tylko kierownik zespołu. Aby więc wdrożyć do produkcji, kierownik zespołu musi uruchomić skrypt.

— Turtle

Przykro nam, że łamiesz marzenia, ale nadal mamy zespół „wdrożeń”, którego Oek ma uruchamiać aktualizacje DB na Db2-iSeries wraz z ARCAD, a następnie szefem kuchni na serwerach Tomcart, aby wdrażać wersje produkcyjne co 2 czwartki między 20:00 a północą. Niestety, czasami zdarza się słaby operator (mam nadzieję, że nie jest to ich jedyna praca)

— Tensibai

5

Osobiście uważam, distributionże oprogramowanie jest celem jako pośredni etap wdrożenia - instalacja / aktywacja tego oprogramowania jest niezbędna do ukończenia tego wdrożenia.

Dla mnie delivery(jak w continuos delivery) zatrzymuje się, gdy oprogramowanie do wdrożenia jest tworzone i udostępniane do wdrożenia (tj. Do dystrybucji, instalacji i aktywacji)

Tak więc, aby odpowiedzieć na twoje pierwsze pytanie, nie, nie uważałbym dystrybucji i instalacji za odzwierciedlenie ręcznego kroku odróżniającego ciągłe dostarczanie od ciągłego wdrażania.

Tak, w niektórych (miejmy nadzieję rzadkich) przypadkach ten krok ręczny jest tylko ostateczną decyzją człowieka dotyczącą wdrożenia do produkcji, odzwierciedlającą kulturową nieufność w automatyzacji procesów oraz komfort psychiczny polegający na podwójnym sprawdzeniu i podpisaniu przez człowieka decyzji o wdrożeniu (zakładając w ten sposób odpowiedzialność za to), nawet jeśli decyzja ta jest podejmowana wyłącznie w oparciu o algorytm, który można zautomatyzować (np. zliczanie wyników testów pozytywnych / negatywnych).

Ale ogólnie odzwierciedla to po prostu fakt, że decyzja o wdrożeniu w produkcji nie jest po prostu wynikiem zautomatyzowanego algorytmu. Oto kilka przykładów takich przypadków:

zautomatyzowana decyzja zostaje zastąpiona
- wdrożenie można wyrejestrować, nawet jeśli nie zostaną spełnione wszystkie kryteria jakości (wszyscy wiemy, że nie jest to tylko teoretyczny przypadek)
- wdrożenie odbywa się z dowolnego powodu, nawet jeśli wszystkie kryteria są spełnione (na przykład z powodu wpływu na harmonogram rynku)
algorytm automatyczny nie jest (jeszcze) wdrożony / wdrożony
algorytm obejmuje sprawdzenie niektórych kryteriów w zależności od ludzkich decyzji (powiedzmy, wyniki testów ręcznych)
wdrożenie odbywa się w środowisku klienta zewnętrznego, po przeprowadzeniu dodatkowych kontroli klienta

Więc nie patrzyłbym na krok ręczny po prostu jako problem z implementacją.

— Dan Cornilescu
źródło

Merci (oeps: dziękuję) za podzielenie się swoimi spostrzeżeniami na ten temat. Wygląda na to, że inaczej postrzegamy „dystrybucję”. Pozwólcie, że dodam tylko 1 scenariusz: masz okno 1 godziny dla systemu bankowości internetowej, we wczesny niedzielny poranek, aby „aktywować” 150 000 zaktualizowanych plików wykonywalnych. A jeśli z jakichkolwiek powodów konieczne byłoby wycofanie, wówczas żadne negocjacje nie mogłyby rozszerzyć tego okna. Czy naprawdę chcesz marnować czas na „rozpowszechnianie”, zamiast wykorzystywać potrzebny na to „na wypadek, gdyby konieczne było wycofanie? Pomyśl dwa razy: jeśli zajmie to więcej niż 1 godzinę ... jesteś zwolniony ... ???

— Pierre.Vriens

To IMHO to tylko szczegół optymalizacji lub wdrożenia samego wdrożenia, mający zastosowanie w twoim przypadku (ale to nie oznacza, że jest to reguła). To, że wykonujesz część wdrożenia przed faktycznym zamknięciem starego wykonania SW, nie oznacza, że odpowiednia praca jest częścią etapu dostarczania. Nie musi to również oznaczać, że po rozpoczęciu wdrażania należy go również ukończyć. SW jest skutecznie dostarczany (tj. Dostępny / gotowy do wdrożenia), nawet jeśli nie jest on właściwie wdrażany.

— Dan Cornilescu,

2

Jedna dodatkowa uwaga, jeśli publikujesz coś, czego oczekujesz od innych projektów, wdrożenie ma również znaczenie „publikowanie do użycia przez innych”

Rozważ przepływ pracy, w którym wdrażasz bibliotekę we wspólnym repozytorium artefaktów. Ta część procesu może polegać na wdrażaniu innego komponentu, który wymaga tego artefaktu w czasie kompilacji, lub może być po prostu aktualizacją wspólnej biblioteki. Ale niezależnie od tego artefaktu jego cykl życia niekoniecznie kończy się udostępnieniem go do konsumpcji przez innych, ale rozmieszczenie tego artefaktu w repozytorium artefaktów może być ostatnim etapem pracy programistów po tym, jak zdecydowali się wyciąć nowa wersja i zanim inni będą mogli bezpiecznie korzystać z nowej wersji.

— hvindin
źródło