SKOK NA NADERWANYM BUNGEE, CZYLI AGILE BEZ AUTOMATYZACJI

Witold BołtTeam Leader

wbolt@jitsolutions.pl

Barłomiej ZiębaSoftware Architect

bzieba@jitsolutions.pl

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ówTechnology stack: Java EE, JSF, Hibernate, MS SQLMały zespół: 2 x developer + 1 x testerSCRUM, 1 tygodniowe sprinty – łączenie 5 sprintówok. 60 MD pracy, 7500 LOC + 7500 LOC testów455 CI builds

Środowisko wytwórcze

Wyzwania i problemy

Klient zewnętrzny ma dostęp „read” do wszystkiegoKonfiguracja środowiska jednym z dostarczanych produktów

Integracja z systemami klienta: 2 x consume, 1 x provideNiestabilna infrastruktura linii – zmieniliśmy datacenter w trakcieNiestabilne testy Selenium WebdriverMS SQL 2012

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?

Projekt „legacy”

Projekt bankowy rozwijany od latWiele starego kodu w różnych technologiachSporo nowego kodu Java EESkomplikowana struktura środowisk testowych

Było

Jest

Jest

Niestabilna infrastruktura środowisk integration, QA i preliveBlokada 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, warsztatyGitflow, relalizowany na (i przez) Jenkinsie2 poziomy reguł SonaraDokumentacja z kodu, info dla monitoringu – na wiki

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 powodów „losowych”?

Środowisko CI to system produkcyjny!

DO: Jenkins per projekt

Wiele projektów? Systemów? Zespołów?Wiele środowisk CI!Wydajność, stabilność, pewność...Skomplikowane zarządzanie? Zautomatyzuj to!

DO: Wersjonuj WSZYSTKO

Skrypt administracyjnePliki konfiguracyjneBaza danychDefinicja jobów CI, konfiguracja workflow

... WSZYSTKO co się da trafia do SCM!

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!

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ą!

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!

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.

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?

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!

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!

DO: Szybki feedback negatywny

Build & package

Unit tests

Integration tests

Deploy

Automated functional tests

Dziel duże joby na kawałkiW pierwszej kolejności uruchamiaj:

To co działa szybkoTo co ma dużą szansę się wywalić

Zespół powinien szybko wiedzieć, że jest źle – o ile jest ;)

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!

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ć?

DO: ADD = Automation Driven Design

Projektuj z myślą o automatyzacjiWybieraj rozwiązania, które dają się automatyzować i wersjonować

DO: Rozwijaj się w kierunku automatyzacji

Warto się rozwijać w obszarze automatyzacji procesów!Warto inwestować w automatyzację!

Do dzieła!

Dzięki!

Witold Bołtwbolt@jitsolutions.pl

Bartłomiej Ziębabzieba@jitsolutions.pl

Online:www.facebook.com/jitsolutions.gdynia

www.jitsolutions.pl