SlideShare a Scribd company logo
1 of 60
Download to read offline
Diegimas nestabdant sistemos
Technikos ir architektūros
Rolandas Jaskovikas Kaunas JUG 2017-01-18
Agenda
 Įvadas - kam tai reikalinga ir …
 Veikimo pagrindai
 Prototipas ir jo architektūra
 Versijos keitimo technikos
 Architektūros
 Naudingos smulkmenos
 Kartais reikia paleisti iš naujo
Įvadas
Įvadas
 Kam to reikia:
A. Kūrimo ar priežiūros (SLA) sutartyse reikalaujama > 99% up time’o.
B. Norime turėti pilnavertį “Continuous deployment” procesą
C. Norime pakeitimus diegti darbo metu
 Kodėl nedarome:
 Nėra poreikio – dauguma sistemų darbo laikas nuo 08 iki 17 valandos
 Sudėtingesnis programavimas – neatneša naudos
 Reikia patyrusių programuotojų
 Nemokame – dėl aukščiau išvardintų priežasčių praktika nėra paplitusi
Įvadas
 Reikalavimai:
A. Labai pageidaujamas automatizuotas “Continuos deployment” procesas
B. Diegimas mažais funkcionalumo gabaliukais – 15 diegimu per diena norma
C. Du ar daugiau aplikacijų serverių/konteinerių
 Pastebėjimai:
A. Visiškai 100% sistemos nestabdymo pasiekti negalima
B. High availability nėra reikalingas, tačiau kartais HA gauname dovanų
Veikimo pagrindai
Veikimo pagrindai
 Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistuojantys duomenys (būsena)
 Spendimas:
A. Programa išskaidoma į kelis nepriklausomus procesus
Veikimo pagrindai – keli procesai
Veikimo pagrindai
 Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistuojantys duomenys (būsena)
 Spendimas:
A. Programa išskaidoma į kelis nepriklausomus procesus
B. Atliekamas kodo ir būsenos atskyrimas
Veikimo pagrindai – atskirta būsena
Veikimo pagrindai – būsenos nesuderinamos
Veikimo pagrindai
 Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistuojantys duomenys (būsena)
 Spendimas:
A. Programa išskaidoma į kelis nepriklausomus procesus
B. Atliekamas kodo ir būsenos atskyrimas
C. Naudojamas karšto suderinamumo principas (angl: Hot compatibility)
Veikimo pagrindai – karštas suderinamumas
Veikimo pagrindai
 Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistuojantys duomenys (būsena)
 Spendimas:
A. Programa išskaidoma į kelis nepriklausomus procesus
B. Atliekamas kodo ir būsenos atskyrimas
C. Naudojamas karšto suderinamumo principas (angl: Hot compatibility)
 Pastebėjimai:
A. Labai paprasta kuomet nėra būsenos – pakeitimas greitas ir paprastas
B. Laikui bėgant reikia nepamiršti išsivalyti seno kodo
Prototipas
Prototipas
 Tarnybinė stotis:
 Intel Atom x5-Z8300 – 1.84 GHz 4 branduoliai
 2 GB RAM
 32 GB SSD
 Windows 10 Home
 Prisijungimas per Wifi
 SID: ZDD
 PSWD : Zdd4Kjug
 http://zdd/zdd
 http://192.168.0.79/zdd
Prototipas - architektūra
Prototipas
 Naudojama programinė įranga ir biblioketos:
 Java 8
 RedHat Jboss EAP 6.4
 Pound 2.7 reverse proxy
 MySql 5.7
 Java EE 6.0 (EJB 3.0, JSF 2.1, JDBC…)
 Infinispan 5.2
 Jgroups 3.2
 Python 2.7
Prototipas – vartotojo sąsaja
Prototipas – JSF forma, V1
Prototipas – JSF backing bean’as, V1
Prototipas – MessageService, V1
Prototipas – ZddDAO, V1
Versijos keitimo technikos
Būsena
 Programos būseną sudaro:
 Sesija
 Įvairūs kešai (lokalūs ir globalūs)
 Serviso sąsajos versija
 Duomenų bazėse saugoma informacija
 Formos (HTML puslapio) navigacijos būsena
