Ar jums pažįstama situacija, kai IT sprendimas yra kuriamas ilgai ir rezultatą gaunate tik projekto pabaigoje? Tiek dirbant su išoriniu tiekėju, tiek su vidine komanda, norint pasiekti gerą rezultatą ir gauti naudą kuo anksčiau geriausia IT sprendimus kurti ir diegti kuo mažesnėmis dalimis - iteracijomis. Kiekvienos iteracijos rezultatas - funkcionalumo prieaugis, plečiantis arba gerinantis sistemos veiksmingumą. Efektyviausi būdai tai pasiekti - kruopštus darbų planavimas ir procesų automatizavimas. Pranešimo metu pranešėjai pasidalino žiniomis ir patirtimi apie DevOps išteklius, praktikas ir veiklas, būtinas agile projektui, siekiant automatizuoti diegimus į testavimo ir/arba gamybinę aplinkas. Pristatymas pagrįstas kompleksinio mikroservisais grįsto (angl. microservice) produkto Scaled Agile gamybos patirtimi.

1. Diegimo etapas
prasideda nuo
pirmos iteracijos...
ir niekada nesibaigia
Agile Lietuva meetup
2021 vasario 18 d
https://www.imdb.com/title/tt0107048/mediaviewer/rm4118549504/

2. Aleksej Kovaliov
https://www.linkedin.com/in/aleksejkovaliov
Aleksandr Kublickij
https://www.linkedin.com/in/aleksandr-k/
Icons from thenounproject.com

3. Apie ką kalbėsime
Įvadas - prie ko čia Agile ir kažkokie tai diegimai
EIS Engineering
Kaip mes tai darome
Išmoktos pamokos
Patarimai LR viešajam sektoriui

4. Prie ko čia Agile ir kažkokie tai diegimai?
arba
iš Mamutų gyvenimo
https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D0%BC%D0%BE%D0%BD%D1%82%D1%8B#/media/%D0%A4%D0%B0%D0%B9%D0%BB:Woolly_mammoth_(Mammuthus_primigenius)_-_Mauricio_Ant%C3%B3n.jpg

5. Agile numato greitą
Tiekimo ciklą ir Naudotojų grįžtamąjį ryšį
XP: Short feedback
Scrum: Reducing cycle time to absolute minimum
Lean: Decide as late as possible and Deliver as fast as possible
Kanban: Incremental change
...
...ir palieka mūsų fantazijoms, kaip tą greitį užtikrinti

6. Tiekimo ciklas →
Programinis
kodas
Surinkimas
(Build)
Lokalus
testavimas
Versijos
paleidimas
(Release
Candidate)
Diegimas
testavimo
aplinkoje
(Staging)
Integruotas /
Priėmimo
Testavimas
Ten dar visokios
analizės, detalios
analizės,
projektavimas,
testo scenarijų
rašymas…..
Diegimas
gamybinėje
aplinkoje
(Release)
Atsukimas
(Rollback)
← Naudotojų grįžtamasis ryšis

7. Back End
Microservices
Web and Mobile Apps
UI
Gateways
Data
Core
Components
Business
Components
Core
Components
Business
Components
Operational
Perception
Big Data
Tooling
Šiuolaikiško Mamuto Anatomija

8. Dar viena Mamuto anatomijos dalių dimensija
Resursai ir
priklausomybės
Programinis
kodas
Diegimo
artefaktai
Konfigūracijos
Atviro kodo
komponentai
Trečiųjų šalių
komponentai
Kiti jūsų gamybos
komponentai
Senas kodas
Naujas kodas
Nebaigtas kodas
(branched)
Lokaliam
testavimui
Testavimo
aplinkoms
Gamybinėms
aplinkoms
Vamzdynai
Konteineriai
Vaizdai
Surinktos versijos

9. Ne visi Mamutai vienodi
Copy of an interpretation of the "Adams mammoth" carcass from around 1800, with Johann Friedrich Blumenbach's handwriting
https://en.wikipedia.org/wiki/Woolly_mammoth
Tipinis didelių
informacinių
sistemų
mamutų
šeimos
atstovas

