infoShare 2014: Witold Bołt, Bartosz Zięba, Skok na naderwanym bungee, czyli Agile bez automatyzacji.
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 157 views

 

Statistics

Views

Total Views
157
Views on SlideShare
157
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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
  • 10. Wprowadzenie
  • 11. Wprowadzenie
  • 12. Przykład: Projekt „green field” Kiedy zaczynasz od zera, możesz wszystko zrobić dobrze? Albo i nie...
  • 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. Środowisko wytwórcze
  • 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. 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. Projekt „legacy” Projekt bankowy rozwijany od lat Wiele starego kodu w różnych technologiach Sporo nowego kodu Java EE Skomplikowana struktura środowisk testowych
  • 18. Było
  • 19. Jest
  • 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. Wzorce i antywzorce automatyzacji Kilka praktycznych porad...
  • 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. DO: Jenkins per projekt Wiele projektów? Systemów? Zespołów? Wiele środowisk CI! Wydajność, stabilność, pewność... Skomplikowane zarządzanie? Zautomatyzuj to!
  • 24. DO: Wersjonuj WSZYSTKO Skrypt administracyjne Pliki konfiguracyjne Baza danych Definicja jobów CI, konfiguracja workflow ... WSZYSTKO co się da trafia do SCM!
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. DO: ADD = Automation Driven Design Projektuj z myślą o automatyzacji Wybieraj rozwiązania, które dają się automatyzować i wersjonować
  • 36. DO: Rozwijaj się w kierunku automatyzacji Warto się rozwijać w obszarze automatyzacji procesów! Warto inwestować w automatyzację! Do dzieła!
  • 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