Būsena – navigacijos būsena
Būsena – navigacijos būsena
Būsena – duomenų bazė
 Stulpelio pridėjimas:
 Pridedate stulpelį be jokių apribojimų su default reikšme
 Sutvarkote programos kodą, kad teisingai pildytų naują stulpelį
 Migruojate senuose įrašuose esančias stulpelio reikšmes
 Uždedate reikiamus apribojimus
 Stulpelio pašalinimas
 Sutvarkote programos ir db kodą nenaudoti stulpelio
 Nuimate apribojimus trukdančius stulpelio pašalinimui (indeksai ar kiti apribojimai)
 Pašalinate stulpelį
Būsena – duomenų bazė
 Stulpelio pakeitimas (pavadinimas, duomenų tipas ar kita):
 Pridedate naują stulpelį pagal anksčiau aprašytą procedūrą
 Sutvarkote programos kodą naudoti abu stulpelius
 Ištrinate seną stulpelį pagal anksčiau aprašytą procedūrą
 Duomenų migravimas
 Migravimui reikia naudoti papildomą požymio stulpelį (0-seni, 1-migruoti)
 Migruoti reikia mažomis įrašų porcijomis, kad neužrakinti lentelių
Būsena – duomenų bazė
 Didelių lentelių keitimas:
 Pridedant ar šalinant stulpelį yra rakinama lentelė
 Lentelės rakinimo laikas yra tiesinė funkcija nuo įrašų skaičiaus O(n)
 Labai didelės lentelės keičiamos kuriant naują lentelę ir atliekant lentelių sukeitimą
 Atsargiai su indeksų kūrimu, galimas lentelės rakinimas
 Stored procedūrų/paketų keitimas – prieš naudojantis JDBC connection objektu
jį reikia testuoti
 NoSQL duomenų bazės turi menamą schemą – todėl galioja visi aukščiau
išvardinti principai
Būsena – prototipo DB migravimas
V1 ->
V2 ->
V1.5 ->
DB migravimo pavyzdys
Prototipas – ZddDAO, V2
Būsena – serviso sąsajos pasikeitimas
 Funkcijos pridėjimas arba pašalinimas
 Technologija/protokolas reikalauja naujos sąsajos versijos:
 Pridėti naują sąsajos versiją
 Sutvarkyti kodą naudoti naują sąsajos versiją
 Išmesti seną sąsajos versiją
 Technologija/protokolas nereikalauja naujos sąsajos versijos:
 Pridėti naujas funkcijas
 Sutvarkyti kodą naudoti naujas funkcijas ir nenaudoti senų
 Išmesti senas funkcijas
 Pastebėjimas:
 Servisai turi neturėti būsenos
 Servisų keitimas yra vienas paprasčiausių migravimų
Būsena – serviso sąsajos pasikeitimas
 Duomenų migravimas realiu laiku
 Senos funkcijos turi gražinti senus duomenis
 Naujos funkcijos turi gražinti naujus duomenis
Serviso migravimo pavyzdys
Būsena – web serveris
 Sesijos valdymas:
 Iškelti sesiją iš WEB konteinerio atminties – laikyti db išorinimiame, kešo serveryje, …
 Sesijoje turėti papildomą požymį, kuris nurodytų jos versiją
 Migruoti neaktyvias sesijas
 laukti, kol jos “timeout’ins”
 palaikyti migravimo kodą keliomis versijomis atgal
 Momentinis aplikacijos versijos perjungimas, kuomet naudojama ‘Node swap’
architektūra
 Naudoti sinchronizuotą versijos perjungimo mechanizmą
 Galima naudoti “sticky session” mechanizmą “load balanceryje” (nerekomenduoju)
 Formų/puslapių, paveikslėlių ir kito turinio versijavimas.