10. Mamuto darymas Agile būdu - kaip Mamuto dalių ir
dimensijų krūvelės pavirsta KALNAIS
Iteracija 1 Iteracija 2 Iteracija 3 Iteracija 4 ... Iteracija 20 ...
Priklausomybių
artefaktai
Funkcionalumo
artefaktai
???
Kaip šioje iteracijoje
įsitikinti, kad maža to,
kad iteracijos rezultatai
veikia, bet ir viskas, kas
buvo prikaupta anksčiau
vis dar veikia, veikia
kartu, nesupuvo ir
neapaugo saugos
skylėmis?

11. Padarykime visą tai Agile -
sutalpinkime į trumpą iteraciją ir dar gaukime grįžtamąjį ryšį!
● Krūva išorinių ir vidinių priklausomybių, kurios keičiasi
● Krūva programinio kodo, kuris arba nesikeičia, arba keičiasi dalinai
● Krūvelė naujo kodo (iteracijos rezultatai)
● Naujos krūvelės testai
● Testai viso, kas buvo anksčiau
● Diegimas daugelio artefaktų daugelyje vietų pasirinktoje aplinkoje
● Diegimo kartojimas kelis kartus / keliose aplinkose
● ...dar 10+ Scrum komandų

12. Gal padės geresnė Agile komandos motyvacija?
6 tips to boost team motivation. https://www.ntaskmanager.com/blog/team-motivation-tips/
… #6 - Having Fun?

13. Nepadės
https://www.govenuemagazine.com/ac-dcs-highway-to-hell-40th-anniversary/
● Nes netgi labai motyvuoti žmonės daro klaidas
● Nes augant kompleksiškumo lygiui
○ Žmogiškosios klaidos neišvengiamos, nesvarbu, kiek reglamentuoti procesą
○ Rankinis pasikartojančių rutininių operacijos darymas - brangiausias būdas
● Nes labai motyvuoti žmonės pastoviai darydami sudėtingas rutinines
operacijas pavirsta labai demotyvuotais žmonėmis
○ Rutininės operacijos yra “waste” iš principo, nes nekuria paties produkto

14. Reikia specialiųjų techninių priemonių ir automatizavimo
https://www.synopsys.com/glossary/what-is-cicd.html

15. CICD
Programinis
kodas
Surinkimas
(Build)
Lokalus
testavimas
Versijos
paleidimas
(Release
Candidate)
Diegimas
testavimo
aplinkoje
(Staging)
Integruotas /
Priėmimo
Testavimas
Diegimas
gamybinėje
aplinkoje
(Release)
Atsukimas
(Rollback)
Continuous Integration (CI)
Continuous Delivery (CD)
https://www.clipartkey.com/view/iRJxooT_transparent-clipart-cartoon/
Priemonės suvaldyti ir ganyti
Mamutus
Agile būdu

16. https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D0%BC%D0%BE%D0%BD%D1%82%D1%8B#/media/%D0%A4%D0%B0%D0%B9%D0%BB:Woolly_mammoth_(Mammuthus_primigenius)_-_Mauricio_Ant%C3%B3n.jpg
Mamutų paleidimai kiekvieną sprintą
V1.1
Pirmas ir
atsilikęs
V1.2
Šiek tiek kreivas
V1.3
V1.4

17. Kaip mes tai darome

18. Mūsų “Mamutas”
~30 Teams
Lithuania, Belarus, Ukraine, Latvia, USA, China
~50 Releasable Components
Libraries, frameworks, Microservices, UI, Configurations
https://www.eisgroup.com/digital-insurance-solutions/eis-suite/

19. Mūsų “Mamuto” paleidimas (1)

20. Mūsų “Mamuto” paleidimas (2)
7 pakopos pilnai
naujai versijai
išleisti
Atskirų
komponentų
naujinimai
(hotfixes) gali
būti išleidžiami
atskirai

