Jaka jest różnica między tymi trzema terminami? Mój uniwersytet zawiera następujące definicje:

Ciągła integracja oznacza po prostu, że kopie robocze programisty są synchronizowane ze wspólną linią główną kilka razy dziennie.

Ciągła dostawa jest opisywana jako logiczna ewolucja ciągłej integracji: zawsze możesz wprowadzić produkt do produkcji!

Ciągłe wdrażanie jest opisywane jako logiczny następny krok po ciągłym dostarczaniu: Automatycznie wdrażaj produkt do produkcji, ilekroć przejdzie kontrolę jakości!

Ostrzegają również: Czasami termin „ciągłe wdrażanie” jest również używany, jeśli można ciągle wdrażać system testowy.

Wszystko to wprawia mnie w zakłopotanie. Każde wyjaśnienie, które jest nieco bardziej szczegółowe (lub zawiera przykład), jest mile widziane!

Ciągła integracja

Zgadzam się z definicją twojego uniwersytetu. Continuous Integration to strategia, dzięki której deweloper może stale integrować kod z linią główną - w przeciwieństwie do często.

Możesz twierdzić, że jest to tylko strategia rozgałęzienia w twoim systemie kontroli wersji.

Ma to związek z rozmiarem zadań przypisywanych programistom; Jeśli szacuje się, że zadanie zajmie 4-5 osobodni, wówczas programista nie będzie zachęcał do dostarczenia czegokolwiek przez następne 4-5 dni, ponieważ jeszcze nic nie zrobił.

Więc rozmiar ma znaczenie:

small task = continuous integration
big task   = frequent integration

Idealny rozmiar zadania nie jest większy niż dzień pracy. W ten sposób programista będzie miał co najmniej jedną integrację dziennie.

Ciągła dostawa

Istnieją zasadniczo trzy szkoły w ramach Continuous Delivery:

Continuous Delivery to naturalne rozszerzenie Continuous Integration

Ta szkoła przygląda się charakterystycznej serii Addisona-Wesleya „Martin Fowler” i przyjmuje założenie, że od wydania z 2007 roku nosiła nazwę „Continuous Integration”, a ta, która pojawiła się w 2011 roku, nosiła nazwę „Continuous Delivery” , prawdopodobnie mają objętość 1 + 2 tego samego konceptualnego pomysłu, który ma związek z ciągłym czymś .

Ciągła dostawa ma związek z rozwojem zwinnego oprogramowania

Ta szkoła nie zgadza się z myślą, że Continuous Delivery polega na tym, że jest w stanie wspierać zasady ruchu zwinnego, nie tylko jako koncepcyjny pomysł lub list intencyjny, ale na rzeczywistość - w prawdziwym życiu.

Uwzględniając pierwszą zasadę w Manifeście Agile, gdzie termin „ciągła dostawa” jest faktycznie używany po raz pierwszy:

Naszym najwyższym priorytetem jest zadowolenie klienta poprzez wczesne i ciągłe dostarczanie cennego oprogramowania.

Ta szkoła twierdzi, że „Continuous Delivery” to paradygmat, który obejmuje wszystko, co jest potrzebne do zautomatyzowanej weryfikacji Twojej „definicji ukończenia” .

Ta szkoła akceptuje fakt, że „Continuous Delivery” oraz bzyczące słowo lub megatrend „DevOps” są odwrotnymi stronami tej samej monety, w tym sensie, że oboje próbują objąć lub zawrzeć ten nowy paradygmat lub podejście, a nie tylko technikę.

Ciągła dostawa jest synonimem ciągłego wdrażania

Trzecia szkoła opowiada, że ciągłego wdrażania i ciągłego dostarczania można używać zamiennie, co oznacza to samo.

Gdy coś jest gotowe w rękach programistów, jest natychmiast dostarczane do użytkowników końcowych, co w większości przypadków oznacza, że ​​należy je wdrożyć w środowisku produkcyjnym. Dlatego „Wdróż” i „Dostarcz” oznacza to samo.

Do której szkoły dołączyć

Twój uniwersytet wyraźnie dołączył do pierwszej szkoły i twierdzi, że mamy na myśli tom 1 + 2 z tej samej serii publikacji. Moim zdaniem jest to niewłaściwe użycie terminu „dostawa ciągła”.