Prototipas – JSF forma, V2
Prototipas – Backing bean’sas, V2
Prototipas – MessageService, V2
WEB migravimo pavyzdys
Seno kodo valymas
 Reikia nepamiršti išvalyti seno kodo:
 Priklausomai nuo aplikacijos galimas kelių versijų senumo kodo laikymas
 Rekomenduojama turėti automatinius senų kodo versijų valymo įrankius
Prototipas – JSF forma, V3
Prototipas – JSF backing bean’as, V3
Prototipas – MessageService, V3
Prototipas – ZddDAO, V3
Išvalyto kodo diegimo pavyzdys
Architektūros
BlueGreen deployment
*Martin Fowler [https://martinfowler.com/bliki/BlueGreenDeployment.html]
Node swap
Canary deployment
Tomcat parallel deployment
Architektūrų privalumai ir trūkumai
 BlueGreen
 Privalumai:
 Galimas lygiagretus visų stočių diegimas – didelis greitis
 Versija persijungia visoms mašinoms iškarto – nereikalingas papildomas sinchronizavimas
 Trūkumai
 Reikalauja dvigubo resursų turėjimo – įsivaizduokite 500 mašinų klasterį 
 Naudojama skirtingos duomenų bazės – reikalingas duomenų sinchronizavimas
 High availability reikia rūpintis atskirai
Architektūrų privalumai ir trūkumai
 NodeSwap
 Privalumai:
 Perdiegimui reikia tik vienos mašinos
 Naudojama ta pati duomenų bazė – nereikalingas sudėtingas duomenų sinchronizavimas
 High availability gaunama, kaip dovana
 Trūkumai:
 Negalimas lygiagretus visu stočių diegimas – lėtas perdiegimas
 Reikalingas papildomas mechanizmas versijos perdiegimui
Architektūrų privalumai ir trūkumai
 Canary deployment
 Tai tarpinis variantas tarp BlueGreen ir NodeSwap architektūrų – kuri architektūra
dominuos – tuos privalumus ir trūkumus turėsite.
 Papildomas privalumas – galima ištestuoti naują versiją su pasirinktais naudotojais
 Tomcat parallel deployment
 Privalumai:
 Užtenka vienos aplikacijos
 Trūkumai:
 Nėra high availability
 Senos versijos gyvavimas gali užtrukti ilgai – kol atsijungs paskutinis vartotojas.
Naudingos smulkmenos
Naudingos smulkmenos
 Didelių pakeitimų darymas:
 Suskaidykite į mažus nepriklausomus pakeitimus
 Darykite didelį pakeitimą, kaip atskirą nepriklausomą savybę (feature), kuri
diegiama pastoviai, o bus pasiekiama tik ją pilnai įgyvendinus
 Versijos keitimas nestabdant pilna apimtimi yra sudėtingas, tačiau atvejis
nesikeičiant būsenai (duomenims) yra paprastas, todėl jį verta naudoti
 Pakeitimų atstatymas (angl: rollback):
 Jeigu nebuvo duomenų migravimo – galima tiesiog sugrįžti prie senos versijos
 Jeigu buvo duomenų migravimas – grįžimas galimas tik migruojant duomenis į seną
versiją.
Naudingos smulkmenos
 Web tarnybinės stoties išėmimas iš “reverse proxy”:
 Keičiant “reverse proxy” konfigūraciją
 Dažnas “reverse proxy” turi “life detection” mechanizmą
 “Reverse proxy” vienam TCP prisijungimui naudoja 2 socket’us –
susiskaičiuokite poreikį, nes OS palaiko ribotą socket’ų skaičių.
 Galima nesunkiai atlikti testavimą gamyboje, testuojant jau sudiegtą, bet
neprijungtą prie “reverse proxy” web tarnybinę stotį.
Pakeitimai kuriems būtinas stabdymas
 Duomenų bazės serverio versijos keitimas
 Dideli aplikacijos arba duomenų bazės schemos pakeitimai
 Didelio duomenų kiekio lentelių keitimas arba indeksų kūrimas
 Aplikacijos ar jos pagrindinių elementų topologijos ar architektūros keitimas
 Kešo serverių topologijos keitimas
 DB replikavimo mechanizmo keitimas
Klausimai

More Related Content

Similar to Zero downtime deployment

Algirdas Noreika WEB konferencija
Algirdas Noreika WEB konferencijaAlgirdas Noreika WEB konferencija
Algirdas Noreika WEB konferencijaDarius Leskauskas
 
Continuous Integration in .NET Projects (LT)
Continuous Integration in .NET Projects (LT)Continuous Integration in .NET Projects (LT)
Continuous Integration in .NET Projects (LT)Paulius Mačiulis
 
M.Klasavičius - Kelias diegiant monitoringo sistemą - nuo 0 iki verslo metrikų
M.Klasavičius - Kelias diegiant monitoringo sistemą - nuo 0 iki verslo metrikųM.Klasavičius - Kelias diegiant monitoringo sistemą - nuo 0 iki verslo metrikų
M.Klasavičius - Kelias diegiant monitoringo sistemą - nuo 0 iki verslo metrikųAgile Lietuva
 
SOLIDWORKS - Išspausk maksimumą 2017 - Dideli surinkimai II dalis
SOLIDWORKS - Išspausk maksimumą 2017 - Dideli surinkimai II dalisSOLIDWORKS - Išspausk maksimumą 2017 - Dideli surinkimai II dalis
SOLIDWORKS - Išspausk maksimumą 2017 - Dideli surinkimai II dalisJustas Nekrasas
 
Grafikų rengyklė 2.0 vizija
Grafikų rengyklė 2.0 vizijaGrafikų rengyklė 2.0 vizija
Grafikų rengyklė 2.0 vizijaguest2ab2d60
 
Windows group policy_editor
Windows group policy_editorWindows group policy_editor
Windows group policy_editorDonatas Bukelis
 
Naudokite versijų kontrolės sistemas
Naudokite versijų kontrolės sistemasNaudokite versijų kontrolės sistemas
Naudokite versijų kontrolės sistemasBarCamp Lithuania
 
Armantas OSTREIKA, Andrius LAURAITIS. HTML dokumentų turinio palyginimo algor...
Armantas OSTREIKA, Andrius LAURAITIS. HTML dokumentų turinio palyginimo algor...Armantas OSTREIKA, Andrius LAURAITIS. HTML dokumentų turinio palyginimo algor...
Armantas OSTREIKA, Andrius LAURAITIS. HTML dokumentų turinio palyginimo algor...Lietuvos kompiuterininkų sąjunga
 
Blue Bridge: System Center diegimų patirtis
Blue Bridge: System Center diegimų patirtisBlue Bridge: System Center diegimų patirtis
Blue Bridge: System Center diegimų patirtisBlueBridgeGroup_LT
 
Paskaita nr1 savokos_topologija
Paskaita nr1 savokos_topologijaPaskaita nr1 savokos_topologija
Paskaita nr1 savokos_topologijaDonatas Bukelis
 
Qlik Sense architektūros apžvalga
Qlik Sense architektūros apžvalgaQlik Sense architektūros apžvalga
Qlik Sense architektūros apžvalgaDay Q
 
Andrej Slivko "CQRS praktikoje"
Andrej Slivko "CQRS praktikoje"Andrej Slivko "CQRS praktikoje"
Andrej Slivko "CQRS praktikoje".NET Crowd
 
Roko šveikausko skaidrių darbas
Roko šveikausko skaidrių darbasRoko šveikausko skaidrių darbas
Roko šveikausko skaidrių darbasFPSRocketeer
 
P. Litvinas. Geoserver visiems. GIS - paprasta ir atvira 2014.
P. Litvinas. Geoserver visiems. GIS - paprasta ir atvira 2014.P. Litvinas. Geoserver visiems. GIS - paprasta ir atvira 2014.
P. Litvinas. Geoserver visiems. GIS - paprasta ir atvira 2014.opengislt
 
Procesu Ir Informacijos Valdymas Su Open ERP
Procesu Ir Informacijos Valdymas Su Open ERPProcesu Ir Informacijos Valdymas Su Open ERP
Procesu Ir Informacijos Valdymas Su Open ERPRita Petružytė
 

Similar to Zero downtime deployment (20)

Algirdas Noreika WEB konferencija
Algirdas Noreika WEB konferencijaAlgirdas Noreika WEB konferencija
Algirdas Noreika WEB konferencija
 
Continuous Integration in .NET Projects (LT)
Continuous Integration in .NET Projects (LT)Continuous Integration in .NET Projects (LT)
Continuous Integration in .NET Projects (LT)
 
M.Klasavičius - Kelias diegiant monitoringo sistemą - nuo 0 iki verslo metrikų
M.Klasavičius - Kelias diegiant monitoringo sistemą - nuo 0 iki verslo metrikųM.Klasavičius - Kelias diegiant monitoringo sistemą - nuo 0 iki verslo metrikų
M.Klasavičius - Kelias diegiant monitoringo sistemą - nuo 0 iki verslo metrikų
 
SOLIDWORKS - Išspausk maksimumą 2017 - Dideli surinkimai II dalis
SOLIDWORKS - Išspausk maksimumą 2017 - Dideli surinkimai II dalisSOLIDWORKS - Išspausk maksimumą 2017 - Dideli surinkimai II dalis
SOLIDWORKS - Išspausk maksimumą 2017 - Dideli surinkimai II dalis
 
Gamybos srauto analitika
Gamybos srauto analitikaGamybos srauto analitika
Gamybos srauto analitika
 
Grafikų rengyklė 2.0 vizija
Grafikų rengyklė 2.0 vizijaGrafikų rengyklė 2.0 vizija
Grafikų rengyklė 2.0 vizija
 
Wordpress pagrindai
Wordpress pagrindaiWordpress pagrindai
Wordpress pagrindai
 
Windows group policy_editor
Windows group policy_editorWindows group policy_editor
Windows group policy_editor
 
PI_12paskaita
PI_12paskaitaPI_12paskaita
PI_12paskaita
 
Naudokite versijų kontrolės sistemas
Naudokite versijų kontrolės sistemasNaudokite versijų kontrolės sistemas
Naudokite versijų kontrolės sistemas
 
Asp_4_Presentation
Asp_4_PresentationAsp_4_Presentation
Asp_4_Presentation
 
Armantas OSTREIKA, Andrius LAURAITIS. HTML dokumentų turinio palyginimo algor...
Armantas OSTREIKA, Andrius LAURAITIS. HTML dokumentų turinio palyginimo algor...Armantas OSTREIKA, Andrius LAURAITIS. HTML dokumentų turinio palyginimo algor...
Armantas OSTREIKA, Andrius LAURAITIS. HTML dokumentų turinio palyginimo algor...
 
Blue Bridge: System Center diegimų patirtis
Blue Bridge: System Center diegimų patirtisBlue Bridge: System Center diegimų patirtis
Blue Bridge: System Center diegimų patirtis
 
Paskaita nr1 savokos_topologija
Paskaita nr1 savokos_topologijaPaskaita nr1 savokos_topologija
Paskaita nr1 savokos_topologija
 
Qlik Sense architektūros apžvalga
Qlik Sense architektūros apžvalgaQlik Sense architektūros apžvalga
Qlik Sense architektūros apžvalga
 
Andrej Slivko "CQRS praktikoje"
Andrej Slivko "CQRS praktikoje"Andrej Slivko "CQRS praktikoje"
Andrej Slivko "CQRS praktikoje"
 
IT Karjeros Receptai
IT Karjeros ReceptaiIT Karjeros Receptai
IT Karjeros Receptai
 
Roko šveikausko skaidrių darbas
Roko šveikausko skaidrių darbasRoko šveikausko skaidrių darbas
Roko šveikausko skaidrių darbas
 
P. Litvinas. Geoserver visiems. GIS - paprasta ir atvira 2014.
P. Litvinas. Geoserver visiems. GIS - paprasta ir atvira 2014.P. Litvinas. Geoserver visiems. GIS - paprasta ir atvira 2014.
P. Litvinas. Geoserver visiems. GIS - paprasta ir atvira 2014.
 
Procesu Ir Informacijos Valdymas Su Open ERP
Procesu Ir Informacijos Valdymas Su Open ERPProcesu Ir Informacijos Valdymas Su Open ERP
Procesu Ir Informacijos Valdymas Su Open ERP
 

Zero downtime deployment

  • 1. Diegimas nestabdant sistemos Technikos ir architektūros Rolandas Jaskovikas Kaunas JUG 2017-01-18
  • 2. Agenda  Įvadas - kam tai reikalinga ir …  Veikimo pagrindai  Prototipas ir jo architektūra  Versijos keitimo technikos  Architektūros  Naudingos smulkmenos  Kartais reikia paleisti iš naujo
  • 4. Įvadas  Kam to reikia: A. Kūrimo ar priežiūros (SLA) sutartyse reikalaujama > 99% up time’o. B. Norime turėti pilnavertį “Continuous deployment” procesą C. Norime pakeitimus diegti darbo metu  Kodėl nedarome:  Nėra poreikio – dauguma sistemų darbo laikas nuo 08 iki 17 valandos  Sudėtingesnis programavimas – neatneša naudos  Reikia patyrusių programuotojų  Nemokame – dėl aukščiau išvardintų priežasčių praktika nėra paplitusi
  • 5. Įvadas  Reikalavimai: A. Labai pageidaujamas automatizuotas “Continuos deployment” procesas B. Diegimas mažais funkcionalumo gabaliukais – 15 diegimu per diena norma C. Du ar daugiau aplikacijų serverių/konteinerių  Pastebėjimai: A. Visiškai 100% sistemos nestabdymo pasiekti negalima B. High availability nėra reikalingas, tačiau kartais HA gauname dovanų
  • 7. Veikimo pagrindai  Kas trukdo realiu laiku pakeisti esamą programą į naują: A. Veikiantis procesas (kodas) B. Jau egzistuojantys duomenys (būsena)  Spendimas: A. Programa išskaidoma į kelis nepriklausomus procesus
  • 8. Veikimo pagrindai – keli procesai
  • 9. Veikimo pagrindai  Kas trukdo realiu laiku pakeisti esamą programą į naują: A. Veikiantis procesas (kodas) B. Jau egzistuojantys duomenys (būsena)  Spendimas: A. Programa išskaidoma į kelis nepriklausomus procesus B. Atliekamas kodo ir būsenos atskyrimas
  • 10. Veikimo pagrindai – atskirta būsena
  • 11. Veikimo pagrindai – būsenos nesuderinamos
  • 12. Veikimo pagrindai  Kas trukdo realiu laiku pakeisti esamą programą į naują: A. Veikiantis procesas (kodas) B. Jau egzistuojantys duomenys (būsena)  Spendimas: A. Programa išskaidoma į kelis nepriklausomus procesus B. Atliekamas kodo ir būsenos atskyrimas C. Naudojamas karšto suderinamumo principas (angl: Hot compatibility)
  • 13. Veikimo pagrindai – karštas suderinamumas
  • 14. Veikimo pagrindai  Kas trukdo realiu laiku pakeisti esamą programą į naują: A. Veikiantis procesas (kodas) B. Jau egzistuojantys duomenys (būsena)  Spendimas: A. Programa išskaidoma į kelis nepriklausomus procesus B. Atliekamas kodo ir būsenos atskyrimas C. Naudojamas karšto suderinamumo principas (angl: Hot compatibility)  Pastebėjimai: A. Labai paprasta kuomet nėra būsenos – pakeitimas greitas ir paprastas B. Laikui bėgant reikia nepamiršti išsivalyti seno kodo
  • 16. Prototipas  Tarnybinė stotis:  Intel Atom x5-Z8300 – 1.84 GHz 4 branduoliai  2 GB RAM  32 GB SSD  Windows 10 Home  Prisijungimas per Wifi  SID: ZDD  PSWD : Zdd4Kjug  http://zdd/zdd  http://192.168.0.79/zdd
  • 18. Prototipas  Naudojama programinė įranga ir biblioketos:  Java 8  RedHat Jboss EAP 6.4  Pound 2.7 reverse proxy  MySql 5.7  Java EE 6.0 (EJB 3.0, JSF 2.1, JDBC…)  Infinispan 5.2  Jgroups 3.2  Python 2.7
  • 20. Prototipas – JSF forma, V1
  • 21. Prototipas – JSF backing bean’as, V1
  • 25. Būsena  Programos būseną sudaro:  Sesija  Įvairūs kešai (lokalūs ir globalūs)  Serviso sąsajos versija  Duomenų bazėse saugoma informacija  Formos (HTML puslapio) navigacijos būsena
  • 28. Būsena – duomenų bazė  Stulpelio pridėjimas:  Pridedate stulpelį be jokių apribojimų su default reikšme  Sutvarkote programos kodą, kad teisingai pildytų naują stulpelį  Migruojate senuose įrašuose esančias stulpelio reikšmes  Uždedate reikiamus apribojimus  Stulpelio pašalinimas  Sutvarkote programos ir db kodą nenaudoti stulpelio  Nuimate apribojimus trukdančius stulpelio pašalinimui (indeksai ar kiti apribojimai)  Pašalinate stulpelį
  • 29. Būsena – duomenų bazė  Stulpelio pakeitimas (pavadinimas, duomenų tipas ar kita):  Pridedate naują stulpelį pagal anksčiau aprašytą procedūrą  Sutvarkote programos kodą naudoti abu stulpelius  Ištrinate seną stulpelį pagal anksčiau aprašytą procedūrą  Duomenų migravimas  Migravimui reikia naudoti papildomą požymio stulpelį (0-seni, 1-migruoti)  Migruoti reikia mažomis įrašų porcijomis, kad neužrakinti lentelių
  • 30. Būsena – duomenų bazė  Didelių lentelių keitimas:  Pridedant ar šalinant stulpelį yra rakinama lentelė  Lentelės rakinimo laikas yra tiesinė funkcija nuo įrašų skaičiaus O(n)  Labai didelės lentelės keičiamos kuriant naują lentelę ir atliekant lentelių sukeitimą  Atsargiai su indeksų kūrimu, galimas lentelės rakinimas  Stored procedūrų/paketų keitimas – prieš naudojantis JDBC connection objektu jį reikia testuoti  NoSQL duomenų bazės turi menamą schemą – todėl galioja visi aukščiau išvardinti principai
  • 31. Būsena – prototipo DB migravimas V1 -> V2 -> V1.5 ->
  • 34. Būsena – serviso sąsajos pasikeitimas  Funkcijos pridėjimas arba pašalinimas  Technologija/protokolas reikalauja naujos sąsajos versijos:  Pridėti naują sąsajos versiją  Sutvarkyti kodą naudoti naują sąsajos versiją  Išmesti seną sąsajos versiją  Technologija/protokolas nereikalauja naujos sąsajos versijos:  Pridėti naujas funkcijas  Sutvarkyti kodą naudoti naujas funkcijas ir nenaudoti senų  Išmesti senas funkcijas  Pastebėjimas:  Servisai turi neturėti būsenos  Servisų keitimas yra vienas paprasčiausių migravimų
  • 35. Būsena – serviso sąsajos pasikeitimas  Duomenų migravimas realiu laiku  Senos funkcijos turi gražinti senus duomenis  Naujos funkcijos turi gražinti naujus duomenis
  • 37. Būsena – web serveris  Sesijos valdymas:  Iškelti sesiją iš WEB konteinerio atminties – laikyti db išorinimiame, kešo serveryje, …  Sesijoje turėti papildomą požymį, kuris nurodytų jos versiją  Migruoti neaktyvias sesijas  laukti, kol jos “timeout’ins”  palaikyti migravimo kodą keliomis versijomis atgal  Momentinis aplikacijos versijos perjungimas, kuomet naudojama ‘Node swap’ architektūra  Naudoti sinchronizuotą versijos perjungimo mechanizmą  Galima naudoti “sticky session” mechanizmą “load balanceryje” (nerekomenduoju)  Formų/puslapių, paveikslėlių ir kito turinio versijavimas.
  • 38. Prototipas – JSF forma, V2
  • 39. Prototipas – Backing bean’sas, V2
  • 42. Seno kodo valymas  Reikia nepamiršti išvalyti seno kodo:  Priklausomai nuo aplikacijos galimas kelių versijų senumo kodo laikymas  Rekomenduojama turėti automatinius senų kodo versijų valymo įrankius
  • 43. Prototipas – JSF forma, V3
  • 44. Prototipas – JSF backing bean’as, V3
  • 49. BlueGreen deployment *Martin Fowler [https://martinfowler.com/bliki/BlueGreenDeployment.html]
  • 53. Architektūrų privalumai ir trūkumai  BlueGreen  Privalumai:  Galimas lygiagretus visų stočių diegimas – didelis greitis  Versija persijungia visoms mašinoms iškarto – nereikalingas papildomas sinchronizavimas  Trūkumai  Reikalauja dvigubo resursų turėjimo – įsivaizduokite 500 mašinų klasterį   Naudojama skirtingos duomenų bazės – reikalingas duomenų sinchronizavimas  High availability reikia rūpintis atskirai
  • 54. Architektūrų privalumai ir trūkumai  NodeSwap  Privalumai:  Perdiegimui reikia tik vienos mašinos  Naudojama ta pati duomenų bazė – nereikalingas sudėtingas duomenų sinchronizavimas  High availability gaunama, kaip dovana  Trūkumai:  Negalimas lygiagretus visu stočių diegimas – lėtas perdiegimas  Reikalingas papildomas mechanizmas versijos perdiegimui
  • 55. Architektūrų privalumai ir trūkumai  Canary deployment  Tai tarpinis variantas tarp BlueGreen ir NodeSwap architektūrų – kuri architektūra dominuos – tuos privalumus ir trūkumus turėsite.  Papildomas privalumas – galima ištestuoti naują versiją su pasirinktais naudotojais  Tomcat parallel deployment  Privalumai:  Užtenka vienos aplikacijos  Trūkumai:  Nėra high availability  Senos versijos gyvavimas gali užtrukti ilgai – kol atsijungs paskutinis vartotojas.
  • 57. Naudingos smulkmenos  Didelių pakeitimų darymas:  Suskaidykite į mažus nepriklausomus pakeitimus  Darykite didelį pakeitimą, kaip atskirą nepriklausomą savybę (feature), kuri diegiama pastoviai, o bus pasiekiama tik ją pilnai įgyvendinus  Versijos keitimas nestabdant pilna apimtimi yra sudėtingas, tačiau atvejis nesikeičiant būsenai (duomenims) yra paprastas, todėl jį verta naudoti  Pakeitimų atstatymas (angl: rollback):  Jeigu nebuvo duomenų migravimo – galima tiesiog sugrįžti prie senos versijos  Jeigu buvo duomenų migravimas – grįžimas galimas tik migruojant duomenis į seną versiją.
  • 58. Naudingos smulkmenos  Web tarnybinės stoties išėmimas iš “reverse proxy”:  Keičiant “reverse proxy” konfigūraciją  Dažnas “reverse proxy” turi “life detection” mechanizmą  “Reverse proxy” vienam TCP prisijungimui naudoja 2 socket’us – susiskaičiuokite poreikį, nes OS palaiko ribotą socket’ų skaičių.  Galima nesunkiai atlikti testavimą gamyboje, testuojant jau sudiegtą, bet neprijungtą prie “reverse proxy” web tarnybinę stotį.
  • 59. Pakeitimai kuriems būtinas stabdymas  Duomenų bazės serverio versijos keitimas  Dideli aplikacijos arba duomenų bazės schemos pakeitimai  Didelio duomenų kiekio lentelių keitimas arba indeksų kūrimas  Aplikacijos ar jos pagrindinių elementų topologijos ar architektūros keitimas  Kešo serverių topologijos keitimas  DB replikavimo mechanizmo keitimas