Ciągła integracja (CI) – jedna z praktyk metodologii Extreme programming (XP). Czasami bardzo niedoceniana. Jednocześnie prosta w założeniach a zarówn…
Co to, na co i po co to komu?
Hmmm, mógłbym przytaczać tu cytaty z książek i definicje z wikipediów… ale w skrócie chodzi o to aby kod w każdym punkcie czasu się kompilował/budował/uruchamiał.
Ok, ale to nie wystarczy, że przed każdym commitem sprawdzę czy mi się projekt kompiluje? Zresztą najczęściej wszyscy commitujemy gotowe fragmenty kodu które właśnie sprawdziliśmy, że działają.
Januszu 1, użyłeś tutaj dwóch ważnych słów: “każdym” i “najczęściej wszyscy”. Wniknijmy bardziej w każde z nich.
Mówiąc, że zrobisz coś przed “każdym” commitem jak bardzo jesteś tego pewien, że będzie to dokładnie za “każdym” razem?
No w sensie, że zwykle tak robię…
A czy zdarza Ci się czasami zapomnieć, albo stwierdzić, że nie jest to potrzebne – w końcu zmiana literówki w tekście na stronie nie zepsuje projektu nie?
Eeee, no zdarza się…
A co się dzieje gdy “zepsuty” commit poleci na repozytorium?
Nooo…
Ale zaraz to poprawiamy!
Ok, ok nie drążmy tego bardziej. Przejdźmy do aspektu słówka “najczęściej wszyscy”.
Jak bardzo pewny jesteś, że “najczęściej wszyscy” wrzucają tylko poprawne commity?
Raczej tak jak w poprzednim, przecież nikt nie wrzuca na umyślnie zepsutych commitów?
Pewnie i tak. A pracowałeś kiedyś razem ze stażystą nad jednym projektem? Albo prosiłeś nie-programistę aby wrzucił coś na repozytorium?
Akurat nie, ale chyba widzę do czego dążysz…
Dokładnie. Kod czy nie kod – to co trafia na repozytorium trafia tam poprzez człowieka. A człowiek jak to człowiek jest omylny – czyli raz na jakiś czas się pomyli i zrobi format nie tej partycji.
Czyli to całe Continuous integration ma nas przed tym uchronić?
To jeden z wielu problemów jakie rozwiązuje CI.
Oryginalnie CI miało na celu chronić od tzw. “integration hell” – problemu który z czasem powstaje gdy kilka zespołów pracuje nad jednym systemem.
Na początku owe zespoły dzielą się na poszczególne moduły. Gdy moduły są “w miarę” skończone zespoły spotykają się na tzw. “integrację”. Oczywiście okazuje się, że nic nie jest kompatybilne z niczym a podstawowe założenia zostały dawno zrównane z ziemią (ZZZ™).
Continuous integration rozwiązuje to dyktując zasadę – każda nowa wersja kodu musi być natychmiast zintegrowana z resztą.
Tak było na początku, dawno, dawno temu. Potem przyszli ludzie z XP na koszulkach i stwierdzili, że można zastosować to w mniejszej skali – per commit. Dodatkowo powiedzieli, że nie tylko można sprawdzać czy kod się kompiluje ale czy np. wszystkie testy jednostkowe przechodzą? Czy pokrycie kodu jest odpowiednie? Czy dokumentacja się generuje poprawnie? itp.
I tak na dzień dzisiejszy jest określane CI – jako zestaw wymagań sprawdzanych przy każdym nowym akcie dodania swojej pracy do repozytorium.
Ok, ok ale pewnie wymaga to masy czasu i serwerów do testowania tego wszystkiego?
No właśnie, nie do końca…
Ale o tym następnym razem.
Be First to Comment