21. Mūsų įrankiai (1)
Programinio kodo valdymas:
● https://about.gitlab.com/
● Kodo valdymas, sekimas
● Yra nemokama versija*
Konteinerizavimas:
● Kubernetes
● Docker

22. Mūsų įrankiai (2)
● Surinkimas (Build)
● Diegimas (Deploy)
● Testavimas
● Pakeitimų kontrolė (Commit Gating)
● Paleidimas (Release)
GitLab kodas Surinkimas Diegimas Testavimas Paleidimas

23. Saugumas !
Skenuojamas kodas, naudojamos bibliotekos, aplikacijų konteineriai ir t.t.
● OWASP skenavimas
○ https://owasp.org/ The Open Web Application Security Project
● Statinis kodo skenavimas (SonarQube)
○ https://www.sonarqube.org/
● “Docker” konteinerio skenavimas
○ https://docs.docker.com/engine/scan/

24. Kelias nuo monolito iki sistemos komponentų atskyrimo (1)
Nepaisant Mikroservisų architektūros pirma
kodo ir CI versija gavosi monolitinė (iš įpročio)
● Paleidimas (“Release”) užtrunka ~6 val.
● Skubūs taisymas (“Hot Fix”) = Paleidimas
● Surinkimas (“Build”) po kiekvieno
papildomo pakeitimo
● Itin sunkus pakeitimų išėmimas
https://cdn.nybooks.com/wp-content/uploads/2020/10/3.jpeg

25. Kelias nuo monolito iki sistemos komponentų atskyrimo (2)
● Monolitinės aplikacijos vystymas - lyg vieną
knygą rašytų 50 autorių. Vienu metu.
● Kiekvieno pakeitimo tikrinimas užtrunka kelias
valandas

26. Kelias nuo monolito iki sistemos komponentų atskyrimo (3)
Bendras Kodas
A B ... N
https://www.vectorstock.com/royalty-free-vector/rocket-space-rocket-launch-project-start-up-vector-22269709
6 valandos
O
+1 val

27. Kelias nuo monolito iki sistemos komponentų atskyrimo (4)
Bendras Kodas
A B ... N
https://www.vectorstock.com/royalty-free-vector/rocket-space-rocket-launch-project-start-up-vector-22269709
1 valanda
2 valandos
1 valanda 30 min N

28. Ko mums pavyko pasiekti?
● “Skaldyk ir valdyk” - pavyko išlygiagretinti, surinkimo paleidimo ir kitus procesus
● Naujų komponentų pridėjimas beveik neprailgina bendro surinkimo arba
paleidimo laiko
● Skubūs taisymas (“Hot fix”) - įmanomas atskiras tik paveiktų komponentų
taisymas. “Hot fix” pristatymas užtrunka nuo 15 min iki 1 valandos
● Naujų komponentų pridėjimas - standartizuotas procesas
● Kiekviena komanda dirba tik prie savo komponento (-ų) projekto, kiek įmanoma
mažiau įtakojant kitas

29. Organizacija
● DevOps - atskira komanda
○ Pagrindiniai klientai - Programavimo komandos
○ Pagrindinis tikslas - greitas naujų pakeitimų diegimas + nuolatinis CI tobulinimas
○ Vidinė palaikymo tarnyba su skirtingomis rolėmis
■ “Gaisrų” gesinimas - skubių problemų sprendimas
■ Ateinančių užklausų vykdymas
○ Projektinė (planinė) veikla
■ CI architektūros tobulinimo strategija (roadmap)
■ CI sekų (pipelines) ir aplinkų kūrimas ir palaikymas
● Programuotojų komandos
○ Fokusuojasi į produkto kūrimą ir testavimą
○ Naudojasi DevOps komandos suteiktais įrankiais tam, kad vykdyti savo
komponentų versijų automatizuotą testavimą bei paleidimus

30. Išmoktos pamokos

31. Ar verta skaidyti mano projekta?
TAIP*
○ Jeigu prie PĮ kodo dirba daugiau nei 1
komanda
○ Jeigu visos sistemos paleidimas
(surinkimas) užtrunka nepriimtinai* ilgai
○ Jeigu kodo bazė GALI būti išskaidyta į
mažesnius, paprastesnius projektus
https://miro.medium.com/max/638/1*Pb2RvaEZl__ReSO6ydzLGg.jpeg