Osobiście opowiadam się za zrozumieniem, że Continuous Delivery wiąże się z wdrażaniem rzeczywistego wsparcia dla pomysłów i koncepcji wyrażonych przez ruch zwinny. Dołączyłem więc do szkoły, która mówi, że termin obejmuje cały paradygmat - jak „DevOps”.

Szkoła, która używa dostarczania jako synonimu wdrażania, jest najczęściej popierana przez dostawców narzędzi, którzy tworzą konsole wdrażania, starając się uzyskać nieco szumu w związku z bardziej powszechnym użyciem terminu Continuous Delivery .

Ciągłe wdrażanie

Nacisk na ciągłe wdrażanie jest szczególnie istotny w domenach, w których dostęp użytkownika końcowego do aktualizacji oprogramowania zależy od aktualizacji jakiegoś scentralizowanego źródła tych informacji i gdzie to scentralizowane źródło nie zawsze jest łatwe do aktualizacji, ponieważ jest monolityczne lub ma (zbyt) wysoką spójność z natury (sieć, SOA, bazy danych itp.).

W przypadku wielu domen produkujących oprogramowanie, w których nie ma scentralizowanego źródła informacji (urządzenia, produkty konsumenckie, instalacje klienta itp.) Lub w których scentralizowane źródło informacji jest łatwe do aktualizacji (systemy zarządzania artefaktami w sklepach z aplikacjami, repozytoria Open Source itp. ), prawie w ogóle nie ma szumu na temat ciągłego wdrażania. Po prostu się wdrażają; to nie jest wielka sprawa - to nie ból, który wymaga szczególnej uwagi.

Fakt, że ciągłe wdrażanie nie jest czymś ogólnie interesującym dla wszystkich, jest również argumentem, że szkoła, która twierdzi, że „dostarczanie” i „wdrażanie” są synonimami, popełniła błąd. Ponieważ Continuous Delivery naprawdę ma dla wszystkich sensowne znaczenie - nawet jeśli tworzysz oprogramowanie wbudowane w urządzenia lub wypuszczasz wtyczki Open Source dla frameworka.

Definicja twojego uniwersytetu, że ciągłe wdrażanie jest naturalnym kolejnym krokiem ciągłego dostarczania, domyślnie zakłada, że ​​każda dostawa, która jest poddawana kontroli jakości, powinna natychmiast stać się dostępna dla użytkowników końcowych, jest bliższa definicji używanej przez moje plemię do opisu terminu „ciągłe Wydanie ”, co z kolei jest kolejną koncepcją, która ogólnie nie ma sensu dla wszystkich.

Wydanie może być bardzo strategiczne lub polityczne i nie ma powodu zakładać, że każdy chciałby to robić przez cały czas (chyba że jest to księgarnia internetowa oferująca usługę przesyłania strumieniowego). Niemniej jednak firmy, które nie ujawniają wszystkiego na ślepo przez cały czas, mogą mieć wiele powodów, dla których i tak chcą być mistrzami wdrażania, więc również robią to w trybie ciągłego wdrażania . Nie od wydania do produkcji, ale od kandydatów do wydania w środowiskach podobnych do produkcji .

Ponownie uważam, że twój uniwersytet źle to zrozumiał. Mylą „Continuous Deployment” z „Continuous Release”.

Ciągłe wdrażanie to po prostu dyscyplina ciągłego przenoszenia wyników procesu programowania do środowiska produkcyjnego, w którym testy funkcjonalne mogą być wykonywane w pełnej skali.

Historia ciągłej dostawy

Na zdjęciu wszystko ożywa:

Proces ciągłej integracji to pierwsze dwa działania na schemacie przejścia stanu. który - jeśli się powiedzie - uruchamia potok ciągłego dostarczania, który implementuje definicję „gotowe” . Wdrożenie to tylko jedno z wielu działań, które będą musiały być stale wykonywane w tym procesie. W idealnym przypadku proces jest zautomatyzowany od momentu, w którym programista zatwierdza się do VCS, do momentu, w którym potok potwierdzi, że mamy ważnego kandydata do wydania.

