Proste wyjaśnienie ciągłej integracji


32

Jak zdefiniowałbyś ciągłą integrację i jakie konkretne składniki zawiera serwer CI?

Chcę wyjaśnić komuś z działu marketingu, czym jest Continuous Integration. Rozumieją kontrolę źródła - tj. Używają Subversion. Ale chciałbym im dokładnie wyjaśnić, czym jest CI. Wikipedia Artykuł nigdy właściwie definiuje, tym artykule Martin Fowler tylko daje następujące dane, które jest w zasadzie tautologią następnie niejasne wyjaśnienia „integracji”:

Continuous Integration to praktyka tworzenia oprogramowania, w której członkowie zespołu często integrują swoją pracę, zwykle każda osoba integruje się co najmniej codziennie - co prowadzi do wielu integracji dziennie. Każda integracja jest weryfikowana przez automatyczną kompilację (w tym test) w celu jak najszybszego wykrycia błędów integracji.

Aktualizacja : wysłałem im ten obraz, nie mogłem znaleźć prostszego.

wprowadź opis zdjęcia tutaj

Aktualizacja 2 : informacje zwrotne z działu marketingowego (na czas, gdy pojawiły się 3 pytania):

Właściwie podoba mi się wszystkie 3 odpowiedzi - z różnych powodów. Chcę się zalogować, aby podziękować wszystkim!

Oczywiście, że nie może - dziękuję w jego imieniu :)

Aktualizacja 3 : Zdałem sobie sprawę, patrząc na artykuł w Wikipedii, że zawiera on zasady, które, biorąc pod uwagę tylko nagłówki, są całkiem dobrą listą:

  1. Utrzymaj repozytorium kodu
  2. Zautomatyzuj kompilację
  3. Wykonaj autotest kompilacji
  4. Każdy zobowiązuje się do poziomu podstawowego każdego dnia
  5. Każde zatwierdzenie (do linii bazowej) powinno być zbudowane
  6. Szybka kompilacja
  7. Testuj w klonie środowiska produkcyjnego
  8. Ułatw sobie otrzymywanie najnowszych produktów
  9. Każdy może zobaczyć wyniki najnowszej kompilacji
  10. Zautomatyzuj wdrażanie

3
oO Twój dział marketingu korzysta z Subversion? Kusiło mnie, aby zagłosować za „Too Localized” ... ;-)
Jeroen

@Jeroen Tak, naprawdę, w przypadku plików na stronie internetowej. Zrobiłem z nich ładny duży czerwony przycisk na stronie internetowej z napisem „Zrób to”, aby zaktualizować subversion na serwerze. :)
icc97

Odpowiedzi:


27

Gdy ktoś zmienia pliki tworzące oprogramowanie, a następnie próbuje je zgłosić (innymi słowy, próbuje zintegrować zmiany z głównym kodem produktu), musisz upewnić się, że oprogramowanie nadal może zostać pomyślnie zbudowane.

Zwykle istnieje system zewnętrzny, zwany serwerem CI , który okresowo lub przy każdej zmianie pobiera pliki źródłowe z kontroli wersji i próbuje zbudować produkt (kompilacja / test / pakiet). Jeśli serwer CI może pomyślnie wykonać kompilację, zmiany zostały pomyślnie zintegrowane.

Serwer CI musi także być w stanie nadawać, jeśli kompilacja się nie powiedzie lub powiedzie, dlatego systemy takie jak Jenkins (jeden z najczęściej używanych obecnie serwerów CI) będą mogły wysyłać e-maile / SMS-y, a także interfejs internetowy podobny do pulpitu nawigacyjnego garść informacji o bieżących i przeszłych kompilacjach, kto zameldował kod, kiedy coś się zepsuło itp. (Na twoim zdjęciu powyżej byłby to mechanizm sprzężenia zwrotnego ).

CI jest ważne, ponieważ zapewnia, że ​​w sposób ciągły masz działający produkt. Jest to ważne dla wszystkich programistów pracujących nad oprogramowaniem, a także dla wszystkich osób, które chcą mieć dostęp do codziennych wersji oprogramowania, takich jak QA.


1
Ciągła integracja dba o status kompilacji, ale także o testy.
Quentin Pradet

1
i wdrożenie, nie wystarczy skompilować i uruchomić testy, ale powinieneś także wysłać pliki binarne do środowiska, aby mogły być one przetestowane również przez ludzi (lub zautomatyzowane narzędzia).
gbjbaanb

1
Ponieważ pytanie wymagało prostego wyjaśnienia, pominąłem wiele (przez większość czasu specyficznych dla projektu / zespołu) szczegółów, które mogą znaleźć się w systemie CI.
c_maker

