Toimitimme kerran asiakkaalle sähköisen dokumentinhallintajärjestelmän yhdessä toimipisteessä. Ja sitten toiseen esineeseen. Ja vielä yksi. Ja neljännellä ja viidennellä. Innostuimme niin, että saavutimme 10 jaettua kohdetta. Se osoittautui voimakkaaksi... varsinkin kun pääsimme toteuttamaan muutoksia. Osana toimitusta tuotantokiertoon testijärjestelmän 5 skenaariota vaativat lopulta 10 tuntia ja 6-7 työntekijää. Tällaiset kustannukset pakottivat meidät toimittamaan mahdollisimman harvoin. Kolmen vuoden toiminnan jälkeen emme kestäneet sitä ja päätimme piristää projektia ripaus DevOpsia.
Nyt kaikki testaus tapahtuu 3 tunnissa, ja siihen osallistuu 3 henkilöä: insinööri ja kaksi testaajaa. Parannukset ilmaistaan selvästi numeroina ja johtavat paljon rakastetun TTM:n vähenemiseen. Kokemuksemme mukaan DevOpsista hyötyviä asiakkaita on paljon enemmän kuin niitä, jotka edes tietävät siitä. Siksi tuodaksemme DevOpsin lähemmäksi ihmisiä olemme kehittäneet yksinkertaisen konstruktorin, josta puhumme tarkemmin tässä viestissä.
Kerrotaan nyt tarkemmin. Yksi energiayhtiö ottaa käyttöön teknistä dokumenttien hallintajärjestelmää 10 suuressa toimipaikassa. Tämän mittakaavan projekteissa ei ole helppoa navigoida ilman DevOpsia, koska suuri osa käsityöstä viivästyttää suuresti työtä ja myös heikentää laatua - kaikki manuaalinen työ on täynnä virheitä. Toisaalta on projekteja, joissa on vain yksi asennus, mutta kaiken pitää toimia automaattisesti, jatkuvasti ja ilman vikoja - esimerkiksi samat asiakirjankulkujärjestelmät suurissa monoliittisissa organisaatioissa. Muuten joku tekee asetukset manuaalisesti, unohtaa käyttöönottoohjeet - ja seurauksena tuotannossa asetukset menetetään ja kaikki romahtaa.
Yleensä teemme asiakkaan kanssa sopimuksen, ja tässä tapauksessa kiinnostuksemme poikkeavat hieman. Asiakas tarkastelee projektia tiukasti budjetin ja teknisten eritelmien rajoissa. Voi olla vaikea selittää hänelle erilaisten DevOps-käytäntöjen etuja, jotka eivät sisälly teknisiin eritelmiin. Entä jos hän on kiinnostunut liiketoiminnallista lisäarvoa tuovista pikajulkaisuista tai automaatioputken rakentamisesta?
Valitettavasti tätä kiinnostusta ei aina löydy, kun työskentelet ennalta hyväksyttyjen kustannusten kanssa. Käytännössämme oli tapaus, jolloin jouduimme poimimaan häikäilemättömän ja huolimattoman urakoitsijan kehitystyötä. Se oli kauheaa: ei ollut ajantasaisia lähdekoodeja, saman järjestelmän koodikanta oli erilainen eri asennuksissa, dokumentaatio puuttui osittain ja osittain kauhealaatuista. Tietenkään asiakas ei voinut hallita lähdekoodia, kokoonpanoa, julkaisuja jne.
Toistaiseksi kaikki eivät tiedä DevOpsista, mutta heti kun puhumme sen eduista, todellisista resurssien säästöistä, kaikkien asiakkaiden silmät kirkastuvat. Joten DevOpsia sisältävien pyyntöjen määrä kasvaa ajan myötä. Jotta voimme helposti puhua samaa kieltä asiakkaiden kanssa, meidän on yhdistettävä nopeasti liiketoimintaongelmat ja DevOps-käytännöt, jotka auttavat rakentamaan sopivan kehitysputken.
Joten toisaalta meillä on joukko ongelmia, toisaalta meillä on DevOps-tietoa, käytäntöjä ja työkaluja. Mikset jakaisi kokemuksia kaikkien kanssa?
DevOps-konstruktorin luominen
Agilella on oma manifestinsa. ITIL:llä on oma menetelmänsä. DevOps on vähemmän onnekas - se ei ole vielä hankkinut malleja ja standardeja. Siitä huolimatta määritellä yritysten kypsyys arvioiden niiden kehitystä ja toimintatapoja.
Onneksi tunnettu yritys Gartner vuonna 2014 ja analysoitiin keskeisiä DevOps-käytäntöjä ja niiden välisiä suhteita. Tämän perusteella julkaisin infografian:
Otimme sen perustaksemme . Jokaisella neljällä alueella on joukko työkaluja - keräsimme ne tietokantaan, tunnistimme suosituimmat, tunnistimme integraatiopisteet ja sopivat optimointimekanismit. Kaiken kaikkiaan se selvisi 36 harjoitusta ja 115 työkalua, joista neljännes on avoimen lähdekoodin tai ilmaisia ohjelmistoja. Seuraavaksi kerromme, mitä olemme saavuttaneet kullakin alueella ja esimerkkinä kuinka tämä toteutettiin teknisen dokumentinhallinnan luomisprojektissa, jolla aloitimme postauksen.
prosessit
Pahamaineisessa EDMS-projektissa teknisen dokumentaation hallintajärjestelmä otettiin käyttöön saman kaavan mukaan jokaisessa 10 kohteessa. Asennus sisältää 4 palvelinta: tietokantapalvelimen, sovelluspalvelimen, kokotekstin indeksoinnin ja sisällönhallinnan. Asennuksessa ne toimivat yhdessä solmussa ja sijaitsevat tilojen datakeskuksessa. Kaikki objektit eroavat hieman infrastruktuuriltaan, mutta tämä ei häiritse globaalia vuorovaikutusta.
Ensin DevOps-käytäntöjen mukaisesti automatisoimme infrastruktuurin paikallisesti, sitten toimme toimituksen testipiiriin ja sitten asiakkaan tuotteeseen. Jokainen prosessi työstettiin askel askeleelta. Ympäristöasetukset on kiinteät lähdekoodijärjestelmässä, mikä huomioidaan jakelusarjan automaattista päivitystä varten. Konfiguraatiomuutosten sattuessa insinöörien tarvitsee vain tehdä tarvittavat muutokset versionhallintajärjestelmään - ja sitten automaattinen päivitys tapahtuu ilman ongelmia.
Tämän lähestymistavan ansiosta testausprosessi on yksinkertaistettu huomattavasti. Aikaisemmin projektissa oli testaajia, jotka eivät tehneet muuta kuin päivittäneet telineitä manuaalisesti. Nyt he vain tulevat, näkevät, että kaikki toimii ja tekevät hyödyllisempiä asioita. Jokainen päivitys testataan automaattisesti - pintatasolta liiketoimintaskenaarioiden automatisointiin. Tulokset julkaistaan erillisinä raportteina TestRailissa.
Культура
Jatkuva kokeilu selittyy parhaiten testisuunnittelun esimerkin kautta. Sellaisen järjestelmän testaaminen, jota ei vielä ole olemassa, on luovaa työtä. Kun kirjoitat testisuunnitelmaa, sinun on ymmärrettävä, miten testataan oikein ja mitä haaroja seurata. Ja myös löytää tasapaino ajan ja budjetin välillä määrittääksesi optimaalisen tarkastusten määrän. On tärkeää valita tarkalleen tarvittavat testit, miettiä kuinka käyttäjä on vuorovaikutuksessa järjestelmän kanssa, ottaa huomioon ympäristö ja mahdolliset ulkoiset tekijät. Se on mahdotonta ilman jatkuvaa kokeilua.
Nyt puhutaan vuorovaikutuskulttuurista. Aiemmin vastakkaisia puolia oli kaksi - insinöörit ja kehittäjät. Kehittäjät sanoivat: "Emme välitä siitä, miten se käynnistetään. Olette insinöörejä, olette älykkäitä, varmista, että se toimii ilman vikoja". Insinöörit vastasivat: "Te kehittäjät olette liian huolimattomia. Olkaamme varovaisempia, ja toistamme julkaisusi harvemmin. Koska joka kerta, kun annat meille vuotavan koodin, meille ei ole selvää, kuinka toimia.". Tämä on kulttuurinen vuorovaikutuskysymys, joka on rakenteeltaan erilainen DevOpsin näkökulmasta. Täällä sekä insinöörit että kehittäjät ovat osa yhtä tiimiä, joka keskittyy jatkuvasti muuttuviin, mutta samalla luotettaviin ohjelmistoihin.
Samassa tiimissä asiantuntijat ovat päättäneet auttaa toisiaan. Kuten se oli ennen? Valmisteltiin esimerkiksi paksuja käyttöönotto-ohjeita, noin 50 sivua.. Insinööri luki sen, ei ymmärtänyt jotain, kirosi ja pyysi kehittäjää kommentoimaan kello kolmella aamulla. Kehittäjä kommentoi ja myös kirosi - lopulta kukaan ei ollut onnellinen. Lisäksi tietysti oli virheitä, koska et voi muistaa kaikkea ohjeista. Ja nyt insinööri kirjoittaa yhdessä kehittäjän kanssa käsikirjoitusta sovellusohjelmistoinfrastruktuurin automaattista käyttöönottoa varten. Ja he puhuvat toisilleen käytännössä samalla kielellä.
Ihmiset
Joukkueen koko määräytyy päivityksen laajuuden mukaan. Tiimi rekrytoidaan toimituksen muodostumisen aikana, siihen kuuluu kiinnostuneita yleisestä projektitiimistä. Sitten kirjoitetaan päivityssuunnitelma kustakin vaiheesta vastaavien kanssa, ja tiimi raportoi sen etenemisestä. Kaikki joukkueen jäsenet ovat vaihtokelpoisia. Osana tiimiä meillä on myös varakehittäjä, mutta hänen ei tarvitse melkein koskaan ottaa yhteyttä.
Tekniikka
Teknologiakaaviossa muutama kohta on korostettu, mutta niiden alla on kasa tekniikoita - niiden kuvauksilla voisi julkaista kokonaisen kirjan. Joten korostamme mielenkiintoisimpia.
Infrastruktuuri koodina
Nyt luultavasti tämä konsepti ei yllätä ketään, mutta aiemmin infrastruktuurien kuvaukset jättivät paljon toivomisen varaa. , testiympäristöt olivat ainutlaatuisia, niitä vaalittiin ja vaalittiin, niistä puhallettiin pölyhiukkasia.
Nykyään kukaan ei pelkää kokeilla. Virtuaalikoneista on peruskuvia, valmiita skenaarioita ympäristöjen käyttöönottoon. Kaikki mallit ja komentosarjat tallennetaan versionhallintajärjestelmään ja päivitetään nopeasti. Aiemmin, kun paketti piti toimittaa telineeseen, ilmaantui konfiguraatiovako. Nyt sinun tarvitsee vain lisätä rivi lähdekoodiin.
Infrastruktuuriskriptien ja -putkien lisäksi dokumentoinnissa käytetään myös Documentation as a Code -lähestymistapaa. Tämän ansiosta projektiin on helppo kytkeä uusia ihmisiä, esitellä heidät järjestelmään esimerkiksi testisuunnitelmassa kuvattujen toimintojen perusteella ja myös käyttää testitapauksia uudelleen.
Jatkuva toimitus ja seuranta
DevOpsista puhuimme siitä, kuinka valitsimme työkalut jatkuvan toimituksen ja seurannan toteuttamiseen. Usein mitään ei tarvitse kirjoittaa uudelleen - riittää, että käytät aiemmin kirjoitettuja skriptejä, rakennat oikein komponenttien välisen integraation ja luot yhteisen hallintakonsolin. Ja kaikki prosessit voidaan käynnistää yhdellä painikkeella tai aikataululla.
Englannin kielellä on erilaisia käsitteitä, Continuous Delivery ja Continuous Deployment. Molemmat voidaan kääntää "jatkuvaksi toimitukseksi", mutta itse asiassa niiden välillä on pieni ero. Hajautetun energiayhtiön teknisen asiakirjavirran projektissamme käytetään pikemminkin Toimitusta - kun asennus tuotantoon tapahtuu käskystä. Käyttöönotossa asennus tapahtuu automaattisesti. Jatkuva toimitus tässä projektissa on yleensä tullut DevOpsin keskeinen osa.
Yleisesti ottaen tiettyjä parametreja keräämällä ymmärrät selvästi, miksi DevOps-käytännöt ovat hyödyllisiä. Ja välitä tämä johdolle, joka todella rakastaa numeroita. Lanseerausten kokonaismäärä, skriptivaiheiden suoritusaika, onnistuneiden julkaisujen osuus – kaikki tämä vaikuttaa suoraan kaikkien suosikkiaikaan markkinoille tuloon, eli aikaan, joka kuluu sitoutumisesta versionhallintajärjestelmään version julkaisuun. tuotantoympäristö. Tarvittavien työkalujen käyttöönoton myötä insinöörit saavat arvokkaita indikaattoreita postitse, ja projektipäällikkö näkee ne kojelaudalla. Näin voit välittömästi arvioida uusien työkalujen hyödyt. Ja voit kokeilla niitä infrastruktuurissasi DevOps-suunnittelijan avulla.
Kuka meitä tarvitsee ?
Älkäämme teeskennelkö: aluksi hänestä tuli meille hyödyllinen. Kuten olemme jo todenneet, sinun tulee puhua samaa kieltä asiakkaan kanssa, ja DevOps-suunnittelijan avulla voimme nopeasti hahmotella perusteet tällaiselle keskustelulle. Liiketoiminnan asiantuntijat voivat itse arvioida, mitä he tarvitsevat, ja siten kehittyä nopeammin. Pyrimme tekemään suunnittelijasta mahdollisimman yksityiskohtaista lisäämällä joukko kuvauksia, jotta jokainen käyttäjä ymmärtää, mitä hän valitsee.
Suunnittelijan muoto mahdollistaa yrityksen olemassa olevan rakennusprosessien ja automaation kehityksen huomioimisen. Kaikkea ei tarvitse purkaa ja rakentaa uudelleen, jos voit valita vain ratkaisuja, jotka integroituvat hyvin olemassa oleviin prosesseihin ja jotka voivat yksinkertaisesti täyttää aukot.
Ehkä kehityssi on jo siirtynyt korkeammalle tasolle ja työkalumme näyttää liian "kapteenilta". Mutta pidämme sitä hyödyllisenä itsellemme ja toivomme, että siitä on hyötyä joillekin lukijoille. Muistutamme sinua suunnittelijalle - saat kaavion heti alkutietojen syöttämisen jälkeen. Olemme kiitollisia palautteestasi ja lisäyksistäsi.
Lähde: will.com