Prezsentation at DevClub.lv about software delivery process automatization.
In talk I summarize our company experience about delivery automation process.
2. Oracle pieredze > 10
gadi.
Oracle, .NET, Ruby,
Java
1 – 20+ cilvēki
projektā
Dažādas piegāžu
automatizācijas
pakāpes
3. Dibināta: 04.06.2014
apvienojoties SIA Special
Solutions, SIA eBIT unSIA Open
ID
Darbinieki: ~100
Tehnoloģijas: Oracle
PL/SQL, Java, Ruby,
Microsoft .NET, ĢIS
4. Jautājumi par automatizāciju
Vai izmanto automatizāciju?
Kādus rīkus izmanto (Jenkins/Bamboo/cits)
Vai esi pārliecināts par to, ka piegādes
sagatavošana/uzstādīšana ies pēc plāna?
– Ļoti pārliecināts
– 50/50
– Neesmu pārliecināts
10. Rezultātu paziņošana
Būvējumu rezultāti RSS/E-pastā vai reālā laika
paziņojumi.
Build Notifiers – vairāk kā 50 spraudņi
– Skype
– Google calendar
– IRC
– Sladiator
17. Izmaiņu izstrāde – manuāli
Rakstīt pārbaudes vai tabula izveidota/kolonna
pievienota u.t.t.
Manuāla formu un citu objektu nogāde uz
aplikāciju serveri.
18. Izmaiņu izstrāde/sagatavošana
commit-am - automatizēšana
Atkārtoti darbināmi skripti:
– Pārbaude par iespēju veikt darbību
– Skriptu reģistrs, lai nemēģina izpildīt otru reizi
Gatavi paraugi dažādām darbībām (CREATE
TABLE/ALTER TABLE/CREATE INDEX, u.t.t.)
Automatizācijas iespējas:
– Konvertācija no ruby migrācijām
– DB struktūras salīdzināšana ar VCS
– Formu un citu objektu nogāde uz aplikāciju
serveri – lokāli darbināms “piegādes savākšanas”
skripts
19. Commit testa DB / Vienībtestu
automātiska darbināšana
Pēc commit automātiska DB izmaiņu uzlikšana
testa DB
– Pārbauda vai skripti darbosies
– Sagatavo vidi vienībtestiem
Vienībtestu automātiska darbināšana
21. Izmaiņu nogādāšana
testēšanai - manuāli
Izmainīto failu savākšana ar rokām, piemēram,
pēc SVN log.
Izmainīto aplikāciju servera failu kopēšana uz
serveri.
DB piegādes uzstādīšanas kopējais SQL skripts.
Pieteikumu statusu maiņa (bulk edit)
22. Izmaiņu
savākšana/sagatavošana
Java/.NET – Maven, Ant, MSBuild
Oracle Forms/Reports, DB (ja nepiegādā ar app
migrācijām) – savāc izmaiņas no repozitorija
– Instalācijas secība
• Stingri definēta starp dažāda veida objektiem (Tabulas ->
Indeksi -> Skati -> … -> Procedūras -> … -> Dati -> … ->
Oracle Forms -> …
• Commit secībā
• Objekta ietvaros alfabētiski
23. Izmaiņu uzstādīšana
Java – uzkopē war/ear/jar
.NET – web deploy/copy
Ruby – Capistrano
Oracle Forms/Reports, DB (ja nepiegādā ar app
migrācijām)
– “master” skripts, kurā definētas darbības
dažāda veida objektu uzstādīšanai
– ģenerēts skripts ar visām uzstādāmajām
izmaiņām.
26. Piegādes pakas
sagatavošana
Piegādes failu savākšana
Arhīva izveidošana
Arhīva kopēšana uz serveri
Piegādes dokumentācijas “dzejošana”
Izmaiņas pieteikumu sistēmā
(statusi/versijas/komentāri)
27. Nogādāšana līdz klientam
SFTP
Repozitorijs commit -> push -> instalē pēc tag
Direct build (ja ir piekļuve klienta vidēm)
Caur e-pastu, caur JIRA
Slikti: Repozitorijā iekommitots sakompilēts
binārais fails
Slikti: Klients pats build-o – var nesakrist
darbstacijas konfigurācijas, pastāv iespēja, ka
pielabos kodu.
28. Pakas informācija
Informācija par piegādi
– Ar roku rakstīts -> E-pasts no template ->
Automātiski aizpildīts template ->
Nosūtīts/pārsūtīts gatavais e-pasts
Statusu maiņa/komentāri pie pieteikuma
Piegādes dokumentācija
– Eksports no pieteikumu sistēmas
– Ģenerēts
• Caur JIRA API
• Markdown (teksts -> PDF)
29. Pakas uzstādīšana
Maksimāli automatizēts, bet ar monitorēšanas
un reaģēšanas iespēju.
– NOATTEND_INSTALL, NOATTEND_LEVEL
• There was a warning during installation. Press
enter to continue
• There was an error during installation. Do you wish
to continue [y|n]
Rollback uz iepriekšējo versiju
Atgriezeniskā saite par versijas uzlikšanu
– Master -> Test -> Prod
35. Automatizēšana - Legacy
projekti
Necenties automatizēt bardaku – var būt ilgi un
neoptimāli.
Jāmaina domāšana pašiem/klientam.
Automatizēšana ir laikietilpīga.
Automatizācija kā apakšprojekts.
Nevajag uzreiz 100% - galvenais sākumā karkass,
uz kura būvēt. Kļūdu novēršana var būt laikietilpīga.
Kļūdas piegādes savākšanā var izraisīt problēmas
sistēmā.
Atkārtojami instalējami skripti.
Never ending story – vienmēr ir vieta uzlabojumiem.
36. Automatizēšana - Jauni projekti
Jau uzsākot izmantot arhitektūru, kas atvieglo
piegāžu automatizēšanu
Pēc iespējas, dalīt neatkarīgi piegādājamos
moduļos - high cohesion, low coupling
Kas ir jādara, lai izmaiņu piegāde nebūtu galvassāpes.
Pēdējos 2-3 gadus pastiprināti interese par piegāžu automatizācijas procesu
Dažādi klienti, gan privātajā gan valsts sektorā, gan Latvijā, gan ārzemēs
LMT, Lattelecom, Latvenergo, Baltcom, LAD (Lauku atbalsta dienests), MSC (Mediterian shipping company), Nordea
Mkods, e-paraksts
Visu iepriekš minēto var darbināt ar roku, bet:
Ja nav bieži jādara, tad var aizmirsties kas un kādā secībā jādara
Ja bieži jādara, tad “apnīk” visu laiku laist vienu skriptu pēc otra + potenciāli ilgs gaidīšanas laiks
By default installation will ask about every error encountered.
By default noattend installation error level is E - terminate on errors.
Supported NOATTEND_LEVEL values: A - continue always, E - terminate on errors, W - terminate on errors and warnings.
Lai atvieglotu piegāžu statusa meklēšanu tika ieviests build pipeline (https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin)
Sagatavo piegādi, atzīmē piegādes uzlikšanas faktu akcepttesta/produkcijas vidēs.