CI oraz CD w złożonym projekcie o małym budżecie

Potrzeba Założenia Technologie Projekt Realizacja EOP
CI oraz CD w złożonym projekcie o małym
budżecie
Historia oparta na faktach
G. Godlewski
28 lutego 2016

O autorze
W wolnym czasie programuję pracując nad swoimi pomysłami,
trenuję karate, muzykuję i param się serowarstwem.

Podstawowe problemy
Zawsze brakuje:
Pieniędzy
Ludzi
Czasu
Wiedzy
Doświadczenia
Ludzie posiadają ograniczone możliwości uczenia się i pojmowania
wiedzy. Zrób jak najlepiej za pierwszym razem, nie będzie trzeba
do tego wracać.

Zakres do automatyzacji
Testy jednostkowe (co piszę)
Testy funkcjonalne (co klikam)
Składniki jakościowe (nightly build, code coverage, phpmd,
phpcs, jshint, jslint, ...)
Przygotowanie aplikacji do testów (deployment itp)
Wszystko co powtarzalne i wykonywane często!
Miejsc do szukania oszczędności czasu przez należy poszukiwać
ciągle.

Continuous Integration
Martin Fowler:
Continuous Integration is a software development
practice where members of a team integrate their
work frequently, usually each person integrates at least
daily - leading to multiple integrations per day. Each
integration is veriﬁed by an automated build (including
test) to detect integration errors as quickly as possible.

Continuous Delivery
Martin Fowler:
A common question we hear is “what is the diﬀerence
between Continuous Delivery and Continuous
Deployment?” Both terms are similar and were coined
around the same time. I see the diﬀerence as a business
decision about frequency of deployment into production.
Continuous Delivery is about keeping your application
in a state where it is always able to deploy into
production. Continuous Deployment is actually
deploying every change into production, every day or
more frequently.
A gdy nie jesteśmy pewni?
Automatyzacja do etapu staging, a potem ”promote to production”

12-factor app

Kodeks postępowania
Stosowanie zasada Pareta
Duże operacje mają być wykonywane jedną linijką - 3
działania i więcej - do skryptu
Rozwiązania mają być ładne, zgrabne, poprawne i lekkie w
utrzymaniu - „this small”
Małe i luźno powiązane elementy łatwiej się utrzymuje
Powtarzalność redukuje złożoność, stwórz konwencję i się jej
trzymaj
Projektuj i działaj w oparciu o kontrakty
Co się da i ma sens, przenoś do konﬁguracji z
udokumentowaną wartością domyślną

PHP
7.0.3 - nowość, nowość nowość!
composer - zarządzanie zależnościami
phing - kontrakt pomiędzy projektem a systemem CI
wszystko z czym można eksperymentować (PHP Data
Structures itp)

Silex
Bardzo mały footprint
Kompatybilny z najnowszym PHP
Dostarcza łatwej obsługi Request i Response
Na etapie budowania prostych API nie potrzebuję nic więcej
Ładnie się integruje z pozostałymi komponentami Symfony

TeamCity
Wersja darmowa:
3 build agent’y
20 build configurations
Duże możliwości w zakresie konfiguracji (parametry buildów,
szablony konfiguracji, definiowanie zależności etc)

Git
Bo wszystko inne to herezja
BitBucket - prywatne repozytoria za darmo do 5 osób, dla
małych zespołów idealne rozwiązanie
TeamCity VCS root bardzo ładnie się integruje i wspiera Git

Bash / Make
Stosowanie podejścia: conﬁgure, make, make install (temat
zamknięty w 3 krokach)
Skrypty wspomagające / upraszczające uruchamianie /
restartowanie aplikacji
Każde zadanie wymagające co najmniej 3 kroków należy
złożyć do 1 skryptu

Docker
Przeprowadzanie procesu CI wewnątrz izolowanych
kontenerów (docker in docker, sic!)
Zapewnienie ‘opakowania dla produktu‘, w którym będzie
wysyłany na serwer
Prywatny Docker Hub (run in docker) - musimy gdzieś
udostępniać budowane obrazy
Rozszerzanie dostępnych obrazów i ich dostosowanie do
naszych potrzeb
Docker Compose w celu uruchamiania grup kontenerów (w
szczególności 1 element)

Ansible
Opisanie sposobu dostarczenia produktu do odbiorcy
(deployment na serwer)
Zarządzanie infrastrukturą (zapewnienie odpowiedniej
konﬁguracji)
Bardzo dobra dokumentacja
Bardzo duża liczba modułów - jeszcze nie traﬁłem na
konieczność pisania własnych

Sposób postrzegania produktu

Cykl życia produktu
Produkcja - składanie z części, diagnostyka, usunięcie
zbędnych elementów
Pakowanie - gotowy produkt złożony tylko z części
ﬁnałowych pakowany jest w pudełko / kontener
Dostarczenie - przekazanie do odbiorcy - pod wskazany
adres, w określony sposób
Każdy z etapów procesu ma jasno określone granice - wejście /
wyjście

Kompletne rozwiązanie
W przypadku produktu złożonego z wielu komponentów, możemy
posłużyć się analogią do zakupu zestawu kuchennego:
Wszystkie pudełka zawierają komponenty produkty
spełniające szereg wymogów
Wiemy jak komponenty mają być ze sobą połączone
Wiemy jak komponenty powinny być rozmieszczone docelowo
w infrastrukturze klienta

Przepływ pracy

