Aine foorumitest, erinevatest vestlustest ja kirjatükkidest on hakanud viimaste aastate jooksul läbi jooksma termin DevOps ja kuidas mainitud seltskond on süüdi kõikides maailma hädades, eriti selles kui vast toodangusse minev tarkvara ei taha sinna üldse minna ja see pole kaugeltki arendaja süü, vaid toosama  müütiline DevOps on asja vussi keeranud ja keeruliseks ajanud ning üldse kõik pahasti teinud. Lisaks ei suuda DevOps tüüp riistvara ja võrgukindlust garanteerida.

Mida rohkem sellel teemal olen lugenud-kuulnud-näinud, seda rohkem on hakanud see mind häirima. Mõistmiseks, miks, peame liikuma natuke ajas tagasi ja eemale ja lahkama kahte asja:

1. Mis on tarkvara elutsükkel?
2. Kuidas saab tarkvara kasutajatele kättesaadavaks, ehk siis toodangusse ja kuidas ta seal kättesaadavana püsib?

Tarkvara elutsükkel on umbes tuhat korda ära kaardistatud, iga järjekordne lõputööd kirjutav projektijuht teeb seda uuesti[1]:

1. Nõuded
2. Planeerimine
3. Arendus
4. Testimine
5. Kasutamine/jooksutamine

Siia lisan ma nüüd juurde, et kasutamine/jooksutamine kaasab endas:

1. Riistvara haldust
2. Võrgutaristute haldust
3. Uute versioonide toodangusse lubamist
4. jne

.. ja sellises järjekorras see ka käib. Iteratiivselt või kose mudelit mööda, vahet pole. Iga tarkvara planeeritakse, ehitatakse valmis ja siis hallatakse. 

Olenevalt ettevõttest/meeskonnast, vastutas erinevate etappide eest konkreetne seltskond, kes siis jagunes väga laias laastus kaheks:

1. Arendajad
2. Administratorid

Esimesed arendasid asja valmis, panid testkeskkonda, organiseerisid testimise/kvaliteedikontrolli. Teine kamp tagas vajaliku taristu: riistvara, seadistatud operatsioonisüsteemid, vajaliku baastarkvara olemasolu taristul. Toodangukeskkonna jaoks oli (tegelikult on ka praegu) olemas administraatorite alamliik peene nimega rakenduse administraatorid, kelle ülesanne oli/on konkreetset rakendust elus hoida.

Toodangusse paneku töörutiin kulges tavaliselt ühelt rollilt teisele tööülesannete ette andmisel (stiilis meie tegime tarkvara valmis, pange teie nüüd üles): Arendajad andsid teada, projektijuht koordineeris, administraatorid tegid. Toimis. Niivõrd-kuivõrd.

Viimasel ajal on keskastme juhtide avaldustesse tekkinud laused stiilis Me peame omale DevOps inimese palkama, kes tegeleks toodangusse panemisega ja pipelinede haldusega.

Mida rohkem ma taolist kuulen, seda nukramaks ma muutun. DevOps ei ole amet. DevOps ei ole roll. DevOps ei ole osakond.

DevOps ei ole Github Actions/Bitbucket pipelines jne.

DevOps on maailmavaade, mille võib kokku võtta ühe lausega: iga seltskond vastutab saba ja sarvedega selle eest, et tema loodud tarkvara saaks valmis kirjutatud, toodangusse pandud ja seisaks seal üleval[2].

Mida see praktikas tähendab? Seda, et igas meeskonnas võiks olla vähemalt üks inimene, kes on ennast kurssi viinud kasutatava taristuga, opsüsteemidega, mustritega kuidas tarkvara saab arendusest toodangusse. Ühes töökohas oli selle rolli nimi väga lakooniline Toodangu eest vastutaja. Ei tehtaks enam osakondade/meeskondadevahelisi ülesandepüstitusi ülaltoodud stiilis. Tarkvara tootnud meeskond paneb selle ka toodangusse ja haldab.

DevOps ei tähenda seda, et me juurutame endale Bamboo või Jenkinsi ja siis üks õnnetuke kusagil osakonnas X rabeleb pipeline'sid teha ja saab kolki iga jumala kord kui ei tööta. Bamboo, Jenkins ja sõbrad on lihtsalt töö lihtsamaks ja kiiremaks tegemise vahendid.

DevOps on võimalik ka kasutades vaid SSH'd ja käsurida. DevOps ei määra, millega me asju teeme, vaid kuidas me asju teeme ja kes mille eest vastutab:

1. Adminid vastutavad selle eest, et baastaristu töötaks:
1. Riistvara
2. Võrk
3. Operatsioonisüsteemid
4. Abivahendid (a la Kubernetes, CI/CD töövahendid)
2. Rakenduste eest vastutavad DevOps mentaliteeti jälgivad meeskonnad (täiesti meelega väldin sõna 'tiim'. See on ääretult kole värdlaen):
1. Abivahenditel toimivad protsessid (nö. pipelined)
2. Rakenduste logimine ja monitoorimine
1. Hädade korral neile reageerimine
3. Muu, mis kaasneb tarkvara saadavuse tagamisega

Vot selline arvamus. Puhtalt isiklik. Mõningatel kogemustel põhinev.

[1] https://www.sciencedirect.com/topics/computer-science/software-lifecycle#

[2] https://aws.amazon.com/devops/what-is-devops/