Prezentacja z wykładu prowadzonego przez Witka Boła i Bartka Ziębę o automatyzacji procesów wytwórczych w zespołach softwareowych. Prezentacja odbyła się w ramach konferencji InfoShare 2014, 22.05.2014 w Gdańsku.
InfoShare 2014: Skok na naderwanym bungee, czyli agile bez automatyzacji
1. SKOK NA NADERWANYM BUNGEE,
CZYLI AGILE BEZ AUTOMATYZACJI
Witold Bołt
Team Leader
wbolt@jitsolutions.pl
Barłomiej Zięba
Software Architect
bzieba@jitsolutions.pl
16. Wyzwania i problemy
Klient zewnętrzny ma dostęp „read” do wszystkiego
Konfiguracja środowiska jednym z dostarczanych produktów
Integracja z systemami klienta: 2 x consume, 1 x provide
Niestabilna infrastruktura linii – zmieniliśmy datacenter w
trakcie
Niestabilne testy Selenium Webdriver
MS SQL 2012
17. Przykład:
Projekt typu „legacy”
Co zrobić gdy stoi za nami kupa ...
wcześniejszych doświadczeń, sukcesów,
słusznych decyzji, trafnych wyborów
i nie tylko?
18. Projekt „legacy”
Projekt bankowy rozwijany od lat
Wiele starego kodu w różnych technologiach
Sporo nowego kodu Java EE
Skomplikowana struktura środowisk testowych
21. Jest
Niestabilna infrastruktura środowisk integration, QA i prelive
Blokada organizacyjna na poziomie release
„One repo to rule them all” -> code split, repo split , nexus!
Wiele elementów systemu (kontenery aplikacji, ESB itp.)
Wsparcie w zespole wewnętrznym, warsztaty
Gitflow, relalizowany na (i przez) Jenkinsie
2 poziomy reguł Sonara
Dokumentacja z kodu, info dla monitoringu – na wiki
23. DO NOT: Niestabilne środowisko / testy
Słaby sprzęt /
infrastruktura?
Niska wydajność i
dostępność?
Częste faile testów z
powodów „losowych”?
Środowisko CI to system
produkcyjny!
24. DO: Jenkins per projekt
Wiele projektów?
Systemów? Zespołów?
Wiele środowisk CI!
Wydajność, stabilność,
pewność...
Skomplikowane
zarządzanie?
Zautomatyzuj to!
25. DO: Wersjonuj WSZYSTKO
Skrypt administracyjne
Pliki konfiguracyjne
Baza danych
Definicja jobów CI,
konfiguracja workflow
... WSZYSTKO co się da
trafia do SCM!
26. DO NOT: Sonar overkill
Cel: zero naruszeń w
Sonarze?
Kary dla programistów,
którzy naruszają reguły?
Blokowanie commitów?
Sztywne granice odnośnie
code coverage, rules
complience, itd.?
NIE!
27. DO: Power to the people!
Oddzielny dział/zespół
rządzący środowiskiem CI?
Specjalne pozwolenie na
wykonanie builda?
Wniosek o odświeżenie
środowiska?
Programiści i testerzy
rządzą!
28. DO NOT: Zmieniamy wszystko na raz!
Stan obecny – wszystko
robimy ręcznie?
Co chcemy osiągnąć w
jednym kroku? Wszystko
automatycznie!
NIE!
Małe kroki, walidacja,
mierzymy korzyści!
29. DO NOT: „za wcześnie na automatyzację”
„Póki co nie ma czego
testować... Pomyślimy o
testach później!”
„Automatyczny
deployment teraz to strata
czasu – jak będą testy UAT
to zrobimy.”
NIE! Zacznij tak szybko jak
to możliwe.
30. DO: Hello World!
Testuj infrastrukturę CI!
Mini-projekt „hello world”
– czy przechodzi
poprawnie cały proces?
Czy każdy rozumie
proces?
Czy każdy otrzymuje
odpowiedni feedback?
31. DO NOT: te testy zawsze failują - spoko
„Spoko, te 6 testów
zawsze failuje...”
„Nie ma problemu – te
testy nie działają bo baza
nie ma danych...”
Akceptacja dla błędów to
źródło wielkiego zła!
Co zrobić? Wywal popsute
testy albo je napraw!
32. DO: Chodzi o informacje!
Propaguj informacje!
Lampy, odgłosy, ekrany,
maile, SMS, IM, spotkania
poranne... cokolwiek co
działa dla Ciebie.
Informacja, z której nikt
nie korzysta jest
bezużyteczna!
33. DO: Szybki feedback negatywny
Build & package
Unit tests
Integration tests
Deploy
Automated
functional tests
Dziel duże joby na kawałki
W pierwszej kolejności
uruchamiaj:
To co działa szybko
To co ma dużą szansę się
wywalić
Zespół powinien szybko
wiedzieć, że jest źle – o ile
jest ;)
34. DO NOT: ręczne poprawki po automatach
Build się nie udał?!
Spokojnie – umiem to
naprawić... ssh, cp, rm,
vim, deploy.sh, DONE!
Zamiast ręcznie poprawić
popsuty build – popraw
automat!
35. DO: Refactoring linii produkcyjnej
Czy wszystkie narzędzia, które
mamy są nam potrzebne?
Czy osiągamy korzyści z
naszych procesów?
Czy wszystko jest poprawnie
zintegrowane?
Czy coś można zrównoleglić?
Czy coś jeszcze można
automatyzować?
36. DO: ADD = Automation Driven Design
Projektuj z myślą o
automatyzacji
Wybieraj rozwiązania,
które dają się
automatyzować i
wersjonować
37. DO: Rozwijaj się w kierunku automatyzacji
Warto się rozwijać w
obszarze automatyzacji
procesów!
Warto inwestować w
automatyzację!
Do dzieła!