Repozytoria
W pracy z dużą liczbą repozytoriów może pomóc zastosowanie
konwencji:
Szablon
(1) [ p r o j ]−source −[x ]
(2) [ p r o j ]−image −[x ]
(3) [ p r o j ]−image −[x]−dev
1 Kod źródłowy produktu
2 Kod źródłowy obrazu, który będzie zawierał gotowy produkt
3 Kod źródłowy deweloperskiej wersji obrazu dla produktu
Przykład
foo−source−s e r v i c e −payment
foo−image−s e r v i c e −payment
foo−image−s e r v i c e −payment−dev

Zatrudniamy agentów

Rozszerzanie obrazów

Plan działań
1 Przygotowanie projektu (projektów) do CI
2 Przygotowanie infrastruktury pod CI
3 Przygotowanie samego serwera CI
4 Opracowanie konﬁguracji (Build Conﬁgurations)

Przygotowanie projektu
Pełna dowolność użycia narzędzia: make, phing, ant, maven -
dosłownie cokolwiek, byle by z głową.
Jedną komendą powinniśmy być w stanie (zadanie dla build
agent’a):
Podłączyć wszystkie wymagane zależności
Przeprowadzić diagnostykę
Zdemontować zależności niewymagane przez odbiorcę
Przygotować paczkę do dystrybucji

Budowanie samego projektu
<?xml version="1.0"?>
<project name="Project name" default="build">
<target name="build">
<phingcall target="clean" />
<phingcall target="configure" />
<phingcall target="dependencies-dev" />
<phingcall target="tests" />
<phingcall target="assets" />
<phingcall target="dependencies-dist" />
<phingcall target="package" />
</target>

Budowanie samego projektu
Plik build.xml zawiera opis wszystkich operacji - stanowi pomost
pomiędzy projektem, a agentem.
Wykonywanie build’u
$ phing
Domyślny build target: build.
W każdym komponencie systemu (serwisie etc), który będzie
budowany przez serwer CI należy stosować to samo podejście -
powtarzalność redukuje złożoność!

Przygotowanie infrastruktury
1 Odpowiedni kernel (już od 3.10!)
2 Odpowiednie moduły kernela (aufs, devicemapper itp - zależy
od distro)
3 Zainstalowany docker
4 Zainstalowany docker-compose

Pułapka Docker i DeviceMapper
Jeżeli używacie sterownika devicemapper, zwróćcie uwagę aby
Udev Sync Supported było ustawionena true.

Przygotowanie serwera
Docker Hub (registry)
Serwer TeamCity (sjoerdmulder/teamcity)
Agenty TeamCity (sjoerdmulder/teamcity-agent)
W rzeczywistym zastosowaniu powinniśmy mieć swój
wyspecjalizowany obraz agent’a, rozszerzający wspomniany wyżej.

Docker Hub
hub:
restart: always
image: registry:2
ports:
- "5000:5000"
environment:
TERM: linux
REGISTRY_HTTP_TLS_CERTIFICATE: :)
REGISTRY_HTTP_TLS_KEY: :)
REGISTRY_AUTH: htpasswd
REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
volumes:
- "/home/docker-distro/registry/data:/var/lib/registry"
- "/etc/ssl/certs:/certs"
- "/etc/ssl/private:/keys"
- "/home/docker-distro/registry/auth:/auth"

TeamCity Server
server:
image: "sjoerdmulder/teamcity:latest"
ports:
- "8111:8111"
volumes:
- "/home/teamcity/server/data:/var/lib/teamcity"
environment:
TERM: linux

TeamCity Agent
agent:
image: "sjoerdmulder/teamcity:latest"
ports:
- "9090:9090"
volumes:
- "/var/run/docker.sock:/var/run/docker.sock" # docker in docker
- "/usr/bin/docker:/usr/bin/docker"
- "/usr/bin/docker:/usr/local/bin/docker"
- "/home/teamcity/agent/work:/opt/buildAgent/work" # work directories
- "/home/teamcity/agent/composer:/opt/composer/cache" # composer cache
- "/home/teamcity/agent/docker:/home/teamcity/.docker" # hub auth keys
environment:
TERM: linux
TEAMCITY_SERVER: "http://teamcity_server:8111" # your server
TEAMCITY_AGENT_NAME: "Alpha"
AGENT_HOME_ON_HOST: "/home/teamcity/agent"

Konfigurowanie serwera
Zdefiniować VCS roots, które będą używane
Określenie parametrów konfiguracji (nawet komend, szukanie
wspólnych mianowników
Zdefiniowanie konfiguracji build’u
Artefakty!
Zdefiniowanie zależności między konfiguracjami
Zdefiniowanie triggerów buildów

Wdrażanie
Zadanie dla Ansible:
Przygotowanie docker-compose.yml z odpowiednią wersją
obrazu do wdrożenia
Przygotowanie skryptów pomocniczych (start, stop, restart
itp).
Uruchomienie przy pomocy skryptu pomocniczego
Wszystkie dodatkowe zadania (ustawienie monitorowania itp).
Wasza infrastruktura wymusi konkretne kroki.

No dobra, ale co w przypadku projektu spadkowego?

Dziękuję za uwagę!
http://linkedin.com/in/ggodlewski
grzegorz@sorcerystudio.com
@GGodlewski

CI oraz CD w złożonym projekcie o małym budżecie

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie CI oraz CD w złożonym projekcie o małym budżecie

Ähnlich wie CI oraz CD w złożonym projekcie o małym budżecie (20)

CI oraz CD w złożonym projekcie o małym budżecie