6. PROBLEMY
• Duży narzut na testy przed wydaniem wersji
• Brak specyfikacji, wymagań, kryteriów akceptacji
• Nie do końca spełnione oczekiwania klientów
• Duży koszt utrzymania starszych fragmentów kodu,
brak testów
• Długi czas wydania poprawki dla aplikacji mobilnej
• “Wrzutki”
12. ZESPÓŁ SZYBKIEGO REAGOWANIA
• Szybka reakcja na krytyczne bugi
• Zajmowanie się wrzutkami, wydawaniem wersji
• Wdrażanie nowych technologii i rozwiązań
• Codzienne daily
• Tablica z aktualnymi zadaniami i priorytetami
• Brak sprintów i spotkań scrumowych
13. Co zyskaliśmy?
• lepiej opisane zadania i
zdefiniowane cele
• brak “przeskakiwania” między
zadaniami
• testy od razu po
developmencie
• szybki feedback i bug fixing
• wzrost ogólnej jakości
produktu
• Częstsze wydania
14. CONTINUOUS INTEGRATION
Praktyka stosowana w trakcie rozwoju
oprogramowania, polegająca na
częstym, regularnym włączaniu
(integracji) bieżących zmian w kodzie do
głównego repozytorium
18. Jenkins
• Budowanie wersji przy każdym commicie
• Budowanie konkretnych gałęzi
• Dostępne kilka wersji (podpisy, package name,
platforma) per build
• Źródło wersji do testów i wydawania
• Dodatkowe metryki (np. Lint, pokrycie kodu)
19. CO ZYSKALIŚMY?
• Zautomatyzowany i
konfigurowalny proces budowania
aplikacji
• Szybka informacja zwrotna o
statusie
• Zawsze działający kod w
repozytorium
• Łatwy dostęp do wersji testowych
czy kandydatów do wydania
• Stały wgląd do metryk
21. Gerrit
• Narzędzie do inspekcji kodu online w przeglądarce
• Darmowy
• Tworzony przez Google
• Integruje się z Gitem i Jenkinsem
22.
23.
24. Do czego używamy code review?
• Część mobilna
• Przypadki testowe
• Tłumaczenia
• Część serwerowa
25. CO ZYSKALIŚMY?
• Podział i wymiana wiedzy w
zespole
• Zwiększona jakość aplikacji
• Czytelniejszy, łatwiejszy do
utrzymania kod
• Wcześniejsze wyłapywanie
potencjalnych błędów
• Wprowadzanie standardów
kodowania