Ani pytanie, ani odpowiedzi tak naprawdę nie pasują do mojego prostego sposobu myślenia o tym. Jestem konsultantem i zsynchronizowałem te definicje z wieloma zespołami deweloperów i osobami DevOps, ale jestem ciekawy, jak to pasuje do całej branży:

Zasadniczo myślę o zwinnej praktyce ciągłego dostarczania jak o kontinuum:

Nieciągłe (wszystko ręczne) 0% ----> 100% Ciągłe dostarczanie wartości (wszystko zautomatyzowane)

Kroki w kierunku ciągłej dostawy:

Zero. Nic nie jest zautomatyzowane, gdy deweloperzy sprawdzają kod ... Masz szczęście, jeśli skompilowali, uruchomili lub wykonali jakiekolwiek testy przed odprawą.

1. Ciągłe budowanie: automatyczne budowanie przy każdym odprawie, co jest pierwszym krokiem, ale nie robi nic, aby udowodnić funkcjonalną integrację nowego kodu.

2. Continuous Integration (CI): automatyczne budowanie i wykonywanie przynajmniej testów jednostkowych w celu udowodnienia integracji nowego kodu z istniejącym kodem, ale najlepiej testów integracyjnych (end-to-end).

3. Continuous Deployment (CD): automatyczne wdrażanie, gdy kod przekazuje CI przynajmniej do środowiska testowego, najlepiej do wyższych środowisk, gdy jakość jest potwierdzona albo przez CI, albo poprzez oznaczenie niższego środowiska jako PASSED po ręcznym testowaniu. IE, w niektórych przypadkach testowanie może być ręczne, ale awans do następnego środowiska jest automatyczny.

4. Ciągła dostawa: automatyczna publikacja i wydanie systemu do produkcji. Jest to płyta CD w produkcji oraz wszelkie inne zmiany konfiguracji, takie jak konfiguracja do testowania A / B, powiadamianie użytkowników o nowych funkcjach, powiadamianie o wsparciu nowej wersji i uwagi dotyczące zmian itp.

