SKOK NA NADERWANYM BUNGEE,
CZYLI AGILE BEZ AUTOMATYZACJI
Witold Bołt
Team Leader
wbolt@jitsolutions.pl
Barłomiej Zięba
Sof...
Wprowadzenie
Kilka słów o tym co większość z Was już wie?
Wprowadzenie
Wprowadzenie
Wprowadzenie
Wprowadzenie
Wprowadzenie
Wprowadzenie
Wprowadzenie
Wprowadzenie
Wprowadzenie
Przykład:
Projekt „green field”
Kiedy zaczynasz od zera, możesz wszystko
zrobić dobrze? Albo i nie...
Green-field project
Aplikacja biznesowe do generowania dokumentów
Technology stack: Java EE, JSF, Hibernate, MS SQL
Mały z...
Środowisko wytwórcze
Wyzwania i problemy
Klient zewnętrzny ma dostęp „read” do wszystkiego
Konfiguracja środowiska jednym z dostarczanych produ...
Przykład:
Projekt typu „legacy”
Co zrobić gdy stoi za nami kupa ...
wcześniejszych doświadczeń, sukcesów,
słusznych decyzj...
Projekt „legacy”
Projekt bankowy rozwijany od lat
Wiele starego kodu w różnych technologiach
Sporo nowego kodu Java EE
Sko...
Było
Jest
Jest
Niestabilna infrastruktura środowisk integration, QA i prelive
Blokada organizacyjna na poziomie release
„One repo to...
Wzorce i antywzorce
automatyzacji
Kilka praktycznych porad...
DO NOT: Niestabilne środowisko / testy
Słaby sprzęt /
infrastruktura?
Niska wydajność i
dostępność?
Częste faile testów z
...
DO: Jenkins per projekt
Wiele projektów?
Systemów? Zespołów?
Wiele środowisk CI!
Wydajność, stabilność,
pewność...
Skompli...
DO: Wersjonuj WSZYSTKO
Skrypt administracyjne
Pliki konfiguracyjne
Baza danych
Definicja jobów CI,
konfiguracja workflow
....
DO NOT: Sonar overkill
Cel: zero naruszeń w
Sonarze?
Kary dla programistów,
którzy naruszają reguły?
Blokowanie commitów?
...
DO: Power to the people!
Oddzielny dział/zespół
rządzący środowiskiem CI?
Specjalne pozwolenie na
wykonanie builda?
Wniose...
DO NOT: Zmieniamy wszystko na raz!
Stan obecny – wszystko
robimy ręcznie?
Co chcemy osiągnąć w
jednym kroku? Wszystko
auto...
DO NOT: „za wcześnie na automatyzację”
„Póki co nie ma czego
testować... Pomyślimy o
testach później!”
„Automatyczny
deplo...
DO: Hello World!
Testuj infrastrukturę CI!
Mini-projekt „hello world”
– czy przechodzi
poprawnie cały proces?
Czy każdy ro...
DO NOT: te testy zawsze failują - spoko
„Spoko, te 6 testów
zawsze failuje...”
„Nie ma problemu – te
testy nie działają bo...
DO: Chodzi o informacje!
Propaguj informacje!
Lampy, odgłosy, ekrany,
maile, SMS, IM, spotkania
poranne... cokolwiek co
dz...
DO: Szybki feedback negatywny
Build & package
Unit tests
Integration tests
Deploy
Automated
functional tests
Dziel duże jo...
DO NOT: ręczne poprawki po automatach
Build się nie udał?!
Spokojnie – umiem to
naprawić... ssh, cp, rm,
vim, deploy.sh, D...
DO: Refactoring linii produkcyjnej
Czy wszystkie narzędzia, które
mamy są nam potrzebne?
Czy osiągamy korzyści z
naszych p...
DO: ADD = Automation Driven Design
Projektuj z myślą o
automatyzacji
Wybieraj rozwiązania,
które dają się
automatyzować i
...
DO: Rozwijaj się w kierunku automatyzacji
Warto się rozwijać w
obszarze automatyzacji
procesów!
Warto inwestować w
automat...
Dzięki!
Witold Bołt
wbolt@jitsolutions.pl
Bartłomiej Zięba
bzieba@jitsolutions.pl
Online:
www.facebook.com/jitsolutions.gd...
infoShare 2014: Witold Bołt, Bartosz Zięba, Skok na naderwanym bungee, czyli Agile bez automatyzacji.
Upcoming SlideShare
Loading in …5
×

infoShare 2014: Witold Bołt, Bartosz Zięba, Skok na naderwanym bungee, czyli Agile bez automatyzacji.

233
-1

Published on

Published in: Internet
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
233
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

infoShare 2014: Witold Bołt, Bartosz Zięba, Skok na naderwanym bungee, czyli Agile bez automatyzacji.

  1. 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. 2. Wprowadzenie Kilka słów o tym co większość z Was już wie?
  3. 3. Wprowadzenie
  4. 4. Wprowadzenie
  5. 5. Wprowadzenie
  6. 6. Wprowadzenie
  7. 7. Wprowadzenie
  8. 8. Wprowadzenie
  9. 9. Wprowadzenie
  10. 10. Wprowadzenie
  11. 11. Wprowadzenie
  12. 12. Przykład: Projekt „green field” Kiedy zaczynasz od zera, możesz wszystko zrobić dobrze? Albo i nie...
  13. 13. 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
  14. 14. Środowisko wytwórcze
  15. 15. 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
  16. 16. 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?
  17. 17. Projekt „legacy” Projekt bankowy rozwijany od lat Wiele starego kodu w różnych technologiach Sporo nowego kodu Java EE Skomplikowana struktura środowisk testowych
  18. 18. Było
  19. 19. Jest
  20. 20. 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
  21. 21. Wzorce i antywzorce automatyzacji Kilka praktycznych porad...
  22. 22. 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!
  23. 23. DO: Jenkins per projekt Wiele projektów? Systemów? Zespołów? Wiele środowisk CI! Wydajność, stabilność, pewność... Skomplikowane zarządzanie? Zautomatyzuj to!
  24. 24. DO: Wersjonuj WSZYSTKO Skrypt administracyjne Pliki konfiguracyjne Baza danych Definicja jobów CI, konfiguracja workflow ... WSZYSTKO co się da trafia do SCM!
  25. 25. 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!
  26. 26. 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ą!
  27. 27. 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!
  28. 28. 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.
  29. 29. 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?
  30. 30. 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!
  31. 31. 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!
  32. 32. 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 ;)
  33. 33. 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!
  34. 34. 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ć?
  35. 35. DO: ADD = Automation Driven Design Projektuj z myślą o automatyzacji Wybieraj rozwiązania, które dają się automatyzować i wersjonować
  36. 36. DO: Rozwijaj się w kierunku automatyzacji Warto się rozwijać w obszarze automatyzacji procesów! Warto inwestować w automatyzację! Do dzieła!
  37. 37. Dzięki! Witold Bołt wbolt@jitsolutions.pl Bartłomiej Zięba bzieba@jitsolutions.pl Online: www.facebook.com/jitsolutions.gdynia www.jitsolutions.pl
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×