Jak oszczędzać czas zespołuw środowisku mikroserwisów,

czyli efektywny flow wytwarzania oprogramowania

1

Prawo Conway’a

Organizacja będzie produkowała taki kod, jak jej struktura komunikacji

2

Ilu z Was pracuje w środowisku mikroserwisów?

3

Jak oszczędzać czas zespołuw środowisku mikroserwisów,

czyli efektywny flow wytwarzania oprogramowania

4

Mateusz PaprockiChief 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

• 10 lat na rynku

• 31 zgranych osób

• siedziba we Wrzeszczu (Biała 1)

6

• startup development

• outsourcing

• API integration

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

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

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

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

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

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

JaCoCo - code coverage

13

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

Sonar - Główne metryki

15

Sonar - Podgląd projektu

16

Docker

• Wyizolowane środowisko

• Developer nie ma potrzeby “grzebania” w obrazie

• Prosty setup na środowisku lokalnym

• Repozytorium dockerów (docker repository)

17

Frontend containers

• NPM registry - generatory + skrypty Grunt

• Bower repository

• Nexus + Amazon S3 - trzymanie buildów

18

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

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

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

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

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

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

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

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

Podsumowanie

27

Stary vs Nowy flowStary flow Nowy flow

Czas deploymentu + testy [s] 1800 60Liczba zaangażowanych osób 3 1Komunikacja [s] 300 0Czas finalny [h] 0,58 0,02

Czas w skali miesiąca (3 buildy dziennie) [h] 35,00 1,00

Odwiedź nasBiała 180-435 Gdańsk

E-mailmpaprocki@neoteric.eurekrutacja@neoteric.eu

Zadzwoń+48 602 557 952

Webwww.neoteric.eufacebook.com/neoteric-eu