Ons het een keer 'n elektroniese dokumentbestuurstelsel aan 'n klant by een fasiliteit verskaf. En dan na 'n ander voorwerp. En nog een. En op die vierde, en op die vyfde. Ons het so meegevoer geraak dat ons 10 verspreide voorwerpe bereik het. Dit het kragtig uitgedraai ... veral toe ons by die lewering van die veranderinge gekom het. As deel van die aflewering aan die produksiekring, het 5 scenario's van die toetsstelsel uiteindelik 10 uur en 6-7 werknemers benodig. Sulke koste het ons gedwing om aflewerings so selde moontlik te doen. Na drie jaar se operasie kon ons dit nie verduur nie en het besluit om die projek op te kikker met 'n knippie DevOps.
Nou vind alle toetsing in 3 uur plaas, en 3 mense neem daaraan deel: 'n ingenieur en twee toetsers. Die verbeterings word duidelik in getalle uitgedruk en lei tot 'n vermindering in die baie geliefde TTM. Volgens ons ervaring is daar baie meer kliënte wat by DevOps kan baat vind as diegene wat selfs daarvan weet. Daarom, om DevOps nader aan mense te bring, het ons 'n eenvoudige konstruktor ontwikkel, waaroor ons in meer besonderhede in hierdie pos sal praat.
Kom ons vertel jou nou in meer detail. Een energiemaatskappy is besig om 'n tegniese dokumentbestuurstelsel by 10 groot fasiliteite te ontplooi. Dit is nie maklik om projekte van hierdie skaal sonder DevOps te navigeer nie, want 'n groot deel van handearbeid vertraag die werk baie en verminder ook kwaliteit - alle handwerk is belaai met foute. Aan die ander kant is daar projekte waar daar net een installasie is, maar alles moet outomaties, konstant en sonder mislukking werk – byvoorbeeld dieselfde dokumentvloeistelsels in groot monolitiese organisasies. Andersins sal iemand die instellings met die hand maak, vergeet van die ontplooiingsinstruksies - en gevolglik sal die instellings in produksie verlore gaan en alles sal ineenstort.
Gewoonlik werk ons met die kliënt deur middel van 'n kontrak, en in hierdie geval verskil ons belange effens. Die kliënt kyk na die projek streng binne die begroting en tegniese spesifikasies. Dit kan moeilik wees om die voordele van verskeie DevOps-praktyke wat nie by die tegniese spesifikasies ingesluit is, aan hom te verduidelik nie. Wat as hy belangstel in vinnige vrystellings met toegevoegde besigheidswaarde, of in die bou van 'n outomatiseringspyplyn?
Helaas, wanneer daar met 'n vooraf-goedgekeurde koste gewerk word, word hierdie belangstelling nie altyd gevind nie. In ons praktyk was daar 'n geval toe ons die ontwikkeling van 'n gewetenlose en sorgelose kontrakteur moes optel. Dit was verskriklik: daar was geen bygewerkte bronkodes nie, die kodebasis van dieselfde stelsel was anders op verskillende installasies, die dokumentasie was gedeeltelik afwesig en gedeeltelik van verskriklike gehalte. Natuurlik het die kliënt nie beheer oor die bronkode, samestelling, vrystellings, ens.
Tot dusver weet nie almal van DevOps nie, maar sodra ons oor die voordele daarvan praat, oor werklike hulpbronbesparing, lig die oë van alle kliënte. Die aantal versoeke wat DevOps insluit, neem dus mettertyd toe. Hier, om maklik dieselfde taal met kliënte te praat, moet ons besigheidsprobleme en DevOps-praktyke vinnig verbind wat sal help om 'n geskikte ontwikkelingspyplyn te bou.
So, ons het 'n stel probleme aan die een kant, ons het DevOps kennis, praktyke en gereedskap aan die ander kant. Hoekom deel jy nie die ervaring met almal nie?
Skep 'n DevOps-konstruktor
Agile het sy eie manifes. ITIL het sy eie metodologie. DevOps is minder gelukkig – dit het nog nie sjablone en standaarde verkry nie. Alhoewel bepaal die volwassenheid van maatskappye gebaseer op 'n beoordeling van hul ontwikkeling en bedryfspraktyke.
Gelukkig het die bekende maatskappy Gartner in 2014 en sleutel DevOps-praktyke en die verhoudings tussen hulle ontleed. Op grond hiervan het ek 'n infografika vrygestel:
Ons het dit as die basis geneem vir ons . Elk van die vier areas het 'n stel gereedskap - ons het dit in 'n databasis versamel, die gewildstes geïdentifiseer, integrasiepunte en geskikte optimaliseringsmeganismes geïdentifiseer. In totaal het dit geblyk 36 oefeninge en 115 gereedskap, waarvan 'n kwart oopbron- of gratis sagteware is. Vervolgens sal ons praat oor wat ons bereik het op elke gebied en, as 'n voorbeeld, oor hoe dit geïmplementeer is in die projek om tegniese dokumentbestuur te skep, waarmee ons die pos begin het.
prosesse
In die berugte EDMS-projek is die tegniese dokumentasiebestuurstelsel volgens dieselfde skema by elk van die 10 voorwerpe ontplooi. Die installasie sluit 4 bedieners in: databasisbediener, toepassingsbediener, volteksindeksering en inhoudbestuur. In die installasie werk hulle binne 'n enkele nodus en is hulle in die datasentrum by die fasiliteite geleë. Alle voorwerpe verskil effens in infrastruktuur, maar dit meng nie in met globale interaksie nie.
Eerstens, volgens DevOps-praktyke, het ons die infrastruktuur plaaslik geoutomatiseer, toe het ons die aflewering na die toetskring gebring, en dan na die kliënt se produk. Elke proses is stap vir stap uitgewerk. Die omgewingsinstellings word in die bronkodestelsel vasgestel, met inagneming van watter die verspreidingskit saamgestel is vir outomatiese opdatering. In die geval van konfigurasieveranderings moet ingenieurs eenvoudig die toepaslike veranderinge aan die weergawebeheerstelsel aanbring - en dan sal die outomatiese opdatering sonder probleme plaasvind.
Danksy hierdie benadering is die toetsproses aansienlik vereenvoudig. Voorheen het die projek toetsers gehad wat niks anders gedoen het as om stalletjies handmatig op te dateer nie. Nou kom hulle net, sien alles werk en doen meer nuttige dinge. Elke opdatering word outomaties getoets - van oppervlakvlak tot outomatisering van sakescenario's. Die resultate word as aparte verslae in TestRail geplaas.
Культура
Deurlopende eksperimentering word die beste verduidelik deur die voorbeeld van toetsontwerp. Om 'n stelsel te toets wat nog nie bestaan nie, is kreatiewe werk. Wanneer jy 'n toetsplan skryf, moet jy verstaan hoe om korrek te toets en watter vertakkings om te volg. En vind ook 'n balans tussen tyd en begroting om die optimale aantal tjeks te bepaal. Dit is belangrik om presies die nodige toetse te kies, te dink oor hoe die gebruiker met die stelsel sal omgaan, die omgewing en moontlike eksterne faktore in ag te neem. Dit is onmoontlik om sonder voortdurende eksperimentering te doen.
Nou oor die kultuur van interaksie. Voorheen was daar twee opponerende kante – ingenieurs en ontwikkelaars. Die ontwikkelaars het gesê: “Ons gee nie om hoe dit bekendgestel gaan word nie. Julle is ingenieurs, julle is slim, maak seker dat dit sonder mislukkings werk.". Die ingenieurs het geantwoord: “Julle ontwikkelaars is te onverskillig. Kom ons wees versigtiger, en ons sal jou vrystellings minder gereeld speel. Want elke keer as jy vir ons ’n lekkende kode gee, is dit nie vir ons duidelik hoe om interaksie te hê nie.”. Dit is 'n kulturele interaksiekwessie wat anders gestruktureer is vanuit 'n DevOps-perspektief. Hier is beide ingenieurs en ontwikkelaars deel van 'n enkele span wat daarop gefokus is om voortdurend te verander, maar terselfdertyd betroubare sagteware.
Binne dieselfde span is spesialiste vasbeslote om mekaar te help. Soos dit voorheen was? Byvoorbeeld, 'n paar dik ontplooiingsinstruksies was besig om voorberei te word, ongeveer 50 bladsye lank. Die ingenieur het dit gelees, iets nie verstaan nie, gevloek en die ontwikkelaar om drie-uur die oggend gevra om kommentaar te lewer. Die ontwikkelaar het kommentaar gelewer en ook gevloek – op die ou end was niemand gelukkig nie. Boonop was daar natuurlik 'n paar foute, want jy kan nie alles in die instruksies onthou nie. En nou is die ingenieur, saam met die ontwikkelaar, besig om 'n skrif te skryf vir die outomatiese ontplooiing van toepassingsagteware-infrastruktuur. En hulle praat feitlik in dieselfde taal met mekaar.
Mense
Die grootte van die span word bepaal deur die omvang van die opdatering. Die span word tydens die vorming van die aflewering gewerf; dit sluit belangstellendes van die algemene projekspan in. Dan word 'n opdateringsplan geskryf met diegene wat vir elke stadium verantwoordelik is, en die span doen verslag soos dit vorder. Alle spanlede is uitruilbaar. As deel van die span het ons ook 'n rugsteunontwikkelaar, maar hy hoef amper nooit aan te sluit nie.
Tegnologie
In die tegnologiediagram word 'n paar punte uitgelig, maar onder hulle is daar 'n klomp tegnologieë - jy kan 'n hele boek met hul beskrywings publiseer. So ons sal die interessantste uitlig.
Infrastruktuur as kode
Nou, waarskynlik, sal hierdie konsep niemand verras nie, maar voorheen het die beskrywings van infrastruktuur veel te wense oorgelaat. , die toetsomgewings was uniek, hulle is gekoester en gekoester, stofdeeltjies is daarvan afgewaai.
Deesdae is niemand bang om te eksperimenteer nie. Daar is basiese beelde van virtuele masjiene, en klaargemaakte scenario's vir die implementering van omgewings. Alle sjablone en skrifte word in 'n weergawebeheerstelsel gestoor en word dadelik opgedateer. Voorheen, toe dit nodig was om 'n pakkie by 'n staanplek af te lewer, het 'n konfigurasiegaping verskyn. Nou moet jy net 'n reël by die bronkode voeg.
Benewens infrastruktuurskrifte en pyplyne, word die Dokumentasie as 'n Kode-benadering ook vir dokumentasie gebruik. Danksy dit is dit maklik om nuwe mense aan die projek te koppel, hulle aan die stelsel bekend te stel op grond van die funksies wat byvoorbeeld in die toetsplan beskryf word, en ook toetsgevalle te hergebruik.
Deurlopende aflewering en monitering
oor DevOps, het ons gepraat oor hoe ons gereedskap gekies het vir die implementering van deurlopende aflewering en monitering. Dikwels is dit nie nodig om iets te herskryf nie - dit is genoeg om voorheen geskrewe skrifte te gebruik, integrasie tussen komponente korrek te bou en 'n gemeenskaplike bestuurskonsole te skep. En alle prosesse kan van stapel gestuur word met een knoppie of skedule.
In Engels is daar verskillende konsepte, Continuous Delivery en Continuous Deployment. Albei kan vertaal word as "voortdurende aflewering", maar in werklikheid is daar 'n effense verskil tussen hulle. In ons projek vir die tegniese dokumentvloei van 'n verspreide energiemaatskappy, word aflewering eerder gebruik - wanneer installasie vir produksie op bevel plaasvind. In Ontplooiing vind installasie outomaties plaas. Deurlopende aflewering in hierdie projek het oor die algemeen geword sentrale deel van DevOps.
Oor die algemeen, deur sekere parameters te versamel, kan jy duidelik verstaan waarom DevOps-praktyke nuttig is. En dra dit oor aan die bestuur, wat baie lief is vir syfers. Die totale aantal bekendstellings, die uitvoeringstyd van skripstadia, die aandeel suksesvolle bekendstellings - dit alles beïnvloed direk almal se gunsteling tyd om te bemark, dit wil sê die tyd vanaf 'n verbintenis tot die weergawebeheerstelsel tot die vrystelling van 'n weergawe op 'n produksie omgewing. Met die implementering van die nodige gereedskap ontvang ingenieurs waardevolle aanwysers per pos, en die projekbestuurder sien dit op die dashboard. Op hierdie manier kan jy dadelik die voordele van nuwe gereedskap evalueer. En jy kan dit op jou infrastruktuur probeer deur die DevOps-ontwerper te gebruik.
Wie sal ons nodig hê ?
Laat ons nie voorgee nie: vir 'n begin het hy vir ons nuttig geword. Soos ons reeds gesê het, moet jy dieselfde taal met die kliënt praat, en met die hulp van die DevOps-ontwerper kan ons vinnig die basis vir so 'n gesprek skets. Besigheidspesialiste sal self kan bepaal wat hulle nodig het en sodoende vinniger ontwikkel. Ons het probeer om die ontwerper so gedetailleerd moontlik te maak, deur 'n klomp beskrywings by te voeg sodat enige gebruiker verstaan wat hy kies.
Die formaat van die ontwerper laat jou toe om die maatskappy se bestaande ontwikkelings in bouprosesse en outomatisering in ag te neem. Dit is nie nodig om alles af te breek en weer op te bou as jy net oplossings kan kies wat goed met bestaande prosesse integreer en wat bloot die leemtes kan vul nie.
Miskien het jou ontwikkeling reeds na 'n hoër vlak beweeg en ons instrument sal te "kaptein s'n" lyk. Maar ons vind dit nuttig vir onsself en hoop dat dit vir sommige van die lesers nuttig sal wees. Ons herinner jou aan die ontwerper - indien enigiets, ontvang u die diagram onmiddellik nadat u die aanvanklike data ingevoer het. Ons sal dankbaar wees vir jou terugvoer en byvoegings.
Bron: will.com