Diegimo etapas prasideda nuo pirmos iteracijos... ir niekada nesibaigia
Agile ir kažkokie tai diegimai
Kaip mes tai darome EIS Engineering
Patarimai LR viešajam sektoriui
Diegimo etapas prasideda nuo pirmos iteracijos... (Agile Lietuva meetup 2021 02)
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/
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
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
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/
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
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 …..
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
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