32. Paleidimas laiku
Noras “sukišti” į naują versija per daug naujo
funkcionalumo dažnai nulemia paleidimo datos atidejimą:
● Realistiškas darbų planavimas: darbų apimtis <=
turimi resursai
● Numatyti laiką stabilizavimui: testavimas, klaidų
taisymas, pažeidžiamumų analizė ir pašalinimas
● Sprinto padalinimas į fazes: implementavimas,
stabilizavimas, paleidimas

33. DevOps - atskira organizacija
● Sutelkti DevOps specialistus į atskirą komandą, nebent kol vyksta esminiai
CICD pertvarkymai ir eksperimentai
○ Tai gali būti amžinas procesas

34. Niekas nemėgsta CICD/DevOps
● Nes CICD priemonės irgi lūžinėja
○ Visur dirba žmonės
● Nes būna visos CICD architektūros klaidų
○ Jau nuėjome CI 1.0 → CI 2.0 ir tai dar ne pabaiga
● Nes CICD uždeda procesinių ir technologinių apribojimų,
reikalauja griežto proceso laikymosi
○ Kai kurie net prisimena Agile Manifestą: “Processes and tools over
Individuals and interactions”
● Nes CICD demaskuoja daugybę esamų problemų
(bet nesprendžia jų, o reikalauja spręsti)
○ Architektūros (pvz. per daug compile time dependencies, per daug
monolitiniai komponentai)
○ Kokybės (negali padaryti release-o su bug-ais)
○ Organizacijos (neoptimalus darbo sričių ir komandų pasidalinimas,
nesusišnekėjimas, kontrolės stoka…)
● Nes tai tiesiog papildomi kaštai, komandos, planai,
planavimas, reglamentavimas, palaikymas …..

35. Patarimai LR viešajam sektoriui

36. Kokius prioritetus kelti?
● Informacinių sistemų (IS) vystymas iteraciniu-inkrementiniu būdu
● Tarpinių IS versijų diegimas testavimo aplinkoje kiekvienos iteracijos metu,
apimant pakeitimus bei esamus IS modulius
● Pilnas tarpinių IS versijų testavimas kiekvienos iteracijos metu, apimant
pakeitimus bei esamus IS modulius
● Operatyvaus gamybinės IS versijos palaikymo (trūkumų taisymą, pilną
testavimą bei atnaujinimų diegimą) esamo funkcionalumo apimtyje,
lygiagrečiai vystant ir testuojant naują IS funkcionalumą, užtikrinimas
● Kuo didesnis testavimo ir diegimo veiklų automatizavimas

37. Ko reikalauti iš IS vystytojų? (1)
● Programinio kodo saugojimo Užsakovo turimoje arba Užsakovui prieinamoje saugykloje (angl.
source control), palaikančioje
○ programinio kodo versijavimą
○ programinio kodo šakas (angl. branch)
○ Programinio kodo įkėlimo (angl. merge) žurnalizavimą
● Programinio kodo šakų (angl. branches) valdymo, užtikrinant programinio kodo atskyrimą į versijas:
○ Palaikoma versija (-os)
○ Pagrindinė vystoma versija
○ Bandomasias versijas
● Programinio kodo resursų (bibliotekų, gairių, standartinių, atviro kodo arba 3-ųjų šalių komponentų)
bei jų versijų
○ tvirtinimo pagal Užsakovo nustatytą tvarką
○ inventoriaus dokumentavimo ir nuolatinio dokumento atnaujinimo
○ naudojamų artefaktų rinkinio saugojimo prie atitinkamų programinio kodo šakų (versijų)
● Atbulinio suderinamumo (angl. backward compatibility) tvarkos dokumentavimo ir laikymosi, vystant
integracines sąsajas ir el. paslaugas
● Automatizuoto testavimo tvarkos ir priemonių dokumentavimo
● Automatizuoto testavimo funkcinių scenarijų vystymo, užtikrinant tam tikrą padengimo procentą

