W jaki sposób ciągła integracja odnosi się do ciągłej dostawy / wdrażania?

Oto cytat z aktualnej treści ciągłej integracji :

... proces częstego łączenia kopii kodu roboczego programisty ze wspólną bazą kodów, aby zapobiec problemom z integracją lub je zminimalizować.

OK, rozumiem. Ale jest też ciągłe dostarczanie i ciągłe wdrażanie , i tam ciągle się trochę gubię:

• W jaki sposób ciągła integracja odnosi się do ciągłego dostarczania i / lub ciągłego wdrażania , zakładając, że gdzieś wzdłuż linii przez integrationCiebie trafisz do deliveringdocelowego środowiska, w którym wszystko będzie deployed.
• Jaka jest różnica między ciągłą dostawą a ciągłym wdrażaniem ?

Dawno temu, zanim DevOps nazwano DevOps, używaliśmy terminologii, która może pomóc w zrozumieniu tych nowych terminów DevOps, takich jak:

• promowanie do (lub obniżanie ) z jakiegoś celu przedprodukcyjnego, opcjonalnie w połączeniu z pewnym rodzajem procesu regeneracji (kompilacja, powiązanie itp.) w celu spakowania wszystkich powiązanych komponentów razem w rzeczy podobne do wykonywalnego. To powinno być podobne / bliskie ciągłej integracji , czy nie?
• 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 zatrzymania / uruchomienia itp. Czy to powinno być podobne / bliskie ciągłego wdrażania , czy nie?

Ciągłe dostarczanie i ciągłe wdrażanie idą o krok dalej, poprzez dodanie do procesu kroku „wdrożenie do produkcji”. Różnica między ciągłym dostarczaniem a wdrażaniem polega na tym, że w przypadku dostarczania ten krok jest wykonywany ręcznie, a w przypadku wdrażania jest automatyczny.

Różnica między ciągłą integracją, ciągłą dostawą i ciągłym wdrażaniem. Zdjęcie skopiowane z codeproject.com

Niezależnie od tego, czy wykonujesz ciągłą dostawę, czy ciągłe wdrażanie, wybór jest bardzo ważny. W przypadku ciągłego wdrażania zmiany w kodzie będą wdrażane automatycznie po pozytywnym przejściu testów akceptacyjnych. Może to być lub nie być pożądane dla twojego produktu. Dzięki ciągłemu dostarczaniu ludzie mogą wybrać, czy konkretna zmiana kodu zostanie wdrożona, czy nie (i ewentualnie gdzie dokładnie zostanie wdrożona).

Ponieważ różnica między ciągłą dostawą a wdrożeniem jest niewielka, a wiele osób nie zdaje sobie sprawy z dokładnej różnicy, te dwa terminy są czasami używane zamiennie.

Ciągła dostawa i ciągłe wdrażanie (CD) są mniej więcej tym samym *. Za każdym razem, gdy zmiana zostanie uznana za „dobrą do przejścia” (przetestowaną / zweryfikowaną), należy ją natychmiast zwolnić. Możesz to zrobić tyle razy dziennie, ile jest ukończonych prac.

Ciągła integracja (CI) odnosi się tylko do łączenia kodu ze sobą często, aby zapewnić, że gałęzie funkcji nie odwrócą się zbyt daleko od głównej gałęzi „master”, a także, abyś bardzo szybko wiedział, czy występują problemy z kodem z perspektywa integracji - tzn. czy zmieniłeś coś podczas zmiany rzeczy.

Jeśli chodzi o ich wzajemne relacje, CI pomaga znacznie zweryfikować kod, aby można go było szybko zwolnić (CD). Nadal możesz osiągnąć CD bez CI (i vice versa), ale przekonasz się, że często życie znacznie ułatwia wczesną integrację kodu i często szybsze znajdowanie problemów, co z kolei pozwala szybciej i szybciej naprawić wspomniane problemy. dostarcz swoje funkcje szybciej!

* Edycja: oto artykuł omawiający różnicę. https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff Ciągłe dostarczanie nie zawsze oznacza faktyczne wdrażanie do produkcji przez cały czas, a raczej ciągłe wdrażanie w środowisku produkcyjnym , mając pewność, że zmiany te mogą zostać wprowadzone do produkcji w dowolnym momencie, gdy firma będzie gotowa. W praktyce większość ludzi łączy te warunki.

Pewna wersja oprogramowania musi najpierw ukończyć etap integracji, zanim będzie mogła zostać dostarczona lub wdrożona.

W przypadku ciągłego dostarczania / wdrażania konieczna jest ciągła integracja. W przeciwnym razie, jeśli zdarzenia ukończenia integracji są zbyt daleko od siebie, aby zakwalifikować się do atrybutu „ciągłego”, to możliwe są również dostawy / wdrożenia (tylko podzbiór zintegrowanych wersji zazwyczaj kwalifikuje się do dostaw / wdrożenia).

Aktualizacja: Moja odpowiedź podkreśla jedynie zależność (relację) między CI i (obydwoma) płytami CD, terminologia jest dość dobrze ujęta w odpowiedzi THelpera.

Jedyny komentarz na ten temat dotyczy (przeciążonego) użycia deployment. Wdrożenia w środowiskach nieprodukcyjnych to prawdziwa rzecz. Mogą się nawet zdarzać dość często - na przykład jako część różnych etapów testowania podczas ciągłej dostawy. Ale to nie powoduje takich wdrożeń continuous deployments. Ciągłe wdrożenia odnoszą się w szczególności do wdrożeń w środowisku produkcyjnym.

Zasadniczo ciągła integracja jest częścią zarówno ciągłego dostarczania, jak i ciągłego wdrażania, z tym wyjątkiem, że wydania są wykonywane automatycznie. Można również myśleć o ciągłym dostarczaniu jako logicznym kolejnym kroku ciągłej integracji i działa ona we wszystkich środowiskach. Ciągła integracja pomaga również w weryfikacji artefaktów, dzięki czemu można ją szybciej wdrożyć. Mimo że ciągłe wdrażanie nie jest możliwe bez ciągłej integracji, o wiele łatwiej jest wychwycić błędy przy ciągłej integracji. Wszystkie te „ciągłe rzeczy” dotyczą ostatecznie usuwania niepotrzebnych działań w przepływie pracy programistycznej. Co najważniejsze, CI / CD są ważne zarówno z technicznego, jak i biznesowego punktu widzenia. Firmy, które nie stosują tych zasad DevOps ryzykują, że pójdą drogą dinozaurów. W dzisiejszym szybkim środowisku IT tak jestDevOps or die.