Czy to zależy od rozwoju opartego na testach? Kod, który się kompiluje, nie zawsze działa poprawnie? Bez testów zakończonych niepowodzeniem, gdy kod nie jest gotowy, skąd system CI wiedziałby, czy kod naprawdę został pomyślnie zintegrowany?
mowwwalker

1
@ user828584: W mojej odpowiedzi sugeruję, że „test” jest częścią kompilacji. Na marginesie, TDD różni się od testów mających na celu sprawdzenie jakości. Jako efekt uboczny TDD będziesz miał dobrze napisane testy, ale możesz je przeprowadzać bez wykonywania TDD.
c_maker

33

Myślę, że dla twojego działu marketingu nie jest ważne, jak działa CI , ale co to znaczy CI dla nowych wydań twojego oprogramowania .

CI będzie idealnie oznaczać, że możesz produkować nową potencjalnie możliwą do wydania wersję oprogramowania każdego dnia, gotową do prezentacji lub sprzedaży klientowi, z dodanymi nowymi funkcjami, funkcjami lub poprawkami błędów. Nie oznacza to, że musisz dostarczać nową wersję każdego dnia, ale możesz, jeśli chcesz.

Na przykład, jeśli planujesz oficjalnie wydać nowy zestaw funkcji dla wersji oprogramowania „2015” i masz części tego zestawu funkcji już zakodowane i zintegrowane dzisiaj, specjaliści od marketingu mogą wziąć aktualną wersję oprogramowanie i pokaż je - mniej lub bardziej bezpiecznie - na następnej konferencji w 2013 roku. Bez CI musieli poprosić zespół o nieplanowane zawieszenie kodu, każdy członek zespołu musiał zintegrować częściowo wypaloną funkcję, nad którą pracuje. produkt może nie mieć wystarczającej liczby automatycznych testów i zgadnij, co się stanie na konferencji - „wersja alfa” Twojego wydania 2015er będzie znacznie bardziej narażona na awarie, szczególnie gdy zostaną zaprezentowane nowe funkcje.


4
+1 za podejście do niego z perspektywy korzyści, które zapewnia.
poke

17

Nie możesz wiedzieć, czym jest CI, chyba że wiesz, co robiliśmy. Wyobraź sobie system z 3 częściami. Istnieje interfejs użytkownika, który gromadzi dane i umieszcza je w bazie danych. Istnieje system raportowania, który tworzy raporty z bazy danych. Jest też jakiś serwer, który monitoruje bazę danych i wysyła powiadomienia e-mail, jeśli spełnione są określone kryteria.

Dawno temu byłoby to napisane w następujący sposób:

  1. Uzgodnij schemat bazy danych i wymagania - zajęłoby to tygodnie, ponieważ musiało być idealne, ponieważ wkrótce zrozumiesz, dlaczego
  2. Przydziel 3 deweloperów lub 3 niezależne zespoły deweloperów do 3 elementów
  3. Każdy deweloper pracował nad swoim utworem i testował go przy użyciu własnej kopii bazy danych przez tygodnie lub miesiące.

W tym czasie deweloperzy nie uruchamiali nawzajem kodu ani nie próbowali używać wersji bazy danych utworzonej przez kod innej osoby. Autor raportu po prostu ręcznie doda kilka przykładowych danych. Autor alertów ręcznie dodawał rekordy symulujące zdarzenia w raporcie. A pisarz GUI patrzy na bazę danych, aby zobaczyć, co dodał GUI. Z czasem deweloperzy zdają sobie sprawę, że specyfikacja jest w jakiś sposób błędna, na przykład nie określają indeksu lub mają zbyt krótką długość pola i „naprawiają” to w swojej wersji. Mogą powiedzieć innym, którzy mogą na to zareagować, ale zwykle te rzeczy trafią na listę na później.

Gdy wszystkie trzy części zostaną całkowicie zakodowane i przetestowane przez ich twórców, a czasem nawet przetestowane przez użytkowników (pokazując im raport, ekran lub powiadomienie e-mailem), wtedy nastąpi faza „integracji”. Budżet ten był często budżetowany na kilka miesięcy, ale nadal się przedłużał. Ta zmiana długości pola przez dev 1 zostałaby tutaj odkryta i wymagałaby dev 2 i 3, aby wprowadzić ogromne zmiany kodu i ewentualnie zmiany interfejsu użytkownika. Ten dodatkowy indeks siałby spustoszenie. I tak dalej. Gdyby jeden z deweloperów otrzymał od użytkownika polecenie dodania pola, i zrobiłby to, teraz nadszedłby czas, aby pozostali dwaj również musieli je dodać.

