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.
