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

2. Wprowadzenie
Kilka słów o tym co większość z Was już wie?

3. Wprowadzenie

4. Wprowadzenie

5. Wprowadzenie

6. Wprowadzenie

7. Wprowadzenie

8. Wprowadzenie

9. Wprowadzenie

11. Wprowadzenie

12. Wprowadzenie

13. Przykład:
Projekt „green field”
Kiedy zaczynasz od zera, możesz wszystko
zrobić dobrze? Albo i nie...

14. Green-field project
Aplikacja biznesowe do generowania dokumentów
Technology stack: Java EE, JSF, Hibernate, MS SQL
Mały zespół: 2 x developer + 1 x tester
SCRUM, 1 tygodniowe sprinty – łączenie 5 sprintów
ok. 60 MD pracy, 7500 LOC + 7500 LOC testów
455 CI builds

15. Środowisko wytwórcze

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

19. Było

20. Jest

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

22. Wzorce i antywzorce
automatyzacji
Kilka praktycznych porad...

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!

38. Dzięki!
Witold Bołt
wbolt@jitsolutions.pl
Bartłomiej Zięba
bzieba@jitsolutions.pl
Online:
www.facebook.com/jitsolutions.gdynia
www.jitsolutions.pl