Ta faza była brutalnie bolesna i prawie niemożliwa do przewidzenia. Ludzie zaczęli mówić: „musimy częściej integrować”. „Musimy współpracować od samego początku”. „Gdy jedno z nas zgłosi prośbę o zmianę [wtedy tak rozmawialiśmy] inni muszą o tym wiedzieć”. Niektóre zespoły zaczęły wcześniej przeprowadzać testy integracyjne, nadal pracując osobno. Niektóre zespoły od samego początku zaczęły używać kodu i danych wyjściowych. I to stało się ciągłą integracją.

Możesz myśleć, że przesadzam z tą pierwszą historią. Pewnego razu pracowałem dla firmy, w której mój kontakt wydzwonił mnie za sprawdzenie kodu, który cierpiał z powodu następujących wad:

  • ekran, nad którym nie pracował, miał przycisk, który jeszcze nic nie zrobił
  • żaden użytkownik nie podpisał się na projekcie ekranu (dokładne kolory i czcionki; istnienie ekranu, jego możliwości i jakie przyciski miał w specyfikacji 300 stron).

Jego zdaniem nie poddajesz kontroli źródła, dopóki nie zostanie WYKONANE. Zazwyczaj robił jedno lub dwa kontrole ROK. Mieliśmy trochę filozoficznej różnicy :-)

Ponadto, jeśli trudno ci uwierzyć, że zespoły byłyby rozłączone wokół wspólnego zasobu, takiego jak baza danych, naprawdę nie uwierzysz (ale to prawda), że to samo podejście zostało zastosowane do kodu. Zamierzasz napisać funkcję, którą mogę wywołać? To świetnie, śmiało i zrób to, w międzyczasie po prostu koduję to, czego potrzebuję. Miesiące później „zintegruję” mój kod, więc wywołuje on Twój interfejs API i odkryjemy, że wysadza się, jeśli przekażę wartość null, wysadzę, jeśli zwróci wartość null (i robi to bardzo często) zwraca rzeczy, które są zbyt duże dla mnie nie jest w stanie obsłużyć lat przestępnych i tysiąca innych rzeczy. Niezależna praca, a następnie faza integracji były normalne. Teraz to brzmi jak szaleństwo.


2
Mieliśmy podobną historię, w której uaktualniliśmy niestandardową aplikację zbudowaną na SP 2003 do SP 2007. Używając VSS (tak, VSS :), każdy programista sprawdził część swojego pliku, zakodowaną na tydzień i dwa, a potem, kiedy zintegrowaliśmy nasz kod, boom, że kiedy problem zaczął się, ponieważ nasz kod znacznie się odchylił. Naprawiliśmy problem z integracją przez miesiąc, a projekt wynajął hotel, aby pomieścić tych, którzy mieszkają bardzo daleko w dni powszednie. Tego dnia nauczyłem się codziennie integrować kod :-)
OnesimusUnbound

@OnesimusUnbound Pamiętam, jak wpadłem z VSS na Clearcase ... z szalki do ognia. Wiele lat później, po powrocie do tej samej firmy na drinki, pamiętam, jak ktoś śmiał się z kolegi programisty za to, że wspomniał o nowej kontroli źródła zwanej „Git”: „Po co nam inny system kontroli źródła?”.
icc97

1
Dziękuję - starałem się wcześniej zrozumieć CI po prostu dlatego, że nie wiedziałem, jaka jest alternatywa
Rhys

Ciekawy. Dla mnie brzmi to bardziej jak porównywanie CI do wodospadu. Ale możesz użyć metodologii innej niż wodospad, która pozwala uniknąć tych problemów (takich jak iteracyjny rozwój) i nie używać CI.
Dan Molding,

@DanMoulding, jeśli jestem zwinny i iteracyjny, a co więcej w mojej części większej rzeczy, która nie jest zintegrowana z tym, co robi ktoś inny, nie robię CI. Cholera, możesz wodospad i CI. Zaprojektuj to wszystko, koduj wszystko, przetestuj wszystko, jeśli chcesz - jeśli wszyscy cały czas używają kodu / schematu / układów plików innych osób, to CI, nawet jeśli używasz wodospadu. Związek jest taki, że bez CI żyjesz i umierasz przez BDUF, ponieważ to twoja jedyna nadzieja (i okazuje się słabą nadzieją) na posiadanie fazy integracji o rozsądnej długości. Przyjęcie CI pozwoliło nam puścić BDUF.
Kate Gregory
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.