EDYCJA: Chciałbym podkreślić, że istnieje różnica między koncepcją „ciągłego dostarczania”, o której mowa w pierwszej zasadzie Manifestu Agile ( http://agilemanifesto.org/principles.html ), a praktyką ciągłej dostawy, wydaje się, że wskazuje na to kontekst pytania. Zasada ciągłej dostawy polega na dążeniu do zmniejszenia ilości zapasów zgodnie z opisem w Lean thinking ( http://www.miconleansixsigma.com/8-wastes.html ). Praktyka ciągłego dostarczania (CD) przez zwinne zespoły pojawiła się od wielu lat, od kiedy Agile Manifesto zostało napisane w 2001 r. Ta zwinna praktyka bezpośrednio odnosi się do zasady, chociaż są to różne rzeczy i najwyraźniej łatwo się pomylić.

Myślę, że definicja Amazon jest prosta i łatwa do zrozumienia.

„ Ciągłe dostarczanie to metodologia opracowywania oprogramowania, w której proces wydania jest zautomatyzowany. Każda zmiana oprogramowania jest automatycznie budowana, testowana i wdrażana do produkcji. Przed ostatecznym przejściem do produkcji osoba, automatyczny test lub reguła biznesowa decyduje, kiedy powinien nastąpić ostateczny postęp, chociaż każda udana zmiana oprogramowania może być natychmiast wprowadzona do produkcji z ciągłą dostawą, nie wszystkie zmiany muszą być natychmiast wprowadzone.

Ciągła integracja to praktyka opracowywania oprogramowania, w której członkowie zespołu używają systemu kontroli wersji i często integrują swoją pracę w tej samej lokalizacji, na przykład w głównej gałęzi. Każda zmiana jest budowana i weryfikowana za pomocą testów i innych weryfikacji w celu jak najszybszego wykrycia błędów integracji. Ciągła integracja koncentruje się na automatycznym budowaniu i testowaniu kodu, w porównaniu do ciągłego dostarczania, co automatyzuje cały proces wydawania oprogramowania aż do produkcji ”.

Proszę sprawdzić http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

Atlassian opublikował dobre wyjaśnienie dotyczące ciągłej integracji vs. ciągłego dostarczania vs. ciągłego wdrażania .

W skrócie:

Continuous Integration - to automatyzacja do budowania i testowania aplikacji za każdym razem, gdy nowe zatwierdzenia są wypychane do gałęzi.

Continuous Delivery - to Continuous Integration + Wdróż aplikację do produkcji przez „kliknięcie przycisku” (często jest to możliwe, ale na żądanie).

Ciągłe wdrażanie - jest to ciągłe dostarczanie, ale bez interwencji człowieka (Trwa udostępnianie klientom).

Ciągła integracja oznacza po prostu, że kopie robocze programisty są synchronizowane ze wspólną linią główną kilka razy dziennie.

Lub więcej niż kilka razy dziennie. Zasadniczo tak często, jak każde dyskretne zadanie jest wykonywane. Weźmy na przykład zespół programistów pracujących nad pojedynczą aplikacją biznesową. W wielu środowiskach mogą wystąpić następujące zdarzenia:

• Jeden lub dwóch programistów przechowuje lokalne zmiany przez kilka dni, ponieważ „nie jest jeszcze gotowy”.
• Jeden lub dwóch programistów tworzy gałęzie w kontroli źródła, aby mogli pracować nad swoimi funkcjami „bez przeszkadzania zmianom innych osób”.

Może to prowadzić do problemów. Słaba organizacja kodu / zadania prowadzi do rozgałęziania się, rozgałęziania prowadzi do łączenia, łączenia ... prowadzi do cierpienia. Ciągła integracja jako praktyka rozwiązuje ten problem, zachęcając wszystkich do pracy z tego samego wspólnego źródła. Poszczególne elementy pracy powinny być wystarczająco dyskretne, aby można je było wykonać w krótkim czasie (maksymalnie w godzinach).

Zasadniczo ogólną ideą jest integracja niewielkiej zmiany w niewielkiej ilości pracy. Zintegrowanie dużej zmiany to nieproporcjonalnie duża ilość pracy. Suma prac integracyjnych jest mniejsza, jeśli wykonujemy je małymi krokami. Dzięki temu programiści mogą spędzać więcej czasu pracując nad funkcjami widocznymi dla biznesu zamiast narzutów związanych z programowaniem.

Ciągła dostawa jest opisywana jako logiczna ewolucja ciągłej integracji: zawsze możesz wprowadzić produkt do produkcji!

Jest to zgodne z tą samą ideą dyskretnych, dobrze zdefiniowanych elementów pracy. Jeśli istnieje jedna podstawowa baza kodu, która jest zawsze dostosowywana tylko w małych krokach za pomocą kompletnych, przetestowanych, znanych funkcji roboczych, to baza ta jest zawsze stabilna. Zautomatyzowane testy są tutaj kluczowe, aby móc udowodnić stabilność za naciśnięciem przycisku.

Im mniej pracy stabilizacyjnej trzeba wykonać (co znowu jest narzutem procesu programowania i należy go wyeliminować), tym częściej podstawa kodu może zostać wypchnięta do dowolnego środowiska. W wielu firmach wdrożenie może być dość wyczerpującym procesem. Nawet tygodniowa, praktyczna obsługa na pokładzie. Jest to drogie i nie przynosi żadnej wartości biznesowej. Dzięki zastosowaniu dobrych definicji elementów pracy, efektywnych automatycznych testów i ciągłej integracji zespół może być w stanie zautomatyzować dostarczanie bazy kodu do dowolnego środowiska.

Ciągłe wdrażanie jest opisywane jako logiczny następny krok po ciągłym dostarczaniu: Automatycznie wdrażaj produkt do produkcji, ilekroć przejdzie kontrolę jakości!

Rzadko zobaczysz, jak dzieje się to w środowisku biznesowym, i jest to całkiem radosne, gdy się je napotyka. Jeśli podstawa kodu może być automatycznie przetestowana i automatycznie wdrożona w dowolnym środowisku, wówczas produkcja jest środowiskiem takim jak każde inne. Więc jeśli zespół zbudował do tego momentu, to istnieje potencjalna znacząca wartość dla firmy, ponieważ zawsze jest w stanie wdrażać aktualizacje do produkcji.

Poprawki usterek są wysyłane do klientów szybciej, nowe funkcje szybciej docierają na rynek, nowe pomysły są testowane w stosunku do rynku w mniejszych przyrostach, aby umożliwić przekierowanie priorytetów itp.

Załóżmy na przykład, że firma ma świetny pomysł na nową funkcję w swoim produkcie lub usłudze opartej na oprogramowaniu. Przeprowadzili badania, znają rynek i wierzą, że ten pomysł przyniesie nową, silną linię przychodów. Teraz rozważ dwie opcje dostarczenia tej funkcji:

1. Poświęć miesiące na rozwijanie całości w jednorazowej branży. Spędź tygodnie integrując go z powrotem z główną bazą kodu. Spędź kilka dni na testowaniu. Spędź dzień, wdrażając go. I dopiero wtedy zacznij śledzić rzeczywiste przychody w systemie produkcyjnym.
2. Wdrażaj małe części funkcji, pojedynczo. Każdego tygodnia wypuszczaj nowy kawałek. Co tydzień otrzymuj więcej danych o faktycznych przychodach.

W pierwszym scenariuszu, jeśli funkcja nie ma pożądanego efektu rynkowego, wówczas marnuje się dużo pieniędzy na coś, czego klienci tak naprawdę nie chcą. W drugim scenariuszu fakt, że klienci tego nie chcą, jest określany dużo, dużo wcześniej, a reszta pracy nie jest traktowana priorytetowo.

Ostatecznie te „ciągłe rzeczy” polegają na usuwaniu narzutów z procesu programowania. Jeśli linia przychodów firmy to konkretna oferta usług, idealnie wszystkie jej koszty powinny zostać przeznaczone na tę ofertę. Narzut związany z procesem programowania (łączenie kodu, ponowne testowanie tych samych funkcji po scaleniu, zadania ręcznego wdrażania itp.) W rzeczywistości nie przyczyniają się do wzrostu wartości usługi, dlatego te koncepcje mają na celu usunięcie tych kosztów z procesu.

Jeden wykres może zastąpić wiele słów:

Cieszyć się! :-)

