Ciągła integracja: Różnice pomiędzy wersjami
Nie podano opisu zmian |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 31 wersji utworzonych przez 3 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''Ciągła integracja (CI)''' jest praktyką, w której zespół programistów systematycznie i często łączy wyniki swoich pracy integrując swoje kody do głównego nurtu lub repozytorium kodu. Celem jest zmniejszenie ryzyka "piekła integracji" poprzez czekanie na koniec projektu lub sprintu, aby połączyć pracę wszystkich programistów. | '''Ciągła integracja (CI)''' jest praktyką, w której [[zespół]] programistów systematycznie i często łączy wyniki swoich pracy integrując swoje kody do głównego nurtu lub [[repozytorium]] kodu. Celem jest zmniejszenie ryzyka "piekła integracji" poprzez czekanie na koniec projektu lub sprintu, aby połączyć pracę wszystkich programistów. | ||
Jedną z podstawowych korzyści płynących z zastosowania CI jest oszczędność czasu podczas cyklu rozwoju poprzez wczesną identyfikację | Jedną z podstawowych korzyści płynących z zastosowania CI jest [[oszczędność]] czasu podczas cyklu rozwoju poprzez wczesną identyfikację | ||
i rozwiązywanie konfliktów. Jest to również optymalny sposób na zmniejszenie ilości czasu spędzanego na naprawianiu błędów i regresji poprzez położenie większego nacisku na posiadanie dobrego zestawu testów. Wreszcie, pomaga dzielić się lepszym zrozumieniem bazy kodu i funkcji, rozwijanych dla klientów (Chmielarz 2014). | i [[rozwiązywanie konfliktów]]. Jest to również optymalny sposób na zmniejszenie ilości czasu spędzanego na naprawianiu błędów i regresji poprzez położenie większego nacisku na [[posiadanie]] dobrego zestawu testów. Wreszcie, pomaga dzielić się lepszym zrozumieniem bazy kodu i funkcji, rozwijanych dla klientów (Chmielarz 2014). | ||
CI pomaga skalować liczbę pracowników i wydajność zespołów inżynierskich. Wprowadzenie CI do powyższego scenariusza pozwala programistom na niezależną, równoległą pracę nad funkcjami. Kiedy są gotowi, aby połączyć te cechy w produkt końcowy, mogą to zrobić niezależnie i szybko. CI jest wartościową i dobrze ugruntowaną praktyką w nowoczesnych, wysokowydajnych organizacjach zajmujących się inżynierią oprogramowania. CI jest zazwyczaj używane wraz z procesem zwinnego wytwarzania oprogramowania. Organizacja sporządza listę zadań, które składają się na mapę drogową produktu. Zadania te są następnie rozdzielane pomiędzy członków zespołu inżynierii oprogramowania w celu ich dostarczenia. Użycie CI umożliwia niezależne i równoległe rozwijanie tych zadań przez przydzielonych programistów. Kiedy jedno z tych zadań zostanie ukończone, programista wprowadza nową pracę do systemu CI, aby została ona zintegrowana z resztą projektu (Chmielarz 2014). | CI pomaga skalować liczbę pracowników i wydajność zespołów inżynierskich. Wprowadzenie CI do powyższego scenariusza pozwala programistom na niezależną, równoległą pracę nad funkcjami. Kiedy są gotowi, aby połączyć te cechy w produkt końcowy, mogą to zrobić niezależnie i szybko. CI jest wartościową i dobrze ugruntowaną praktyką w nowoczesnych, wysokowydajnych organizacjach zajmujących się inżynierią oprogramowania. CI jest zazwyczaj używane wraz z procesem zwinnego wytwarzania oprogramowania. Organizacja sporządza listę zadań, które składają się na mapę drogową produktu. Zadania te są następnie rozdzielane pomiędzy członków zespołu inżynierii oprogramowania w celu ich dostarczenia. Użycie CI umożliwia niezależne i równoległe rozwijanie tych zadań przez przydzielonych programistów. Kiedy jedno z tych zadań zostanie ukończone, programista wprowadza nową pracę do systemu CI, aby została ona zintegrowana z resztą projektu (Chmielarz 2014). | ||
==TL;DR== | |||
Ciągła integracja (CI) to praktyka, w której programiści regularnie łączą swoje kody, aby zmniejszyć ryzyko konfliktów i błędów. CI pomaga oszczędzać czas, skalować zespoły inżynierskie i poprawiać komunikację w organizacji. CI jest często stosowane wraz z procesem zwinnego wytwarzania oprogramowania. Istnieją również fazy ciągłego wdrażania i dostarczania, które są częścią procesu DevOps. CI przynosi korzyści organizacyjne, takie jak skalowalność, poprawa pętli informacji zwrotnej i komunikacji. Wykorzystanie CI wymaga odpowiedniej infrastruktury i technologii. Implementacja CI może wiązać się z wyzwaniami, ale korzyści z niej płynące przeważają nad trudnościami. | |||
<google>n</google> | |||
==Historia CI== | ==Historia CI== | ||
Po raz pierwszy | Po raz pierwszy termin CI zaproponował '''Grady Booch''' w 1991 roku, opisując swoją metodę programowania (Booch, 1991). chociaż nie zalecał on integrowania wyników zespołowych kilka razy dziennie. Z kolei '''[[programowanie]] ekstremalne (XP)''' zaadoptowało koncepcję CI i zalecało bardzo częstą integrację - nawet do kilkudziesięciu razy dziennie (Beck, 1999) | ||
Jako pierwsi prace nad nad ciągłą integracją podjęli GE Kaiser, DE Perry i WM Schell, którzy | Jako pierwsi prace nad nad ciągłą integracją podjęli '''GE Kaiser, DE Perry i WM Schell''', którzy opracowali środowisko Infuse. W 1997 roku '''Kent Beck i Ron Jeffries''' w ramach projektu '''Chrysler Comprehensive Compensation [[System]]''', obejmującego ciągłą integrację stworzyli [[programowanie ekstremalne]] (XP). Założenia, znaczenie i funkcje ciągłej integracji zebrał w swej publikacji o programowaniu ekstremalnym '''Cruise Control Beck'''. Wydana w 2001 roku książka była pierwszą monografią wyczerpującą tematykę ciągłej integracji. | ||
==Rola CI== | ==Rola CI== | ||
Aby zrozumieć znaczenie '''CI''', warto najpierw omówić kilka problemów, które często pojawiają się z powodu braku CI. Bez CI, programiści muszą ręcznie koordynować i komunikować się, kiedy wnoszą kod do produktu końcowego. Ta koordynacja wykracza poza zespoły programistów do operacji i reszty organizacji. Zespoły produktowe muszą koordynować, kiedy sekwencyjnie uruchamiać funkcje i poprawki oraz którzy członkowie zespołu będą za to odpowiedzialni (Trocki, 2011). | Aby zrozumieć znaczenie '''CI''', warto najpierw omówić kilka problemów, które często pojawiają się z powodu braku CI. Bez CI, programiści muszą ręcznie koordynować i komunikować się, kiedy wnoszą kod do produktu końcowego. Ta [[koordynacja]] wykracza poza zespoły programistów do operacji i reszty organizacji. Zespoły produktowe muszą koordynować, kiedy sekwencyjnie uruchamiać funkcje i poprawki oraz którzy członkowie zespołu będą za to odpowiedzialni (Trocki, 2011). | ||
Koszty ogólne komunikacji w środowisku innym niż IK mogą stać się skomplikowanym i zaplątanym obowiązkiem synchronizacji, który dodaje niepotrzebne biurokratyczne koszty do projektów. Powoduje to wolniejsze wydawanie kodu z wyższym wskaźnikiem niepowodzeń, ponieważ wymaga od programistów wrażliwości i rozwagi w stosunku do integracji. Ryzyko to rośnie wykładniczo wraz ze wzrostem wielkości zespołu inżynierskiego i bazy kodów. | [[Koszty]] ogólne komunikacji w środowisku innym niż IK mogą stać się skomplikowanym i zaplątanym obowiązkiem synchronizacji, który dodaje niepotrzebne biurokratyczne koszty do projektów. Powoduje to wolniejsze wydawanie kodu z wyższym wskaźnikiem niepowodzeń, ponieważ wymaga od programistów wrażliwości i rozwagi w stosunku do integracji. [[Ryzyko]] to rośnie wykładniczo wraz ze wzrostem wielkości zespołu inżynierskiego i bazy kodów. | ||
Bez solidnego potoku CI, może dojść do rozłączenia pomiędzy zespołem inżynierów a resztą organizacji. Komunikacja pomiędzy produktem a inżynierią może być uciążliwa. Inżynieria staje się czarną skrzynką, do której reszta zespołu wprowadza wymagania i cechy i być może otrzymuje z powrotem oczekiwane wyniki. Utrudnia to inżynierom oszacowanie czasu dostarczenia żądań, ponieważ czas integracji nowych zmian staje się nieznanym ryzykiem (Trocki, 2011). | Bez solidnego potoku CI, może dojść do rozłączenia pomiędzy zespołem inżynierów a resztą organizacji. [[Komunikacja]] pomiędzy produktem a inżynierią może być uciążliwa. Inżynieria staje się czarną skrzynką, do której reszta zespołu wprowadza wymagania i cechy i być może otrzymuje z powrotem oczekiwane wyniki. Utrudnia to inżynierom oszacowanie czasu dostarczenia żądań, ponieważ czas integracji nowych zmian staje się nieznanym ryzykiem (Trocki, 2011). | ||
==CI vs Ciągłe Wdrażanie vs Ciągłe Dostarczanie== | ==CI vs Ciągłe Wdrażanie vs Ciągłe Dostarczanie== | ||
'''Ciągła integracja, wdrażanie i dostarczanie''' są trzema fazami zautomatyzowanego procesu wydawania oprogramowania, włączając w to proces DevOps. Te trzy fazy prowadzą oprogramowanie od pomysłu do dostarczenia go użytkownikowi końcowemu. Faza integracji jest pierwszym krokiem w tym procesie. '''Ciągła integracja''' obejmuje proces, w którym wielu programistów próbuje połączyć swoje zmiany w kodzie z głównym repozytorium kodu projektu. | '''Ciągła integracja, wdrażanie i dostarczanie''' są trzema fazami zautomatyzowanego procesu wydawania oprogramowania, włączając w to [[proces]] [[DevOps]]. Te trzy fazy prowadzą oprogramowanie od pomysłu do dostarczenia go użytkownikowi końcowemu. Faza integracji jest pierwszym krokiem w tym procesie. '''Ciągła integracja''' obejmuje proces, w którym wielu programistów próbuje połączyć swoje zmiany w kodzie z głównym repozytorium kodu projektu. | ||
'''Ciągłe dostarczanie''' jest kolejnym rozszerzeniem ciągłej integracji. Faza dostarczania jest odpowiedzialna za pakowanie artefaktów w celu dostarczenia ich do użytkowników końcowych. Faza ta uruchamia zautomatyzowane narzędzia budujące, aby wygenerować ten artefakt. Ta faza budowania jest utrzymywana jako "zielona", co oznacza, że artefakt powinien być gotowy do wdrożenia do użytkowników w dowolnym momencie (Duvall, Matyas, Glove, 2007). | '''Ciągłe dostarczanie''' jest kolejnym rozszerzeniem ciągłej integracji. Faza dostarczania jest odpowiedzialna za [[pakowanie]] artefaktów w celu dostarczenia ich do użytkowników końcowych. Faza ta uruchamia zautomatyzowane narzędzia budujące, aby wygenerować ten [[artefakt]]. Ta faza budowania jest utrzymywana jako "zielona", co oznacza, że artefakt powinien być gotowy do wdrożenia do użytkowników w dowolnym momencie (Duvall, Matyas, Glove, 2007). | ||
'''Ciągłe wdrażanie''' jest ostatnią fazą potoku. Faza wdrażania jest odpowiedzialna za automatyczne uruchomienie i dystrybucję artefaktu oprogramowania do użytkowników końcowych. W czasie wdrażania, artefakt pomyślnie przeszedł fazy integracji i dostarczania. Teraz nadszedł czas, aby automatycznie wdrożyć lub dystrybuować artefakt. Odbędzie się to za pomocą skryptów lub narzędzi, które automatycznie przeniosą artefakt na serwery publiczne lub do innego mechanizmu dystrybucji, np. sklepu z aplikacjami (Highsmith, 2004.). | '''Ciągłe wdrażanie''' jest ostatnią fazą potoku. Faza wdrażania jest odpowiedzialna za automatyczne uruchomienie i dystrybucję artefaktu oprogramowania do użytkowników końcowych. W czasie wdrażania, artefakt pomyślnie przeszedł fazy integracji i dostarczania. Teraz nadszedł czas, aby automatycznie wdrożyć lub dystrybuować artefakt. Odbędzie się to za pomocą skryptów lub narzędzi, które automatycznie przeniosą artefakt na serwery publiczne lub do innego mechanizmu dystrybucji, np. sklepu z aplikacjami (Highsmith, 2004.). | ||
==Korzyści i wyzwania związane z ciągłą integracją== | ==Korzyści i wyzwania związane z ciągłą integracją== | ||
'''Ciągła integracja''' jest istotnym aspektem DevOps i wysoko wydajnych zespołów programistycznych. Jednak korzyści płynące z CI nie ograniczają się do zespołu inżynierskiego, ale są bardzo korzystne dla całej organizacji. CI umożliwia lepszą przejrzystość i wgląd w proces tworzenia i dostarczania oprogramowania. Dzięki tym korzyściom reszta organizacji może lepiej planować i realizować strategie wejścia na rynek. Poniżej przedstawiono niektóre z ogólnych korzyści organizacyjnych wynikających z CI | '''Ciągła integracja''' jest istotnym aspektem DevOps i wysoko wydajnych zespołów programistycznych. Jednak korzyści płynące z CI nie ograniczają się do zespołu inżynierskiego, ale są bardzo korzystne dla całej organizacji. CI umożliwia lepszą przejrzystość i wgląd w proces tworzenia i dostarczania oprogramowania. Dzięki tym korzyściom reszta organizacji może lepiej planować i realizować strategie wejścia na [[rynek]]. Poniżej przedstawiono niektóre z ogólnych korzyści organizacyjnych wynikających z CI: | ||
* '''Umożliwienie skalowania''' | * '''Umożliwienie skalowania''' | ||
CI umożliwia organizacjom skalowanie wielkości zespołów inżynierskich, wielkości bazy kodów i infrastruktury. Minimalizując biurokrację związaną z integracją kodu i koszty ogólne komunikacji, CI pomaga budować DevOps i zwinne przepływy pracy. Dzięki temu każdy członek zespołu może być właścicielem nowej zmiany w kodzie aż do wydania. CI umożliwia skalowanie poprzez usunięcie wszelkich zależności organizacyjnych pomiędzy rozwojem poszczególnych funkcjonalności. Programiści mogą teraz pracować nad funkcjami w odizolowanych silosach i mieć pewność, że ich kod będzie płynnie zintegrowany z resztą bazy kodowej, co jest kluczowym procesem DevOps (Humble , Farley 2010). | CI umożliwia organizacjom skalowanie wielkości zespołów inżynierskich, wielkości bazy kodów i infrastruktury. Minimalizując biurokrację związaną z integracją kodu i koszty ogólne komunikacji, CI pomaga budować DevOps i zwinne przepływy pracy. Dzięki temu każdy członek zespołu może być właścicielem nowej zmiany w kodzie aż do wydania. CI umożliwia skalowanie poprzez usunięcie wszelkich zależności organizacyjnych pomiędzy rozwojem poszczególnych funkcjonalności. Programiści mogą teraz pracować nad funkcjami w odizolowanych silosach i mieć pewność, że ich kod będzie płynnie zintegrowany z resztą bazy kodowej, co jest kluczowym procesem DevOps (Humble , Farley 2010). | ||
* '''Usprawnienie pętli informacji zwrotnej''' | * '''Usprawnienie pętli informacji zwrotnej''' | ||
Szybsza informacja zwrotna dotycząca decyzji biznesowych to kolejny potężny efekt uboczny CI. Zespoły produktowe mogą szybciej testować pomysły i iterować projekty produktów dzięki zoptymalizowanej platformie CI. Zmiany mogą być szybko wprowadzane i mierzone pod kątem sukcesu. Błędy i inne problemy mogą być szybko rozwiązywane i naprawiane (Humble, Farley 2010). | Szybsza [[informacja]] zwrotna dotycząca decyzji biznesowych to kolejny potężny efekt uboczny CI. Zespoły produktowe mogą szybciej testować pomysły i iterować projekty produktów dzięki zoptymalizowanej platformie CI. Zmiany mogą być szybko wprowadzane i mierzone pod kątem sukcesu. Błędy i inne problemy mogą być szybko rozwiązywane i naprawiane (Humble, Farley 2010). | ||
* '''Usprawnienie komunikacji''' | * '''Usprawnienie komunikacji''' | ||
CI poprawia ogólną komunikację i odpowiedzialność inżynierów, co umożliwia lepszą współpracę pomiędzy działem rozwoju i operacji w zespole DevOps. Wprowadzając przepływy pracy pull request powiązane z CI, programiści zyskują pasywną wymianę wiedzy. Pull requesty pozwalają programistom obserwować i komentować kod innych członków zespołu. Programiści mogą teraz przeglądać i współpracować z innymi programistami nad gałęziami funkcjonalności w miarę postępu prac w potoku CI. CI może być również wykorzystane do zmniejszenia wydatków na zasoby QA (Melymuka, 2012). Wydajny potok CI z automatycznym pokryciem testami o wysokim poziomie ufności zabezpieczy przed regresjami i zapewni, że nowe funkcje są zgodne ze specyfikacją. Zanim nowy kod zostanie połączony, musi przejść przez zestaw testów CI, co zapobiegnie nowym regresjom. | CI poprawia ogólną komunikację i [[odpowiedzialność]] inżynierów, co umożliwia lepszą współpracę pomiędzy działem rozwoju i operacji w zespole DevOps. Wprowadzając przepływy pracy pull request powiązane z CI, programiści zyskują pasywną wymianę wiedzy. Pull requesty pozwalają programistom obserwować i komentować kod innych członków zespołu. Programiści mogą teraz przeglądać i współpracować z innymi programistami nad gałęziami funkcjonalności w miarę postępu prac w potoku CI. CI może być również wykorzystane do zmniejszenia wydatków na [[zasoby]] QA (Melymuka, 2012). Wydajny potok CI z automatycznym pokryciem testami o wysokim poziomie ufności zabezpieczy przed regresjami i zapewni, że nowe funkcje są zgodne ze specyfikacją. Zanim nowy kod zostanie połączony, musi przejść przez zestaw testów CI, co zapobiegnie nowym regresjom. | ||
Korzyści płynące z CI znacznie przewyższają wszelkie wyzwania związane z jego implementacją. Mimo to, ważne jest, aby być świadomym wyzwań związanych z CI. Prawdziwe wyzwania związane z CI pojawiają się w momencie przejścia z projektu bez CI do CI. Większość nowoczesnych projektów programistycznych zaadoptuje CI już na wczesnych etapach tworzenia i złagodzi wyzwania związane z jej późniejszym wdrożeniem (Melymuka, 2012). | Korzyści płynące z CI znacznie przewyższają wszelkie wyzwania związane z jego implementacją. Mimo to, ważne jest, aby być świadomym wyzwań związanych z CI. Prawdziwe wyzwania związane z CI pojawiają się w momencie przejścia z projektu bez CI do CI. Większość nowoczesnych projektów programistycznych zaadoptuje CI już na wczesnych etapach tworzenia i złagodzi wyzwania związane z jej późniejszym wdrożeniem (Melymuka, 2012). | ||
| Linia 35: | Linia 40: | ||
==Wdrożenie i instalacja== | ==Wdrożenie i instalacja== | ||
Wyzwania związane z ciągłą integracją dotyczą przede wszystkim przyjęcia przez zespół i początkowej instalacji technicznej. Jeśli zespół nie posiada obecnie rozwiązania CI, wybranie go i rozpoczęcie pracy może wymagać pewnego wysiłku. W związku z tym, podczas instalacji potoku CI należy wziąć pod uwagę istniejącą infrastrukturę inżynierską. | Wyzwania związane z ciągłą integracją dotyczą przede wszystkim przyjęcia przez zespół i początkowej instalacji technicznej. Jeśli zespół nie posiada obecnie rozwiązania CI, wybranie go i rozpoczęcie pracy może wymagać pewnego wysiłku. W związku z tym, podczas instalacji potoku CI należy wziąć pod uwagę istniejącą infrastrukturę inżynierską. | ||
Funkcjonalność CI jest dostarczana z listą technologii wspierających, które mogą być inwestycją w krzywą uczenia się dla zespołu. Te technologie to systemy kontroli wersji, infrastruktura hostingowa i technologie orkiestracji (Chmielarz, 2014). | Funkcjonalność CI jest dostarczana z listą technologii wspierających, które mogą być inwestycją w krzywą uczenia się dla zespołu. Te technologie to systemy kontroli wersji, [[infrastruktura]] hostingowa i technologie orkiestracji (Chmielarz, 2014). | ||
{{infobox5|list1={{i5link|a=[[Metodyka Extreme Programming]]}} — {{i5link|a=[[Lean Software Development]]}} — {{i5link|a=[[DevOps]]}} — {{i5link|a=[[Scaled agile framework]]}} — {{i5link|a=[[Inżynieria oprogramowania]]}} — {{i5link|a=[[Backlog produktu]]}} — {{i5link|a=[[Test driven development]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[Nexus]]}} }} | |||
==Bibliografia== | ==Bibliografia== | ||
* Beck | <noautolinks> | ||
* Belmont J | * Beck K. (1999), ''Embracing change with extreme programming'', IEEE, Vol. 32 (10) | ||
* Booch | * Belmont J. (2018), ''Hands-On Continuous Integration and Delivery: Build and release quality software at scale with Jenkins, Travis CI, and CircleCI'', Packt Publishing, London | ||
* Chmielarz W.(2014), | * Booch G. (1991), ''Object Oriented Design: With Applications'', Benjamin/Cummings Pub. Co, San Francisco | ||
* Duvall P., Matyas S., Glove A. (2007), | * Chmielarz W. (2014), ''Ciągła integracja i dostawa oprogramowania w metodach zarządzania projektem'', Prace Naukowe Uniwersytetu Ekonomicznego w Katowicach, Systemy wspomagania organizacji SWO | ||
* Grubor S. | * Duvall P., Matyas S., Glove A. (2007), ''Continuous Integration: Improving Software Quality and Reducing Risk'', Addison-Wesley Professional, London | ||
* Highsmith J.(2004), | * Grubor S. (2017), ''Deployment with Docker. Apply continuous integration models, deploy applications quicker, and scale at large by putting Docker to work'', Packt Publishing, London | ||
* Humble J., Farley D. (2010), | * Highsmith J. (2004), ''Agile Project Management: Creating Innovative Products'', Addison-Wesley Professional, London | ||
* Humble J., Farley D. (2010), ''Continuous Delivery. Reliable Software Releases through Build, Test, and Deployment Automation'', Pearson Education, London | |||
* Melymuka V.(2012), | * Melymuka V. (2012), ''TeamCity 7 Continuous Integration Essentials'', Packt Publishing, London | ||
* Pathania N. | * Pathania N. (2016), ''Learning Continuous Integration with Jenkins'', Packt Publishing, London | ||
* Rossel S. (2017), | * Rossel S. (2017), ''Continuous Integration, Delivery, and Deployment: Reliable and faster software releases with automating builds, tests, and deployment'', Packt Publishing, London | ||
* Shahin M., Babar M | * Shahin M., Babar M., Zhu L. (2017), ''Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices'', IEEE, Vol. 5 | ||
* Trocki W. (2011), | * Trocki W. (2011), ''Wprowadzenie do ciągłej integracji'' | ||
</noautolinks> | |||
{{a|Kinga Zmarzły}} | {{a|Kinga Zmarzły}} | ||
[[Kategoria: | [[Kategoria:Techniki zwinne]] | ||
{{#metamaster:description|Ciągła integracja to praktyka programistyczna, która pozwala zaoszczędzić czas, wykrywając konflikty i błędy oraz zwiększając zrozumienie kodu.}} | |||
Aktualna wersja na dzień 19:23, 16 sty 2024
Ciągła integracja (CI) jest praktyką, w której zespół programistów systematycznie i często łączy wyniki swoich pracy integrując swoje kody do głównego nurtu lub repozytorium kodu. Celem jest zmniejszenie ryzyka "piekła integracji" poprzez czekanie na koniec projektu lub sprintu, aby połączyć pracę wszystkich programistów.
Jedną z podstawowych korzyści płynących z zastosowania CI jest oszczędność czasu podczas cyklu rozwoju poprzez wczesną identyfikację i rozwiązywanie konfliktów. Jest to również optymalny sposób na zmniejszenie ilości czasu spędzanego na naprawianiu błędów i regresji poprzez położenie większego nacisku na posiadanie dobrego zestawu testów. Wreszcie, pomaga dzielić się lepszym zrozumieniem bazy kodu i funkcji, rozwijanych dla klientów (Chmielarz 2014).
CI pomaga skalować liczbę pracowników i wydajność zespołów inżynierskich. Wprowadzenie CI do powyższego scenariusza pozwala programistom na niezależną, równoległą pracę nad funkcjami. Kiedy są gotowi, aby połączyć te cechy w produkt końcowy, mogą to zrobić niezależnie i szybko. CI jest wartościową i dobrze ugruntowaną praktyką w nowoczesnych, wysokowydajnych organizacjach zajmujących się inżynierią oprogramowania. CI jest zazwyczaj używane wraz z procesem zwinnego wytwarzania oprogramowania. Organizacja sporządza listę zadań, które składają się na mapę drogową produktu. Zadania te są następnie rozdzielane pomiędzy członków zespołu inżynierii oprogramowania w celu ich dostarczenia. Użycie CI umożliwia niezależne i równoległe rozwijanie tych zadań przez przydzielonych programistów. Kiedy jedno z tych zadań zostanie ukończone, programista wprowadza nową pracę do systemu CI, aby została ona zintegrowana z resztą projektu (Chmielarz 2014).
TL;DR
Ciągła integracja (CI) to praktyka, w której programiści regularnie łączą swoje kody, aby zmniejszyć ryzyko konfliktów i błędów. CI pomaga oszczędzać czas, skalować zespoły inżynierskie i poprawiać komunikację w organizacji. CI jest często stosowane wraz z procesem zwinnego wytwarzania oprogramowania. Istnieją również fazy ciągłego wdrażania i dostarczania, które są częścią procesu DevOps. CI przynosi korzyści organizacyjne, takie jak skalowalność, poprawa pętli informacji zwrotnej i komunikacji. Wykorzystanie CI wymaga odpowiedniej infrastruktury i technologii. Implementacja CI może wiązać się z wyzwaniami, ale korzyści z niej płynące przeważają nad trudnościami.
Historia CI
Po raz pierwszy termin CI zaproponował Grady Booch w 1991 roku, opisując swoją metodę programowania (Booch, 1991). chociaż nie zalecał on integrowania wyników zespołowych kilka razy dziennie. Z kolei programowanie ekstremalne (XP) zaadoptowało koncepcję CI i zalecało bardzo częstą integrację - nawet do kilkudziesięciu razy dziennie (Beck, 1999) Jako pierwsi prace nad nad ciągłą integracją podjęli GE Kaiser, DE Perry i WM Schell, którzy opracowali środowisko Infuse. W 1997 roku Kent Beck i Ron Jeffries w ramach projektu Chrysler Comprehensive Compensation System, obejmującego ciągłą integrację stworzyli programowanie ekstremalne (XP). Założenia, znaczenie i funkcje ciągłej integracji zebrał w swej publikacji o programowaniu ekstremalnym Cruise Control Beck. Wydana w 2001 roku książka była pierwszą monografią wyczerpującą tematykę ciągłej integracji.
Rola CI
Aby zrozumieć znaczenie CI, warto najpierw omówić kilka problemów, które często pojawiają się z powodu braku CI. Bez CI, programiści muszą ręcznie koordynować i komunikować się, kiedy wnoszą kod do produktu końcowego. Ta koordynacja wykracza poza zespoły programistów do operacji i reszty organizacji. Zespoły produktowe muszą koordynować, kiedy sekwencyjnie uruchamiać funkcje i poprawki oraz którzy członkowie zespołu będą za to odpowiedzialni (Trocki, 2011).
Koszty ogólne komunikacji w środowisku innym niż IK mogą stać się skomplikowanym i zaplątanym obowiązkiem synchronizacji, który dodaje niepotrzebne biurokratyczne koszty do projektów. Powoduje to wolniejsze wydawanie kodu z wyższym wskaźnikiem niepowodzeń, ponieważ wymaga od programistów wrażliwości i rozwagi w stosunku do integracji. Ryzyko to rośnie wykładniczo wraz ze wzrostem wielkości zespołu inżynierskiego i bazy kodów.
Bez solidnego potoku CI, może dojść do rozłączenia pomiędzy zespołem inżynierów a resztą organizacji. Komunikacja pomiędzy produktem a inżynierią może być uciążliwa. Inżynieria staje się czarną skrzynką, do której reszta zespołu wprowadza wymagania i cechy i być może otrzymuje z powrotem oczekiwane wyniki. Utrudnia to inżynierom oszacowanie czasu dostarczenia żądań, ponieważ czas integracji nowych zmian staje się nieznanym ryzykiem (Trocki, 2011).
CI vs Ciągłe Wdrażanie vs Ciągłe Dostarczanie
Ciągła integracja, wdrażanie i dostarczanie są trzema fazami zautomatyzowanego procesu wydawania oprogramowania, włączając w to proces DevOps. Te trzy fazy prowadzą oprogramowanie od pomysłu do dostarczenia go użytkownikowi końcowemu. Faza integracji jest pierwszym krokiem w tym procesie. Ciągła integracja obejmuje proces, w którym wielu programistów próbuje połączyć swoje zmiany w kodzie z głównym repozytorium kodu projektu. Ciągłe dostarczanie jest kolejnym rozszerzeniem ciągłej integracji. Faza dostarczania jest odpowiedzialna za pakowanie artefaktów w celu dostarczenia ich do użytkowników końcowych. Faza ta uruchamia zautomatyzowane narzędzia budujące, aby wygenerować ten artefakt. Ta faza budowania jest utrzymywana jako "zielona", co oznacza, że artefakt powinien być gotowy do wdrożenia do użytkowników w dowolnym momencie (Duvall, Matyas, Glove, 2007). Ciągłe wdrażanie jest ostatnią fazą potoku. Faza wdrażania jest odpowiedzialna za automatyczne uruchomienie i dystrybucję artefaktu oprogramowania do użytkowników końcowych. W czasie wdrażania, artefakt pomyślnie przeszedł fazy integracji i dostarczania. Teraz nadszedł czas, aby automatycznie wdrożyć lub dystrybuować artefakt. Odbędzie się to za pomocą skryptów lub narzędzi, które automatycznie przeniosą artefakt na serwery publiczne lub do innego mechanizmu dystrybucji, np. sklepu z aplikacjami (Highsmith, 2004.).
Korzyści i wyzwania związane z ciągłą integracją
Ciągła integracja jest istotnym aspektem DevOps i wysoko wydajnych zespołów programistycznych. Jednak korzyści płynące z CI nie ograniczają się do zespołu inżynierskiego, ale są bardzo korzystne dla całej organizacji. CI umożliwia lepszą przejrzystość i wgląd w proces tworzenia i dostarczania oprogramowania. Dzięki tym korzyściom reszta organizacji może lepiej planować i realizować strategie wejścia na rynek. Poniżej przedstawiono niektóre z ogólnych korzyści organizacyjnych wynikających z CI:
- Umożliwienie skalowania
CI umożliwia organizacjom skalowanie wielkości zespołów inżynierskich, wielkości bazy kodów i infrastruktury. Minimalizując biurokrację związaną z integracją kodu i koszty ogólne komunikacji, CI pomaga budować DevOps i zwinne przepływy pracy. Dzięki temu każdy członek zespołu może być właścicielem nowej zmiany w kodzie aż do wydania. CI umożliwia skalowanie poprzez usunięcie wszelkich zależności organizacyjnych pomiędzy rozwojem poszczególnych funkcjonalności. Programiści mogą teraz pracować nad funkcjami w odizolowanych silosach i mieć pewność, że ich kod będzie płynnie zintegrowany z resztą bazy kodowej, co jest kluczowym procesem DevOps (Humble , Farley 2010).
- Usprawnienie pętli informacji zwrotnej
Szybsza informacja zwrotna dotycząca decyzji biznesowych to kolejny potężny efekt uboczny CI. Zespoły produktowe mogą szybciej testować pomysły i iterować projekty produktów dzięki zoptymalizowanej platformie CI. Zmiany mogą być szybko wprowadzane i mierzone pod kątem sukcesu. Błędy i inne problemy mogą być szybko rozwiązywane i naprawiane (Humble, Farley 2010).
- Usprawnienie komunikacji
CI poprawia ogólną komunikację i odpowiedzialność inżynierów, co umożliwia lepszą współpracę pomiędzy działem rozwoju i operacji w zespole DevOps. Wprowadzając przepływy pracy pull request powiązane z CI, programiści zyskują pasywną wymianę wiedzy. Pull requesty pozwalają programistom obserwować i komentować kod innych członków zespołu. Programiści mogą teraz przeglądać i współpracować z innymi programistami nad gałęziami funkcjonalności w miarę postępu prac w potoku CI. CI może być również wykorzystane do zmniejszenia wydatków na zasoby QA (Melymuka, 2012). Wydajny potok CI z automatycznym pokryciem testami o wysokim poziomie ufności zabezpieczy przed regresjami i zapewni, że nowe funkcje są zgodne ze specyfikacją. Zanim nowy kod zostanie połączony, musi przejść przez zestaw testów CI, co zapobiegnie nowym regresjom.
Korzyści płynące z CI znacznie przewyższają wszelkie wyzwania związane z jego implementacją. Mimo to, ważne jest, aby być świadomym wyzwań związanych z CI. Prawdziwe wyzwania związane z CI pojawiają się w momencie przejścia z projektu bez CI do CI. Większość nowoczesnych projektów programistycznych zaadoptuje CI już na wczesnych etapach tworzenia i złagodzi wyzwania związane z jej późniejszym wdrożeniem (Melymuka, 2012).
Wdrożenie i instalacja
Wyzwania związane z ciągłą integracją dotyczą przede wszystkim przyjęcia przez zespół i początkowej instalacji technicznej. Jeśli zespół nie posiada obecnie rozwiązania CI, wybranie go i rozpoczęcie pracy może wymagać pewnego wysiłku. W związku z tym, podczas instalacji potoku CI należy wziąć pod uwagę istniejącą infrastrukturę inżynierską. Funkcjonalność CI jest dostarczana z listą technologii wspierających, które mogą być inwestycją w krzywą uczenia się dla zespołu. Te technologie to systemy kontroli wersji, infrastruktura hostingowa i technologie orkiestracji (Chmielarz, 2014).
| Ciągła integracja — artykuły polecane |
| Metodyka Extreme Programming — Lean Software Development — DevOps — Scaled agile framework — Inżynieria oprogramowania — Backlog produktu — Test driven development — Feature-Driven Development — Nexus |
Bibliografia
- Beck K. (1999), Embracing change with extreme programming, IEEE, Vol. 32 (10)
- Belmont J. (2018), Hands-On Continuous Integration and Delivery: Build and release quality software at scale with Jenkins, Travis CI, and CircleCI, Packt Publishing, London
- Booch G. (1991), Object Oriented Design: With Applications, Benjamin/Cummings Pub. Co, San Francisco
- Chmielarz W. (2014), Ciągła integracja i dostawa oprogramowania w metodach zarządzania projektem, Prace Naukowe Uniwersytetu Ekonomicznego w Katowicach, Systemy wspomagania organizacji SWO
- Duvall P., Matyas S., Glove A. (2007), Continuous Integration: Improving Software Quality and Reducing Risk, Addison-Wesley Professional, London
- Grubor S. (2017), Deployment with Docker. Apply continuous integration models, deploy applications quicker, and scale at large by putting Docker to work, Packt Publishing, London
- Highsmith J. (2004), Agile Project Management: Creating Innovative Products, Addison-Wesley Professional, London
- Humble J., Farley D. (2010), Continuous Delivery. Reliable Software Releases through Build, Test, and Deployment Automation, Pearson Education, London
- Melymuka V. (2012), TeamCity 7 Continuous Integration Essentials, Packt Publishing, London
- Pathania N. (2016), Learning Continuous Integration with Jenkins, Packt Publishing, London
- Rossel S. (2017), Continuous Integration, Delivery, and Deployment: Reliable and faster software releases with automating builds, tests, and deployment, Packt Publishing, London
- Shahin M., Babar M., Zhu L. (2017), Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices, IEEE, Vol. 5
- Trocki W. (2011), Wprowadzenie do ciągłej integracji
Autor: Kinga Zmarzły
