Każdy zespół pracujący w środowisku mikroserwisów boryka się z podobnymi problemami: jak dbać o jakość kodu, organizować feature branche, testować zmiany, budować kolejne wersje aplikacji, zarządzać środowiskami, czy, finalnie, doprowadzić do automatycznych release’ów. W prezentacji przygotowanej przez trójmiejski software house Neoteric zobaczymy jedną z koncepcji rozwiązania problemów. Przygotujcie się na solidną dawkę Jenkinsa, Dockera, GitFlow oraz Sonara!

1. Jak oszczędzać czas zespołu
w środowisku mikroserwisów,
czyli efektywny flow wytwarzania
oprogramowania
1

2. Prawo Conway’a
Organizacja będzie produkowała taki kod,
jak jej struktura komunikacji
2

3. Ilu z Was pracuje w środowisku
mikroserwisów?
3

4. Jak oszczędzać czas zespołu
w środowisku mikroserwisów,
czyli efektywny flow wytwarzania
oprogramowania
4

5. Mateusz Paprocki
Chief Operating Officer (COO), PMO Head @ Neoteric
• 10 lat doświadczenia w branży IT
• w Neoteric od sierpnia 2013
• Certyfikaty: PMP, MongoDB
(Dev + Admin)
5

6. • 10 lat na rynku
• 31 zgranych osób
• siedziba we Wrzeszczu (Biała 1)
6
• startup development
• outsourcing
• API integration

7. Stary flow - Backend setup (2013)
• Monolityczne aplikacje z wciągniętym jako zależność rdzeniem
(Core)
• Środowisko: Glassfish
• Java 6 + PostreSQL + MongoDB
• Komunikacja via REST API
• Środowiska: Dev (na maszynie developera) oraz Prod (u klienta),
brak Staging’u
7

8. Stary flow - Backend deploy (2013)
• Ręczne zbudowanie JARa na maszynie developera
• Login via WWW do Glassfish’a na Produkcji
• Upload JAR’a z maszyny developera, redeploy
• Ręczna zmiana pliku konfiguracyjnego na produkcji (/etc/app.conf)
8

9. Stary flow - Backend - Jakość i testy (2013)
• Unit testy krytycznych części logiki biznesowej
• Brak testów integracyjnych
• Testowanie funkcjonalności backendu za pomocą frontend’u aplikacji
• Brak metryk jakościowych oraz wydajnościowych
• Brak sensownej dokumentacji
• Brak szybkiego dostępu do logów
9

10. Stary flow - Frontend setup (2013)
• Monolityczne aplikacje; brak podziału na logiczne moduły
• Brak sensownego sterowania zależnościami, zarówno pomiędzy
modułami aplikacji, jak i zewnętrznych dostawców (plik index.html ze
wszystkimi plikami)
• Środowisko: AngularJS 1.0.x
• Komunikacja via REST API (serwis obudowujący $http)
• Środowiska: Dev (na maszynie developera) oraz Prod (u klienta), brak
Staging’u
10

11. Gitflow
• Cel: Proste tworzenie/zamykanie feature branches na Gitlab’ie
• 2 predefiniowane branch’e per projekt (master, development) +
dynamiczne branch’e per feature
• Maven plugin - jGitflow (Atlassian) komunikujący się z self-hosted
Gitlab
• Jenkins korzysta z feature branches do robienia build’ów
11

12. Jenkins + build
• Grade + Groovy
• sprawdza status branch’y w projekcie na Gitlab
• tworzy nowy job na podstawie przygotowanego wcześniej szablonu przy
napotkaniu nowego branch’a
• istnieją predefiniowane szablony ze zmiennymi na każdy typ brancha
• Docker (obraz per build) + docker-registry
• JaCoCo - code coverage
• SonarQube
12

13. JaCoCo - code coverage
13

14. Sonar - Główne metryki
• Pokrycie kodu (unit + integration)
• line coverage
• condition coverage
• Złożoność (complexity)
• Checkstyle (blocker, critical, major)
• Duplications
• Liczba i przyrost błędów (delta) pomiędzy buildami
14

