Varustasime kunagi ühes ettevõttes kliendile elektroonilise dokumendihaldussüsteemi. Ja siis teisele objektile. Ja veel üks. Ja neljandal ja viiendal. Me läksime nii hinge, et jõudsime 10 jagatud objektini. See osutus võimsaks... eriti kui jõudsime muudatuste elluviimiseni. Tootmisahelasse tarnimise osana nõudsid testimissüsteemi 5 stsenaariumi lõpuks 10 tundi ja 6–7 töötajat. Sellised kulud sundisid meid tarneid tegema nii harva kui võimalik. Pärast kolme aastat tegutsemist ei suutnud me seda taluda ja otsustasime projekti näputäie DevOpsiga vürtsitada.
Nüüd toimub kogu testimine 3 tunni jooksul ning selles osaleb 3 inimest: insener ja kaks testijat. Täiustused on selgelt väljendatud numbrites ja viivad väga armastatud TTM-i vähenemiseni. Meie kogemuse kohaselt on palju rohkem kliente, kes saavad DevOpsist kasu, kui neid, kes sellest isegi teavad. Seetõttu oleme DevOpsi inimestele lähemale toomiseks välja töötanud lihtsa konstruktori, millest selles postituses lähemalt räägime.
Nüüd räägime teile üksikasjalikumalt. Üks energiaettevõte võtab 10 suurel objektil kasutusele tehnilise dokumendihaldussüsteemi. Ilma DevOpsita pole sellises mahus projektides lihtne navigeerida, sest suur osa käsitsitööst lükkab tööd oluliselt edasi ja vähendab ka kvaliteeti – kogu käsitsitöö on täis vigu. Teisest küljest on projekte, kus on ainult üks paigaldus, kuid kõik peab töötama automaatselt, pidevalt ja tõrgeteta - näiteks samad dokumendivoo süsteemid suurtes monoliitsetes organisatsioonides. Vastasel juhul teeb keegi seaded käsitsi, unustab juurutamisjuhised - ja selle tulemusena lähevad tootmises seaded kaotsi ja kõik variseb kokku.
Tavaliselt töötame kliendiga lepingu alusel ja sel juhul lähevad meie huvid veidi lahku. Klient vaatab projekti rangelt eelarve ja tehniliste näitajate piires. Talle võib olla keeruline selgitada erinevate DevOpsi praktikate eeliseid, mis ei sisaldu tehnilistes kirjeldustes. Mis siis, kui ta on huvitatud ärilise lisaväärtusega kiirväljaannetest või automatiseerimistorustiku ehitamisest?
Paraku ei leita seda huvi alati eelnevalt kinnitatud kuluga töötades. Meie praktikas oli juhtum, kui pidime võtma üles hoolimatu ja hoolimatu töövõtja arenduse. See oli kohutav: puudusid ajakohased lähtekoodid, sama süsteemi koodibaas oli erinevatel installatsioonidel erinev, dokumentatsioon osaliselt puudus ja osaliselt kohutava kvaliteediga. Loomulikult ei olnud kliendil kontrolli lähtekoodi, komplekteerimise, väljalaske jms üle.
Siiani ei tea kõik DevOpsist, kuid niipea, kui räägime selle eelistest, reaalsest ressursi kokkuhoiust, lähevad kõikide klientide silmad särama. Seega kasvab DevOpsi sisaldavate päringute arv aja jooksul. Selleks, et klientidega hõlpsalt ühes keeles rääkida, peame kiiresti ühendama äriprobleemid ja DevOpsi tavad, mis aitavad luua sobiva arendustoru.
Niisiis, ühelt poolt on meil rida probleeme, teiselt poolt on meil DevOpsi teadmised, tavad ja tööriistad. Miks mitte jagada kogemust kõigiga?
DevOpsi konstruktori loomine
Agile’il on oma manifest. ITIL-il on oma metoodika. DevOpsil on vähem vedanud – see pole veel malle ja standardeid omandanud. Kuigi määrata kindlaks ettevõtete küpsus, lähtudes hinnangust nende arengule ja tegevustavadele.
Õnneks on tuntud firma Gartner 2014.a ning analüüsis peamisi DevOpsi tavasid ja nendevahelisi seoseid. Selle põhjal avaldasin infograafika:
Võtsime selle aluseks oma . Igal neljal valdkonnal on tööriistakomplekt – kogusime need andmebaasi, tuvastasime populaarsemad, tuvastasime integratsioonipunktid ja sobivad optimeerimismehhanismid. Kokkuvõttes selgus 36 praktikat ja 115 tööriista, millest veerand on avatud lähtekoodiga või tasuta tarkvara. Järgnevalt räägime sellest, mida oleme igas valdkonnas saavutanud ja näitena sellest, kuidas see teostus tehnilise dokumendihalduse loomise projektis, millega postitust alustasime.
Protsessid
Kurikuulsas EDMS-i projektis kasutati tehniliste dokumentide haldussüsteemi sama skeemi järgi kõigil 10 objektil. Installimine sisaldab 4 serverit: andmebaasiserver, rakendusserver, täisteksti indekseerimine ja sisuhaldus. Installatsioonis töötavad need ühes sõlmes ja asuvad rajatiste andmekeskuses. Kõik objektid erinevad pisut infrastruktuuri poolest, kuid see ei sega globaalset suhtlust.
Esmalt automatiseerisime vastavalt DevOpsi tavadele taristu lokaalselt, seejärel viisime tarne testahelasse ja seejärel kliendi tooteni. Iga protsess töötati välja samm-sammult. Keskkonna seadistused fikseeritakse lähtekoodisüsteemis, arvestades, et jaotuskomplekt koostatakse automaatseks uuendamiseks. Konfiguratsioonimuudatuste korral peavad insenerid lihtsalt tegema vastavad muudatused versioonikontrollisüsteemis – ja siis toimub automaatne uuendamine probleemideta.
Tänu sellele lähenemisele on testimisprotsess oluliselt lihtsustatud. Varem olid projektis testijad, kes ei teinud muud, kui värskendasid stende käsitsi. Nüüd nad lihtsalt tulevad, vaatavad, et kõik töötab ja teevad rohkem kasulikke asju. Iga värskendust testitakse automaatselt – alates pinnatasemest kuni äristsenaariumi automatiseerimiseni. Tulemused postitatakse TestRailis eraldi aruannetena.
Kultuur
Pidevat katsetamist saab kõige paremini selgitada testi kavandamise näite kaudu. Süsteemi testimine, mida veel pole, on loominguline töö. Testiplaani kirjutades pead aru saama, kuidas õigesti testida ja milliseid harusid järgida. Samuti leidke tasakaal aja ja eelarve vahel, et määrata kindlaks optimaalne kontrollide arv. Oluline on valida täpselt vajalikud testid, mõelda, kuidas kasutaja süsteemiga suhtleb, arvestada keskkonda ja võimalikke väliseid tegureid. Ilma pideva katsetamiseta on võimatu.
Nüüd suhtlemiskultuurist. Varem oli kaks vastandlikku poolt – insenerid ja arendajad. Arendajad ütlesid: "Meid ei huvita, kuidas see käivitatakse. Olete insenerid, te olete nutikad, veenduge, et see töötab tõrgeteta". Insenerid vastasid: "Teie arendajad olete liiga hoolimatud. Olgem ettevaatlikumad ja esitame teie väljalaseid harvemini. Sest iga kord, kui annate meile lekkiva koodi, pole meile selge, kuidas suhelda.. See on kultuurilise suhtluse probleem, mis on DevOpsi vaatenurgast erinevalt üles ehitatud. Siin on nii insenerid kui ka arendajad osa ühtsest meeskonnast, mis on keskendunud pidevalt muutuvale, kuid samas töökindlale tarkvarale.
Samas meeskonnas on spetsialistid otsustanud üksteist aidata. Nagu see oli enne? Näiteks valmistati ette mingi paks juurutusjuhend, umbes 50 lehekülge pikk, insener luges läbi, ei saanud millestki aru, kirus ja palus hommikul kell kolm arendajalt kommentaari. Arendaja kommenteeris ja ka kirus - lõpuks ei olnud keegi õnnelik. Lisaks oli loomulikult ka vigu, sest te ei mäleta kõike juhistes. Ja nüüd kirjutab insener koos arendajaga skripti rakendustarkvara infrastruktuuri automatiseeritud juurutamiseks. Ja nad räägivad üksteisega praktiliselt samas keeles.
Inimesed
Meeskonna suuruse määrab värskenduse ulatus. Meeskond komplekteeritakse tarne moodustamise käigus, sinna kuuluvad huvilised projekti üldmeeskonnast. Seejärel koostatakse iga etapi eest vastutajatega uuendusplaan ja meeskond annab selle edenemisest aru. Kõik meeskonnaliikmed on vahetatavad. Meeskonna osana on meil ka varuarendaja, kuid tema ei pea peaaegu kunagi ühendust looma.
Tehnoloogia
Tehnoloogiadiagrammil on mõned punktid esile tõstetud, kuid nende all on hunnik tehnoloogiaid - nende kirjeldustega võiks välja anda terve raamatu. Seetõttu toome välja kõige huvitavamad.
Infrastruktuur koodina
Nüüd ei üllata see kontseptsioon ilmselt kedagi, kuid varem jätsid infrastruktuuride kirjeldused soovida. , katsekeskkonnad olid ainulaadsed, neid hoiti ja hellitati, tolmuosakesed puhuti neilt maha.
Tänapäeval ei karda keegi eksperimenteerida. Virtuaalsete masinate põhikujutised on olemas, keskkondade juurutamiseks on valmis stsenaariumid. Kõik mallid ja skriptid salvestatakse versioonikontrollisüsteemi ja neid värskendatakse kohe. Varem, kui oli vaja pakk stendile toimetada, tekkis konfiguratsioonilünk. Nüüd peate lihtsalt lisama lähtekoodi rea.
Lisaks infrastruktuuri skriptidele ja torujuhtmetele kasutatakse dokumenteerimiseks ka dokumentatsiooni kui koodi lähenemisviisi. Tänu sellele on lihtne uusi inimesi projektiga ühendada, neile näiteks testiplaanis kirjeldatud funktsioonide põhjal süsteemi tutvustada ning ka testjuhtumeid taaskasutada.
Pidev tarnimine ja jälgimine
DevOpsi kohta rääkisime sellest, kuidas valisime pideva tarnimise ja jälgimise rakendamiseks tööriistu. Tihti pole vaja midagi ümber kirjutada – piisab varem kirjutatud skriptide kasutamisest, komponentidevahelise integratsiooni korrektsest ehitamisest ja ühise halduskonsooli loomisest. Ja kõiki protsesse saab käivitada ühe nupu või ajakava abil.
Inglise keeles on erinevad mõisted Continuous Delivery ja Continuous Deployment. Mõlemat võib tõlkida kui "pidev kohaletoimetamine", kuid tegelikult on nende vahel väike erinevus. Meie hajutatud energiaettevõtte tehniliste dokumentide voo projektis kasutatakse pigem kohaletoimetamist - kui tootmiseks paigaldamine toimub käsu alusel. Deploymentis toimub installimine automaatselt. Pidev tarnimine selles projektis on üldiselt muutunud DevOpsi keskosa.
Üldiselt saate teatud parameetrite kogumisel selgelt aru, miks DevOpsi praktikad on kasulikud. Ja edastage see juhtkonnale, kes tõesti numbreid armastab. Käivituste koguarv, skriptietappide täitmisaeg, edukate käivitamiste osakaal – see kõik mõjutab otseselt igaühe lemmikaega turule jõudmiseks, st aega versioonihaldussüsteemile pühendumisest kuni versiooni väljalaskmiseni. tootmiskeskkond. Vajalike tööriistade kasutuselevõtuga saavad insenerid väärtuslikud näitajad posti teel ning projektijuht näeb neid armatuurlaual. Nii saate kohe hinnata uute tööriistade eeliseid. Ja saate neid oma infrastruktuuris proovida, kasutades DevOpsi disainerit.
Kes vajab meie ?
Ärgem teesklegem: alustuseks sai ta meile kasulikuks. Nagu juba öeldud, tuleb kliendiga rääkida ühes keeles ja DevOpsi disaineri abiga saame sellise vestluse aluse kiiresti visandada. Ettevõtlusspetsialistid saavad ise hinnata, mida nad vajavad, ja seeläbi kiiremini areneda. Püüdsime kujundaja võimalikult üksikasjalikuks muuta, lisades hunniku kirjeldusi, et iga kasutaja mõistaks, mida ta valib.
Projekteerija formaat võimaldab arvestada ettevõtte olemasolevate arengutega ehitusprotsesside ja automatiseerimise vallas. Pole vaja kõike lammutada ja uuesti üles ehitada, kui saab valida vaid lahendusi, mis integreeruvad hästi olemasolevate protsessidega ja mis suudavad lihtsalt lüngad täita.
Võib-olla on teie areng juba liikunud kõrgemale tasemele ja meie tööriist tundub liiga "kaptenilik". Kuid leiame, et see on kasulik enda jaoks ja loodame, et see on kasulik ka mõnele lugejale. Tuletame teile meelde projekteerijale - kui midagi, siis saate skeemi kohe pärast algandmete sisestamist. Oleme tänulikud tagasiside ja täienduste eest.
Allikas: www.habr.com