38. Ko reikalauti iš IS vystytojų? (2)
● Programinio kodo ir resursų surinkimo (angl. build) automatizavimo, nurodant
norimą šaką bei surenkamą versiją, sukuriant diegimui paruoštus failus ar
konteinerius
● Surinktos versijos testavimo automatizavimas, apimant
○ Paviršinį/prioritetinį funkcinių scenarijų testavimą (angl. smoke tests)
○ Pilną funkcinių scenarijų veikimo testavimą (angl. regression)
○ Saugos spragų (angl. vulnerabilities) testavimą
○ Integracinių sąsajų ir protokolų atbulinio suderinamumo (angl. backward compatibility) testavimą
● Diegimo architektūros bei diegimo automatizavimo tvarkos ir priemonių
dokumentavimo visoms aplinkoms (testavimo, gamybinei…)
● Diegimo automatizavimo sekų (angl. pipelines) vystymas pagal informacinės
sistemos modulių ir diegimo elementų architektūrą
● Surinktos versijos diegimo testavimo aplinkoje automatizavimo, apimant surinkimo ir
testavimo automatizavimą
● Surinktos versijos diegimo gamybinėje aplinkoje automatizavimo

39. Kokių įrankių (ar lygiaverčių) reikalauti?

40. Ką ir kada planuoti?
Agile projekto gyvavimo ciklas ir etapai pagal
1. Testavimo [ir gamybinių] aplinkų
infrastruktūros planas
2. CI[CD] priemonių ir “vamzdyno” planas
3. CI[CD] ciklų tvarkaraštis, procesas
4. Testavimo automatizacijos priemonių
planas ir strategija (įsk. saugumo skylių
skenavimą)
5. Personalo apmokymas [jei reikia]
6. Testavimo aplinkų diegimas
7. CI[CD] priemonių diegimas
8. Bandomieji CI[CD] “vamzdynai”
9. Bandomieji auto-testai
10. Personalo apmokymas [jei reikia]
14. Automatizuotas diegimas į testavimo
aplinką (CI)
15. Iteracijos priėmimo testavimas
16. Automatizuotas diegimas į gamybinę
aplinką (CD)
17. Bandomoji/gamybinė eksploatacija
11. CI[CD] “vamzdynų” programavimas
12. Auto- testų programavimas
13. Kasdieniai surinkimai ir auto-testų
pritaikymai
18. Valgyk. Miegok. Daryk CICD.
Kartok

41. Su kuo derinti savo reikalavimus ir galimybes?
Priklauso nuo jūsų IT infrastruktūros ir siekiamo automatizavimo lygio
Infrastruktūra Tiekėjas/tvarkytojas CI
Surinkimas, testavimas, versijų
diegimas testavimo aplinkoje
CICD
versijų diegimas
gamybinėje aplinkoje
Laikina IS vystymo
projekto IT infrastruktūra
IS vystymo tiekėjas X -
Vidinis duomenų centras Vidinis IT padalinys X X
Išorinis duomenų
centras/debesija
Debesijos paslaugų
teikėjas
X X
Konsoliduota Valstybės
debesija
Valstybės IT paslaugų
departamentas ir jo
teikiamos paslaugos
X X

42. Strateginės rekomendacijos
● Įtraukti vieningas CICD priemones ir tvarkas į
○ Valstybės IT konsolidavimas ir valdymo pertvarką
○ Valstybės IT paslaugų departamento teikiamas paslaugas
● Parengti oficialias IVPK metodines rekomendacijas CICD taikymui Valstybės
IS vystymui, modernizavimui, palaikymui
● Papildyti VPT rengiamas rekomendacijas IT pirkimams
○ CICD įgyvendinimo ir eksploatavimo paslaugų pirkimas
○ CICD reikalavimai, El. paslaugos arba IT sprendimo įgyvendinimo, modernizavimo, diegimo ir
priežiūros paslaugų pirkimų apimtyje

43. Ačiū!
Klausimai?