# Zaktualizowałem poprawny obraz ...

Różnica między ciągłą integracją, ciągłą dostawą i ciągłym wdrażaniem

Myślę, że przesadzamy z analizą i może trochę komplikujemy „ciągły” zestaw słów. W tym kontekście ciągłość oznacza automatyzację. W przypadku innych słów dołączonych do „ciągłego” użyj języka angielskiego jako przewodnika tłumaczenia i nie próbuj komplikować rzeczy! W „ciągłej kompilacji” automatycznie budujemy (zapis / kompilacja / link / etc) naszą aplikację w coś, co można wykonać na konkretnej platformie / kontenerze / środowisku wykonawczym / itp. „Ciągła integracja” oznacza, że ​​nowa funkcjonalność testuje i działa zgodnie z przeznaczeniem podczas interakcji z innym bytem. Oczywiście przed integracją musi nastąpić kompilacja, a do sprawdzenia poprawności integracji zostaną wykorzystane również dokładne testy. Tak więc w „ciągłej integracji” jeden wykorzystuje automatyzację, aby dodać wartość do istniejącego zestawu funkcji w sposób, który nie zakłóca istniejącej funkcjonalności, ale raczej ładnie się z nią integruje, dodając postrzeganą wartość do całości. Integracja implikuje, według samej angielskiej definicji, że wszystko harmonijnie się porusza, więc w rozmowie kodowej dodaję kompilacje, linki, testy i działa idealnie w ramach całości. Nie nazwałbyś czegoś zintegrowanego, gdyby zawiodło produkt końcowy, prawda ?! W naszym kontekście „ciągłe wdrażanie” jest równoznaczne z „ciągłym dostarczaniem”, ponieważ pod koniec dnia udostępniliśmy funkcjonalność naszym klientom. Jednak analizując to, mogę argumentować, że wdrożenie jest podzbiorem dostarczania, ponieważ wdrożenie czegoś niekoniecznie oznacza, że ​​dostarczyliśmy. Wdrożyliśmy kod, ale ponieważ nie mamy „ Aby skutecznie komunikować się z naszymi interesariuszami, nie udało nam się dostarczyć z perspektywy biznesowej! Rozlokowaliśmy żołnierzy, ale nie dostarczyliśmy obiecanej wody i jedzenia do pobliskiego miasta. Co jeśli miałbym dodać termin „ciągłe przejście”, czy miałby on swoje zalety? W końcu może lepiej nadaje się do opisywania ruchu kodu w środowiskach, ponieważ ma on konotację „z / do” bardziej niż wdrażanie lub dostarczanie, co może oznaczać tylko jedną lokalizację, na zawsze! To właśnie otrzymujemy, jeśli nie będziemy stosować zdrowego rozsądku. czy miałoby to swoje zalety? W końcu może lepiej nadaje się do opisywania ruchu kodu w środowiskach, ponieważ ma on konotację „z / do” bardziej niż wdrażanie lub dostarczanie, co może oznaczać tylko jedną lokalizację, na zawsze! To właśnie otrzymujemy, jeśli nie będziemy stosować zdrowego rozsądku. czy miałoby to swoje zalety? W końcu może lepiej nadaje się do opisywania ruchu kodu w środowiskach, ponieważ ma on konotację „z / do” bardziej niż wdrażanie lub dostarczanie, co może oznaczać tylko jedną lokalizację, na zawsze! To właśnie otrzymujemy, jeśli nie będziemy stosować zdrowego rozsądku.