15. Sonar - Główne metryki
15

16. Sonar - Podgląd projektu
16

17. Docker
• Wyizolowane środowisko
• Developer nie ma potrzeby “grzebania” w obrazie
• Prosty setup na środowisku lokalnym
• Repozytorium dockerów (docker repository)
17

18. Frontend containers
• NPM registry - generatory + skrypty Grunt
• Bower repository
• Nexus + Amazon S3 - trzymanie buildów
18

19. CI/CD
• Bazowy obraz maszyny (obecnie Digital Ocean)
• Env Tools zapewniają instalację wszystkich wymaganych aplikacji
• JSON: projekt | typ środowiska | [lista aplikacji]
• instalacja wszystkiego za pomocą jednego polecenia (również frontend!)
• automatyczne tworzenie baz danych (compose.io API)
• automatyczny reload proxy (nowe endpoint’y odpowiedzialnością
backend’u)
19

20. CI/CD
• Cała konfiguracja projektu trzymana na Gitlab’ie
• 1 repozytorium per typ środowiska (np. <project>-staging-conf)
• 1 katalog w repo per projekt, w każdym 1 lub więcej plików
konfiguracyjnych
• 1 plik z konfiguracją proxy
20

21. Nowy flow - Backend setup
• Mikroserwisy (Jetty) rozmawiające via REST API
• Kolejka xMQ
• Środowisko: mikroserwer Jetty + Apache/Nginx do hostowania frontu
• Java 8 + MongoDB (compose.io) + NodeJS (Sails)
• Komunikacja via REST API
• Środowiska: Local (na maszynie developera), Dev, Staging, Prod
21

22. Nowy flow - Backend deploy
• Push do feature branch’a
• Ewentualna zmiana konfiguracji proxy (jeżeli doszedł nowy
endpoint)
• Automatyczny deploy na Dev, 1-click deploy na Staging i/lub Prod
22

23. Nowy flow - Backend - Jakość i testy
• Pokrycie min. 60%, zwykle 90%+
• Testy integracyjne uruchamiane na Jenkinsie podczas build’u
• [In progress] Testy E2E całego API
• SonarQube pilnujący jakości
• Generowana na bieżąco i łatwo dostępna, interaktywna dokumentacja
(Swagger)
• Logi na stacku ELK (Elastic, Logstash, Kibana)
23

24. Nowy flow - Frontend setup
• Modularne aplikacje z hierarchicznymi modułami, dynamiczne
budowanie menu
• Automatyzacja: Grunt + yeoman (generowanie nowego projektu z
wyborem wersji core’a)
• Zależności w RequireJS + Lazy loading
• Środowisko: AngularJS 1.4.X
• Środowiska: Local (na maszynie developera), Dev, Staging, Prod
24

25. Nowy flow - Frontend setup
• Automatyczne unit testy
• Automatyczne testy E2E: BDD (Cucumber + Gherkin)
• uruchamiane przy merge request’s
• fail na teście E2E informuje Gitlab’a - brak zgody na merge’a
25

26. Podsumowanie
• Postawienie nowego środowiska w mniej niż 10 minut
• Developerzy skupieni na dostarczaniu nowych rozwiązań, nie
konfiguracji
• Testowanie integralną częścią procesu produkcji
• Żywy DevOPS
26

27. Podsumowanie
27
Stary vs Nowy flow
Stary flow Nowy flow
Czas deploymentu + testy [s] 1800 60
Liczba zaangażowanych osób 3 1
Komunikacja [s] 300 0
Czas finalny [h] 0,58 0,02
Czas w skali miesiąca
(3 buildy dziennie) [h] 35,00 1,00

28. Odwiedź nas
Biała 1
80-435 Gdańsk
E-mail
mpaprocki@neoteric.eu
rekrutacja@neoteric.eu
Zadzwoń
+48 602 557 952
Web
www.neoteric.eu
facebook.com/neoteric-eu