We hebben ooit een elektronisch documentbeheersysteem geleverd aan een klant in één vestiging. En dan naar een ander object. En nog een. En op de vierde, en op de vijfde. We lieten ons zo meeslepen dat we 10 verspreide objecten bereikten. Het pakte krachtig uit... vooral toen we de veranderingen doorvoerden. Als onderdeel van de levering aan het productiecircuit vergden 5 scenario's van het testsysteem uiteindelijk 10 uur en 6-7 medewerkers. Dergelijke kosten dwongen ons om zo zelden mogelijk te leveren. Na drie jaar in bedrijf te zijn geweest, konden we het niet uithouden en besloten we het project op te fleuren met een snufje DevOps.
Nu vinden alle tests plaats in 3 uur en doen er 3 mensen mee: een ingenieur en twee testers. De verbeteringen zijn duidelijk in cijfers uitgedrukt en leiden tot een verlaging van de geliefde TTM. Onze ervaring is dat er veel meer klanten zijn die kunnen profiteren van DevOps dan degenen die er zelfs maar van afweten. Om DevOps dichter bij de mensen te brengen, hebben we daarom een eenvoudige constructor ontwikkeld, waarover we in dit bericht meer in detail zullen praten.
Laten we het u nu in meer detail vertellen. Eén energiebedrijf implementeert een technisch documentbeheersysteem bij tien grote faciliteiten. Het is niet eenvoudig om zonder DevOps door projecten van deze omvang te navigeren, omdat een groot deel van de handmatige arbeid het werk enorm vertraagt en ook de kwaliteit vermindert - al het handmatige werk is vol fouten. Aan de andere kant zijn er projecten waarbij er maar één installatie is, maar alles automatisch, constant en zonder fouten moet werken - bijvoorbeeld dezelfde documentstroomsystemen in grote monolithische organisaties. Anders zal iemand de instellingen handmatig uitvoeren, de implementatie-instructies vergeten - en als gevolg daarvan zullen in de productie de instellingen verloren gaan en zal alles instorten.
Meestal werken wij met de klant op basis van een contract, en in dit geval lopen onze belangen enigszins uiteen. De klant bekijkt het project strikt binnen het budget en de technische specificaties. Het kan lastig zijn om hem de voordelen uit te leggen van verschillende DevOps-praktijken die niet in de technische specificaties zijn opgenomen. Wat als hij geïnteresseerd is in snelle releases met toegevoegde bedrijfswaarde, of in het bouwen van een automatiseringspijplijn?
Helaas, als je met vooraf goedgekeurde kosten werkt, wordt deze interesse niet altijd gevonden. In onze praktijk was er een geval waarin we de ontwikkeling van een gewetenloze en onzorgvuldige aannemer moesten oppakken. Het was verschrikkelijk: er waren geen up-to-date broncodes, de codebasis van hetzelfde systeem was verschillend op verschillende installaties, de documentatie ontbrak gedeeltelijk en gedeeltelijk van verschrikkelijke kwaliteit. Uiteraard had de klant geen controle over de broncode, assemblage, releases, etc.
Tot nu toe kent niet iedereen DevOps, maar zodra we het hebben over de voordelen ervan, over echte besparingen op hulpbronnen, lichten de ogen van alle klanten op. Het aantal verzoeken waarin DevOps is opgenomen, neemt dus in de loop van de tijd toe. Om gemakkelijk dezelfde taal met klanten te kunnen spreken, moeten we hier snel bedrijfsproblemen en DevOps-praktijken met elkaar verbinden, zodat een geschikte ontwikkelingspijplijn kan worden opgebouwd.
We hebben dus aan de ene kant een aantal problemen, aan de andere kant hebben we DevOps-kennis, -praktijken en -tools. Waarom deel je de ervaring niet met iedereen?
Een DevOps-constructor maken
Agile heeft zijn eigen manifest. ITIL heeft zijn eigen methodologie. DevOps heeft minder geluk: het heeft nog geen sjablonen en standaarden verworven. Hoewel de volwassenheid van bedrijven bepalen op basis van een beoordeling van hun ontwikkeling en operationele praktijken.
Gelukkig kwam het bekende bedrijf Gartner in 2014 en analyseerde de belangrijkste DevOps-praktijken en de relaties daartussen. Op basis hiervan heb ik een infographic uitgebracht:
Wij hebben het als basis voor ons genomen . Elk van de vier gebieden beschikt over een reeks tools: we hebben ze verzameld in een database, de meest populaire geïdentificeerd, integratiepunten geïdentificeerd en geschikte optimalisatiemechanismen. In totaal bleek het 36 praktijken en 115 instrumenten, waarvan een kwart open source of vrije software is. Vervolgens zullen we vertellen wat we op elk gebied hebben bereikt en, als voorbeeld, hoe dit is geïmplementeerd in het project voor het creëren van technisch documentbeheer, waarmee we deze post zijn begonnen.
processen
In het beruchte EDMS-project werd het technische documentatiebeheersysteem bij elk van de 10 objecten volgens hetzelfde schema ingezet. De installatie omvat 4 servers: databaseserver, applicatieserver, full-text indexering en contentbeheer. In de installatie opereren ze binnen één knooppunt en bevinden ze zich in het datacenter bij de faciliteiten. Alle objecten verschillen enigszins qua infrastructuur, maar dit interfereert niet met de mondiale interactie.
Eerst hebben we, volgens DevOps-praktijken, de infrastructuur lokaal geautomatiseerd, daarna brachten we de levering naar het testcircuit en vervolgens naar het product van de klant. Elk proces werd stap voor stap uitgewerkt. De omgevingsinstellingen worden vastgelegd in het broncodesysteem, waarbij er rekening mee wordt gehouden dat de distributiekit is samengesteld voor automatische updates. In het geval van configuratiewijzigingen hoeven ingenieurs alleen maar de juiste wijzigingen in het versiebeheersysteem aan te brengen - en dan zal de automatische update zonder problemen plaatsvinden.
Dankzij deze aanpak is het testproces sterk vereenvoudigd. Voorheen had het project testers die niets anders deden dan de stands handmatig bijwerken. Nu komen ze gewoon, kijken of alles werkt en doen meer nuttige dingen. Elke update wordt automatisch getest - van het oppervlakteniveau tot de automatisering van bedrijfsscenario's. De resultaten worden als aparte rapporten in TestRail geplaatst.
Cultuur
Continu experimenteren kan het beste worden uitgelegd aan de hand van het voorbeeld van testontwerp. Een systeem testen dat nog niet bestaat, is creatief werk. Bij het schrijven van een testplan moet u begrijpen hoe u correct kunt testen en welke takken u moet volgen. En zoek ook een balans tussen tijd en budget om het optimale aantal controles te bepalen. Het is belangrijk om precies de noodzakelijke tests te kiezen, na te denken over hoe de gebruiker met het systeem zal omgaan, rekening te houden met de omgeving en mogelijke externe factoren. Zonder voortdurend experimenteren is het onmogelijk.
Nu over de cultuur van interactie. Voorheen waren er twee tegengestelde partijen: ingenieurs en ontwikkelaars. De ontwikkelaars zeiden: “Het maakt ons niet uit hoe het gelanceerd zal worden. Jullie zijn ingenieurs, jullie zijn slim, zorgen ervoor dat het storingsvrij werkt". De ingenieurs antwoordden: 'Jullie ontwikkelaars zijn te onzorgvuldig. Laten we voorzichtiger zijn en we zullen uw releases minder vaak afspelen. Want elke keer dat je ons een lekkende code geeft, is het voor ons niet duidelijk hoe we moeten communiceren.”. Dit is een cultureel interactievraagstuk dat vanuit DevOps-perspectief anders is gestructureerd. Hier maken zowel engineers als ontwikkelaars deel uit van één team dat gefocust is op voortdurend veranderende, maar tegelijkertijd betrouwbare software.
Binnen hetzelfde team zijn specialisten vastbesloten elkaar te helpen. Zoals het vroeger was? Er waren bijvoorbeeld dikke implementatie-instructies in de maak, zo'n vijftig pagina's lang. De ingenieur las het, begreep iets niet, vloekte en vroeg de ontwikkelaar om drie uur 's ochtends om commentaar. De ontwikkelaar gaf commentaar en vloekte ook - uiteindelijk was niemand blij. Bovendien waren er natuurlijk enkele fouten, omdat je niet alles in de instructies kunt onthouden. En nu schrijft de engineer samen met de ontwikkelaar een script voor de geautomatiseerde implementatie van de applicatiesoftware-infrastructuur. En ze spreken elkaar vrijwel in dezelfde taal.
Mensen
De grootte van het team wordt bepaald door de omvang van de update. Het team wordt tijdens de totstandkoming van de oplevering samengesteld en bestaat uit geïnteresseerden uit het algemene projectteam. Vervolgens wordt er een updateplan geschreven met de verantwoordelijken voor elke fase, en het team rapporteert naarmate de voortgang vordert. Alle teamleden zijn uitwisselbaar. Als onderdeel van het team hebben we ook een back-upontwikkelaar, maar die hoeft vrijwel nooit verbinding te maken.
Technologie
In het technologiediagram zijn een paar punten gemarkeerd, maar daaronder bevindt zich een aantal technologieën. Je zou een heel boek met hun beschrijvingen kunnen publiceren. Dus we zullen de meest interessante benadrukken.
Infrastructuur als code
Nu zal dit concept waarschijnlijk niemand verbazen, maar voorheen lieten de beschrijvingen van infrastructuren veel te wensen over. De testomgevingen waren uniek, ze werden gekoesterd en gekoesterd, er werden stofdeeltjes van afgeblazen.
Tegenwoordig is niemand bang om te experimenteren. Er zijn basisimages van virtuele machines, er zijn kant-en-klare scenario's voor het inzetten van omgevingen. Alle sjablonen en scripts worden opgeslagen in een versiebeheersysteem en worden onmiddellijk bijgewerkt. Als het voorheen nodig was om een pakket op een stand af te leveren, ontstond er een configuratiekloof. Nu hoeft u alleen maar een regel aan de broncode toe te voegen.
Naast infrastructuurscripts en pipelines wordt ook de Documentation as a Code-aanpak gebruikt voor documentatie. Hierdoor is het eenvoudig om nieuwe mensen aan het project te koppelen, hen kennis te laten maken met het systeem op basis van de functies die bijvoorbeeld in het testplan zijn beschreven, en ook testgevallen opnieuw te gebruiken.
Continue levering en monitoring
over DevOps spraken we over hoe we tools selecteerden voor het implementeren van continue levering en monitoring. Vaak is het niet nodig om iets te herschrijven - het volstaat om eerder geschreven scripts te gebruiken, de integratie tussen componenten correct op te bouwen en een gemeenschappelijke beheerconsole te creëren. En alle processen kunnen met één knop of schema worden gestart.
In het Engels zijn er verschillende concepten, Continuous Delivery en Continuous Deployment. Beide kunnen worden vertaald als “continue levering”, maar in feite is er een klein verschil tussen beide. In ons project voor de technische documentenstroom van een gedistribueerd energiebedrijf wordt liever Levering gebruikt - wanneer de installatie voor productie op commando plaatsvindt. In Implementatie vindt de installatie automatisch plaats. Continuous Delivery is in dit project over het algemeen geworden centraal onderdeel van DevOps.
Over het algemeen kun je door het verzamelen van bepaalde parameters duidelijk begrijpen waarom DevOps-praktijken nuttig zijn. En breng dit over op het management, dat echt van cijfers houdt. Het totale aantal lanceringen, de uitvoeringstijd van scriptfasen, het aandeel succesvolle lanceringen - dit alles heeft rechtstreeks invloed op ieders favoriete time-to-market, dat wil zeggen de tijd vanaf een commit aan het versiebeheersysteem tot de release van een versie op een productieomgeving. Met de implementatie van de benodigde tools ontvangen engineers waardevolle indicatoren per mail en ziet de projectmanager deze op het dashboard. Zo kunt u meteen de voordelen van nieuwe tools evalueren. En u kunt ze op uw infrastructuur uitproberen met behulp van de DevOps-ontwerper.
Wie heeft onze nodig ?
Laten we niet doen alsof: om te beginnen werd hij nuttig voor ons. Zoals we al zeiden, moet je met de klant dezelfde taal spreken en met de hulp van de DevOps-designer kunnen we snel de basis voor zo’n gesprek schetsen. Bedrijfsspecialisten kunnen zelf inschatten wat ze nodig hebben en zich daardoor sneller ontwikkelen. We hebben geprobeerd de ontwerper zo gedetailleerd mogelijk te maken door een aantal beschrijvingen toe te voegen, zodat elke gebruiker begrijpt wat hij kiest.
Door de indeling van de ontwerper kun je rekening houden met de bestaande ontwikkelingen van het bedrijf op het gebied van bouwprocessen en automatisering. Het is niet nodig om alles af te breken en opnieuw op te bouwen, als je maar kunt kiezen voor oplossingen die goed integreren met bestaande processen en die eenvoudigweg de gaten kunnen opvullen.
Misschien is jouw ontwikkeling al naar een hoger niveau gegaan en lijkt onze tool te “captain’s”. Maar we vinden het nuttig voor onszelf en hopen dat het nuttig zal zijn voor sommige lezers. Wij herinneren u eraan aan de ontwerper - u ontvangt het diagram eventueel onmiddellijk na het invoeren van de initiële gegevens. Wij zijn dankbaar voor uw feedback en aanvullingen.
Bron: www.habr.com