Podsumowując, jest to prosta rzecz do opisania (robienie tego jest trochę bardziej ... skomplikowane!), Wystarczy użyć zdrowego rozsądku, języka angielskiego, a wszystko będzie dobrze.

Ciągła integracja: praktyka ciągłego łączenia prac programistycznych z główną gałęzią, aby kod był testowany tak często, jak to możliwe, aby wcześnie wychwycić problemy.

Ciągła dostawa: ciągłe dostarczanie kodu do środowiska, gdy kod będzie gotowy do wysyłki. Może to być inscenizacja lub produkcja. Chodzi o to, że produkt jest dostarczany do bazy użytkowników, którzy mogą być QA lub klientami do przeglądu i inspekcji.

Test jednostkowy w fazie ciągłej integracji nie może wykryć wszystkich błędów i logiki biznesowej, szczególnie problemów projektowych, dlatego potrzebujemy kontroli jakości lub środowiska testowego do testowania.

Ciągłe wdrożenie: wdrożenie lub wydanie kodu, gdy tylko będzie gotowy. Ciągłe wdrażanie wymaga ciągłej integracji i ciągłego dostarczania, w przeciwnym razie jakość kodu nie będzie gwarantowana w wydaniu.

Ciągłe wdrażanie ~~ Ciągła integracja + ciągła dostawa

Ciągła integracja

• Zautomatyzowane (budowanie odpraw + test jednostkowy)

Ciągła dostawa

• Ciągła integracja
• Zautomatyzowane (wdrożenie do testowania środowiska + testowanie obciążenia + test integracji)
• Ręcznie (wdrożenie do produkcji)

Ciągłe wdrażanie

• Ciągła dostawa, ale zautomatyzowana (wdrożenie do produkcji)

CI / CD to podróż. Nie cel.

Te etapy są sugestiami. Możesz dostosować etapy w zależności od potrzeb biznesowych. Niektóre etapy można powtórzyć dla wielu rodzajów testowania, bezpieczeństwa i wydajności. W zależności od złożoności projektu i struktury zespołów niektóre etapy można powtarzać kilka razy na różnych poziomach. Na przykład produkt końcowy jednego zespołu może stać się zależnością w projekcie następnego zespołu. Oznacza to, że produkt końcowy pierwszego zespołu jest następnie wystawiany jako artefakt w projekcie następnego zespołu.

Przypis:

Ćwiczenie ciągłej integracji i ciągłej dostawy w AWS

Źródło: https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/

Co to jest ciągła integracja Ciągła integracja to proces lub praktyka programistyczna polegająca na automatycznej kompilacji i automatycznym testowaniu, tj. Programista musi wielokrotnie zatwierdzać swój kod we wspólnym repozytorium, w którym każda integracja jest weryfikowana przez automatyczną kompilację i test.

Jeśli kompilacja zakończy się niepowodzeniem / sukcesem, programista otrzymuje powiadomienie, a następnie może podjąć odpowiednie działania.

Co to jest Continuous Delivery Continuous Delivery to praktyka polegająca na tym, że nasz kod można wdrożyć w dowolnym momencie, który przeszedł wszystkie testy i ma wymaganą konfigurację, aby wypchnąć kod do produkcji, ale nie został jeszcze wdrożony.

