Continuous integration#01: Warsztat smokogromcy

C

Jest to pierwszy post nt. Continuous Integration. W miarę pisania, będą się pojawiać kolejne.

  1. „Warsztat smokogromcy”
  2. „Atrybuty smoczego pogromcy”

 


W tym szaleństwie jest metoda

Continuous Integration według definicji jest to praktyka programistyczna, wedle której członkowie zespołu często winni scalać wyniki swojej pracy (przynajmniej raz dziennie). Potem jakiś automatyczny system buduje/testuje, powstałe wcześniej zintegrowane wersje kodu.

Uważam że, do pełni szczęścia potrzebne są jeszcze procesy Continuous Delivery i Continuous Deployment. Sama praktyka programistów, którzy w miarę często (raz dziennie to jednak zbyt rzadko) commitują swoje zmiany, nie wystarczy. Bardzo ważną rolę odgrywają właśnie tzw. build serwery (Source automation servers), które potrafią budować projekty, testować je i dodatkowo publikować je na określone maszyny/serwery/środowiska. Tym tematem zajmiemy się innym razem. Tymczasem…

 

Teoria broni

W tym cyklu ograniczę się właśnie do „build automation tools” w kontekście Continuous Integration. Proces ten (CI) ma wiele zalet i większość z nich jest powodem do wdrożenia go w teamie, nie tylko zachętą czy gratisem. Raczej triggerem.

  • Koniec z przeciąganiem liny na zasadzie – „u mnie działa, Ty popraw”. Wiemy kto i kiedy zepsuł czy to testy czy po prostu builda (BTW. Drodzy programiści, budujcie projekt i odpalajcie UnitTesty lokalnie, przed commitem. PROSZĘ WAS!)
  • Jeśli już się pojawi błąd, to zazwyczaj jest go łatwo zlokalizować. Problemy wynikające z różnic pomiędzy środowiskami DEV i PROD są od razu zauważane, nie w momencie budowania paczki releas’owej
  • przy zachowaniu dobrych praktyk pracy z systemem kontroli wersji, każdy członek zespołu pracuje na najnowszej wersji, co minimalizuje sytuacje wymagające rozwiązywania konfliktów w kodzie, a dzięki build serwerowi wie, czy „zaciągać” zmiany czy nie.

Powiem jeszcze o tym, co dają nam build serwery oprócz „nadzoru” nad stanem aktualnym różnych wersji naszej aplikacji/systemu.

  • Jeżeli mamy taką potrzebę, w każdym momencie można postawić wersję na środowisku testowym, pokazać to klientowi, zrobić jakieś większe testy, nawet deployować aplikację codziennie. Ba! Nawet po każdym commit-push!
  • Wreszcie, moim zdaniem najważniejsze, ściągamy z własnych, programistycznych barków brzemię budowania paczek release’owych ręcznie. Z doświadczenia wiem, że bez wdrożonego CI zrobienie bezbłędnego release’u, w sposób ręczny, graniczy z cudem. Zawsze „coś się zapomni”, a to nowe ustawienie w configu, a to jakaś nowa dll’ka, a to wersja nie z tej gałęzi co trzeba, itp. itd. To jest trudne, zwłaszcza w dobie modnych mikroserwisów, gdzie tych elementów, które trzeba puścić w Świat może być zdecydowanie za wiele! W tym przypadku, cały deploy na produkcję, a jeśli chcemy to i release, odbywa się praktycznie bez udziału ludzkiej ręki.

W każdym bądź razie, ja nie o tym chciałem…

 

Warsztat

Jak już wspomniałem, tematem niniejszego cyklu będą narzędzia. Dostarczają one zazwyczaj możliwość zarówno ciągłej integracji jak i automatycznych wdrożeń. Opiszę pokrótce te najpopularniejsze. Skonfiguruję każde z nich i spróbuję wdrożyć swój przykładowy projekt za ich pomocą, na moim „środowisku produkcyjno-testowym”.

  • Raspberry Pi 3 podłączone do lokalnej sieci LAN.
    • Linux Ubuntu 16.04.3 LTS – Mate Desktop 1.16.2.
    • baza danych MySQL 14.14 Distr 5.7.21.
    • repozytorium na GitHub
PowerMalina v1.1

Pendrive’m się nie przejmujcie. On daje +10 do FUN’u, dzięki czemu malina jest szybsza …tak myślę

 

Jeszcze nie wiem czy malina będzie spełniać rolę build maszyny czy może raczej środowiska produkcyjnego. Możliwe że, obu.

 

Arsenał

Narzędzia na tapecie:

  • Jenkins – znany, popularny. Napisany w Javie. Open-Source’owy na licencji MIT.
  • TeamCity – również znany. Również napisany w Javie przez JetBrains. Produkt komercyjny, ale dostępna jest wersja na licencji Freemium (do 100 konfiguracji i 3 build agentów). Projekty Open-Source mogą dostać licencję Free.
  • Team Foundation Server – jest to integralna część Visual Studio Team Foundation Services
  • Bambooprodukt Atlassian’a. Dostępny jako usługa
  • CircleCI – rozwiązanie które umożliwia utworzenie własnego build serwera u siebie, opartego o własną infrastrukturę, ale również udostępnia usługi w formie build serwera
  • Travis CI – to rozwiązanie oferuje build serwer tylko w formie usługi i co ciekawe, projekty open-source z repozytourium na GitHub można „prowadzić” za free

 

Po więcej informacji nt. Continuous Integration i build serwerów odsyłam do Wikipedii.

W kolejnym poście tej serii, noszącym tytuł – „Atrybuty smoczego pogromcy”. Opiszę dwa WebApi (C#, Python) jakie napiszę na potrzeby niniejszej „zabawy”.

 

Oczywiście zachęcam do komentowania i subskrypcji mojego newslettera!

 



 

About the author

Add comment

By Patryk

Autor serwisu

Patryk

Społecznościowe

Instagram

Newsletter



Historycznie

Tagi