Anzeige

A. Kovaliov ir A. Kublickij. Diegimo etapas prasideda nuo pirmos iteracijos ... ir niekada nesibaigia

Agile Lietuva
22. Feb 2021
Anzeige

Más contenido relacionado

Similar a A. Kovaliov ir A. Kublickij. Diegimo etapas prasideda nuo pirmos iteracijos ... ir niekada nesibaigia(20)

Más de Agile Lietuva(20)

Anzeige

A. Kovaliov ir A. Kublickij. Diegimo etapas prasideda nuo pirmos iteracijos ... ir niekada nesibaigia

  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?
Anzeige