En gång levererade vi ett elektroniskt dokumenthanteringssystem till en kund på en anläggning. Och sedan till ett annat objekt. Och en till. Och på den fjärde och på den femte. Vi blev så medryckta att vi nådde 10 utdelade föremål. Det blev kraftfullt... speciellt när vi kom till att leverera förändringarna. Som en del av leveransen till produktionskretsen krävde 5 scenarier av testsystemet slutligen 10 timmar och 6-7 anställda. Sådana kostnader tvingade oss att göra leveranser så sällan som möjligt. Efter tre års drift kunde vi inte stå ut och bestämde oss för att krydda projektet med en nypa DevOps.
Nu sker all testning på 3 timmar, och 3 personer deltar i det: en ingenjör och två testare. Förbättringarna uttrycks tydligt i siffror och leder till en minskning av den mycket älskade TTM. Enligt vår erfarenhet finns det många fler kunder som kan dra nytta av DevOps än de som ens känner till det. Därför, för att föra DevOps närmare människor, har vi utvecklat en enkel konstruktör, som vi kommer att prata mer om i det här inlägget.
Låt oss nu berätta mer i detalj. Ett energibolag använder ett tekniskt dokumenthanteringssystem vid 10 stora anläggningar. Det är inte lätt att navigera i projekt av denna skala utan DevOps, eftersom en stor del av manuellt arbete försenar arbetet kraftigt och även minskar kvaliteten - allt manuellt arbete är fyllt av fel. Å andra sidan finns det projekt där det bara finns en installation, men allt behöver fungera automatiskt, konstant och utan fel – till exempel samma dokumentflödessystem i stora monolitiska organisationer. Annars kommer någon att göra inställningarna manuellt, glömma installationsinstruktionerna - och som ett resultat kommer inställningarna att gå förlorade i produktionen och allt kommer att kollapsa.
Vanligtvis arbetar vi med kunden genom ett kontrakt, och i det här fallet skiljer sig våra intressen något. Kunden tittar på projektet strikt inom budget och tekniska specifikationer. Det kan vara svårt att förklara för honom fördelarna med olika DevOps-praxis som inte ingår i de tekniska specifikationerna. Tänk om han är intresserad av snabba releaser med mer affärsvärde, eller av att bygga en automationspipeline?
Tyvärr, när man arbetar med en i förväg godkänd kostnad, hittas inte alltid detta intresse. I vår praktik var det ett fall då vi var tvungna att ta upp utvecklingen av en skrupelfri och slarvig entreprenör. Det var hemskt: det fanns inga uppdaterade källkoder, kodbasen för samma system var olika på olika installationer, dokumentationen saknades delvis och delvis av fruktansvärd kvalitet. Kunden hade förstås inte kontroll över källkoden, montering, releaser osv.
Än så länge känner inte alla till DevOps, men så fort vi pratar om dess fördelar, om verkliga resursbesparingar, lyser ögonen hos alla kunder. Så antalet förfrågningar som inkluderar DevOps ökar med tiden. Här, för att enkelt kunna prata samma språk med kunderna, måste vi snabbt koppla ihop affärsproblem och DevOps-praxis som hjälper till att bygga en lämplig utvecklingspipeline.
Så vi har en uppsättning problem å ena sidan, vi har DevOps kunskap, praxis och verktyg å andra sidan. Varför inte dela upplevelsen med alla?
Skapa en DevOps-konstruktör
Agile har sitt eget manifest. ITIL har sin egen metodik. DevOps är mindre lyckligt lottad - det har ännu inte skaffat mallar och standarder. Fastän fastställa företagens mognad baserat på en bedömning av deras utveckling och operativa praxis.
Lyckligtvis, det välkända företaget Gartner 2014 och analyserade viktiga DevOps-praxis och relationerna dem emellan. Baserat på detta släppte jag en infografik:
Vi tog det som grund för vårt . Vart och ett av de fyra områdena har en uppsättning verktyg - vi samlade dem i en databas, identifierade de mest populära, identifierade integrationspunkter och lämpliga optimeringsmekanismer. Totalt visade det sig 36 övningar och 115 verktyg, varav en fjärdedel är öppen källkod eller fri programvara. Därefter ska vi prata om vad vi har uppnått inom respektive område och som exempel om hur detta implementerades i projektet för att skapa teknisk dokumenthantering, som vi startade inlägget med.
Processerna
I det ökända EDMS-projektet användes det tekniska dokumentationshanteringssystemet enligt samma schema vid vart och ett av de 10 objekten. Installationen inkluderar 4 servrar: databasserver, applikationsserver, fulltextindexering och innehållshantering. I installationen arbetar de inom en enda nod och är placerade i datacentret på anläggningarna. Alla objekt skiljer sig något i infrastruktur, men detta stör inte global interaktion.
Först, enligt DevOps praxis, automatiserade vi infrastrukturen lokalt, sedan tog vi leveransen till testkretsen och sedan till kundens produkt. Varje process utarbetades steg för steg. Miljöinställningarna är fixerade i källkodssystemet, med hänsyn till vilken distributionssats som är kompilerad för automatisk uppdatering. I händelse av konfigurationsändringar behöver ingenjörer helt enkelt göra lämpliga ändringar i versionskontrollsystemet - och sedan kommer den automatiska uppdateringen att ske utan problem.
Tack vare detta tillvägagångssätt har testprocessen förenklats avsevärt. Tidigare hade projektet testare som inte gjorde annat än att manuellt uppdatera stativ. Nu kommer de bara, ser att allt fungerar och gör nyttigare saker. Varje uppdatering testas automatiskt - från ytnivå till automatisering av affärsscenarier. Resultaten läggs ut som separata rapporter i TestRail.
Культура
Kontinuerlig experimentering förklaras bäst genom exemplet med testdesign. Att testa ett system som inte finns ännu är kreativt arbete. När du skriver en testplan måste du förstå hur du testar rätt och vilka grenar du ska följa. Och hitta även en balans mellan tid och budget för att bestämma det optimala antalet kontroller. Det är viktigt att välja exakt de nödvändiga testerna, tänka på hur användaren kommer att interagera med systemet, ta hänsyn till miljön och eventuella yttre faktorer. Det är omöjligt att göra utan kontinuerliga experiment.
Nu om interaktionskulturen. Tidigare fanns det två motsatta sidor - ingenjörer och utvecklare. Utvecklarna sa: "Vi bryr oss inte om hur det kommer att lanseras. Ni är ingenjörer, ni är smarta, se till att det fungerar utan fel". Ingenjörerna svarade: "Ni utvecklare är för slarviga. Låt oss vara mer försiktiga, så kommer vi att spela dina släpp mer sällan. För varje gång du ger oss en läckande kod är det inte klart för oss hur vi ska interagera.". Detta är en kulturell interaktionsfråga som är strukturerad annorlunda ur ett DevOps-perspektiv. Här ingår både ingenjörer och utvecklare i ett enda team som är fokuserade på att ständigt förändra, men samtidigt pålitlig programvara.
Inom samma team är specialister fast beslutna att hjälpa varandra. Som det var innan? Till exempel förbereddes några tjocka installationsinstruktioner, cirka 50 sidor långa. Ingenjören läste den, förstod inte något, förbannade och bad utvecklaren vid tretiden på morgonen att kommentera. Utvecklaren kommenterade och förbannade också – till slut var ingen nöjd. Plus, naturligtvis, det fanns några misstag, eftersom du inte kan komma ihåg allt i instruktionerna. Och nu skriver ingenjören, tillsammans med utvecklaren, ett skript för automatiserad distribution av applikationsprogramvaruinfrastruktur. Och de pratar med varandra praktiskt taget på samma språk.
Människor
Teamets storlek bestäms av uppdateringens omfattning. Teamet rekryteras under bildandet av leveransen, det inkluderar intresserade från det allmänna projektteamet. Sedan skrivs en uppdateringsplan med de ansvariga för varje steg, och teamet rapporterar allt eftersom det fortskrider. Alla lagmedlemmar är utbytbara. Som en del av teamet har vi även en backup-utvecklare, men han behöver nästan aldrig koppla upp sig.
Teknik
I teknikdiagrammet är några punkter framhävda, men under dem finns ett gäng tekniker - du skulle kunna publicera en hel bok med deras beskrivningar. Så vi lyfter fram det mest intressanta.
Infrastruktur som kod
Nu kommer förmodligen inte detta koncept att förvåna någon, men tidigare lämnade beskrivningarna av infrastrukturer mycket att önska. , testmiljöerna var unika, de var omhuldade och omhuldade, dammpartiklar blåstes av dem.
Nuförtiden är ingen rädd för att experimentera. Det finns grundläggande bilder av virtuella maskiner, det finns färdiga scenarier för att distribuera miljöer. Alla mallar och skript lagras i ett versionskontrollsystem och uppdateras omgående. Tidigare, när det var nödvändigt att leverera ett paket till en monter, uppstod en konfigurationslucka. Nu behöver du bara lägga till en rad i källkoden.
Förutom infrastrukturskript och pipelines, används Documentation as a Code-metoden också för dokumentation. Tack vare detta är det enkelt att koppla nya personer till projektet, introducera dem i systemet utifrån de funktioner som beskrivs till exempel i testplanen och även återanvända testfall.
Kontinuerlig leverans och övervakning
om DevOps pratade vi om hur vi valt verktyg för att implementera kontinuerlig leverans och övervakning. Ofta finns det inget behov av att skriva om något - det räcker med att använda tidigare skrivna skript, bygga korrekt integration mellan komponenter och skapa en gemensam hanteringskonsol. Och alla processer kan startas med en knapp eller ett schema.
På engelska finns olika begrepp, Continuous Delivery och Continuous Deployment. Båda kan översättas som "kontinuerlig leverans", men det finns faktiskt en liten skillnad mellan dem. I vårt projekt för det tekniska dokumentflödet hos ett distribuerat energibolag används snarare Leverans - när installation för produktion sker på kommando. I distribution sker installationen automatiskt. Kontinuerlig leverans i detta projekt har i allmänhet blivit central del av DevOps.
I allmänhet, genom att samla in vissa parametrar, kan du tydligt förstå varför DevOps-metoder är användbara. Och förmedla detta till ledningen, som verkligen älskar siffror. Det totala antalet lanseringar, exekveringstiden för skriptstadier, andelen framgångsrika lanseringar - allt detta påverkar direkt allas favorittid till marknaden, det vill säga tiden från en commit till versionskontrollsystemet till att en version släpps på en produktionsmiljö. Med implementeringen av de nödvändiga verktygen får ingenjörer värdefulla indikatorer per post, och projektledaren ser dem på instrumentpanelen. På så sätt kan du omedelbart utvärdera fördelarna med nya verktyg. Och du kan prova dem på din infrastruktur med hjälp av DevOps-designern.
Vem kommer att behöva vår ?
Låt oss inte låtsas: till en början blev han användbar för oss. Som vi redan har sagt behöver du prata samma språk med kunden och med hjälp av DevOps-designern kan vi snabbt skissa på grunden för ett sådant samtal. Affärsspecialister kommer själva att kunna bedöma vad de behöver och därmed utvecklas snabbare. Vi försökte göra designern så detaljerad som möjligt, lägga till en massa beskrivningar så att alla användare förstår vad han väljer.
Formgivarens format låter dig ta hänsyn till företagets befintliga utveckling inom byggprocesser och automation. Det finns ingen anledning att riva allt och bygga om det om man bara kan välja lösningar som integrerar väl med befintliga processer och som helt enkelt kan fylla luckorna.
Kanske har din utveckling redan flyttat till en högre nivå och vårt verktyg kommer att verka för "kaptens". Men vi finner det användbart för oss själva och hoppas att det kommer att vara användbart för några av läsarna. Vi påminner dig till konstruktören - om något, du får diagrammet omedelbart efter att ha angett de ursprungliga uppgifterna. Vi är tacksamma för din feedback och tillägg.
Källa: will.com