Proste wyjaśnienie ciągłej integracji

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.

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

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.

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.

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.