Co to jest ciągłe wdrażanie Za pomocą CI stworzyliśmy wersję kompilacyjną dla naszej aplikacji i jest gotowa do wypchnięcia do produkcji. Na tym etapie nasza kompilacja jest gotowa i za pomocą płyty CD możemy wdrożyć naszą aplikację bezpośrednio w środowisku kontroli jakości, a jeśli wszystko pójdzie dobrze, możemy wdrożyć tę samą kompilację do produkcji.

Zasadniczo ciągłe wdrażanie jest o krok dalej niż ciągłe dostarczanie. Dzięki tej praktyce każda zmiana, która przejdzie wszystkie etapy produkcji, jest udostępniana klientom.

Ciągłe wdrażanie to połączenie zarządzania konfiguracją i konteneryzacji.

Zarządzanie konfiguracją: CM polega na utrzymaniu konfiguracji serwera, która będzie zgodna z wymaganiami aplikacji.

Konteneryzacja : Konteneryzacja to zbiór opłat drogowych, które utrzymają spójność w całym środowisku.

Źródło img: https://www.atlassian.com/

Devops jest kombinacją 3C firmy - ciągły , komunikacji , współpracy i to doprowadzić do paraboliczne w różnych branżach.

W świecie urządzeń połączonych z Internetem przedmiotów wiele funkcji scrum, takich jak właściciel produktu, sieć, telefon komórkowy i kontrola jakości, działa w zwinny sposób w cyklu cyklu scrum, aby dostarczyć produkt do klienta końcowego.

Ciągła integracja: funkcja wielu scrum działa jednocześnie w wielu punktach końcowych

Ciągła dostawa: dzięki integracji i wdrożeniu dostawa produktu do wielu klientów będzie obsługiwana w tym samym czasie.

Ciągłe wdrażanie: wiele produktów zostało wdrożonych do wielu klientów na wielu platformach.

Zobacz, aby dowiedzieć się, w jaki sposób DevOps włącza świat połączony z Internetem przedmiotów: https://youtu.be/nAfZt2t4HqA

Z tego, czego nauczyłem się z Alexem Cowanem podczas kursu Continuous Delivery & DevOps , CI i CD jest częścią serii produktów, która polega na czasie, jaki przechodzi od obserwacji do wydania produktu.

Od obserwacji po projekty - celem jest uzyskanie wysokiej jakości pomysłów do przetestowania. Ta część procesu jest uważana za projekt ciągły .

To, co dzieje się później, gdy przejdziemy od Kodeksu, jest uważane za funkcję ciągłej dostawy , której celem jest bardzo szybkie wdrożenie pomysłów i wydanie klientowi (możesz przeczytać książkę Jez Humble: Ciągła dostawa: niezawodne wydania oprogramowania poprzez kompilację, test, i automatyzacja wdrażania aby uzyskać więcej informacji). Poniższy potok wyjaśnia, z jakich kroków składa się Continuous Integration (CI) i Continuous Delivery (CD).

Ciągła integracja , jak wyjaśnia Mattias Petter Johansson ,

ma to miejsce, gdy zespół oprogramowania ma zwyczaj wykonywania wielu połączeń dziennie i ma zautomatyzowany system weryfikacji, aby sprawdzić te połączenia pod kątem problemów.

(możesz obejrzeć następujące dwa filmy, aby uzyskać bardziej praktyczny przegląd, korzystając z CircleCI - Pierwsze kroki z CircleCI - Continuous Integration P2 i Uruchamianie CircleCI na żądanie ściągnięcia ).

Można określić potok CI / CD w następujący sposób, który przechodzi od Nowego Kodu do wydanego Produktu.

Pierwsze trzy kroki dotyczą Testów, poszerzając granice tego, co jest testowane.

Ciągłe wdrażanieNatomiast polega na automatycznym obsługiwaniu wdrożenia. Tak więc, każdy kod zatwierdzający, który przechodzi fazę automatycznego testowania, jest automatycznie zwalniany do produkcji.

Uwaga : niekoniecznie tak powinny wyglądać Twoje potoki, ale mogą służyć jako odniesienie.