De DevOps-methodologie: Principles for Success | StackPulse

De DevOps-methodologie voegt twee gebieden samen-softwareontwikkeling en informatietechnologie (IT)-operaties. Het primaire doel van de DevOps-methodologie is een snelle productrelease, die wordt bereikt door het gebruik van automatisering, communicatie en een continue workflow.

De belangrijkste kernprincipes van DevOps zijn: cross-training, samenwerking, voortdurende verbetering, verantwoordelijkheid, transparantie en automatisering. DevOps-teams passen deze principes toe bij het creëren van een DevOps-proces, dat meestal zeven fasen omvat: plannen, coderen, bouwen, testen, leveren, implementeren en bewaken.

In dit artikel leert u:

• Wat is de DevOps-methodologie?
• 6 kern DevOps-principes
• Wat is een DevOps-proces?
• DevOps vs Agile: een vergelijking

Wat is de DevOps-methodologie?

De DevOps-methodologie is een reeks praktijken die de samenwerking van ontwikkel- en operatieteams gedurende de gehele softwareontwikkelingslevenscyclus (SDLC) vereisen. Het omvat Agile praktijken en richt zich op het afbreken van teamsilo’s, het automatiseren van handmatige taken, en het verhogen van de productiviteit door middel van continue feedback.

Wanneer DevOps-teams worden gebruikt, implementeren organisaties vaak verschillende praktijken en hulpmiddelen tegelijkertijd. Deze omvatten:

• Continue integratie / continue implementatie (CI/CD)-een set van processen die gebruik maken van automatisering om de efficiëntie, kwaliteit en snelheid in de software development lifecycle te verbeteren. CI omvat frequente, kleine wijzigingen in codebases die zo snel mogelijk worden getest en geïntegreerd. CD omvat het regelmatig vrijgeven van nieuwe code aan de productie zonder de noodzaak van handmatige updates of patches.
• Cloud-gebaseerde pijplijnen-pijplijnen zijn de toolchains die worden gebruikt om workflows zoals CI/CD uit te voeren. Vaak zijn deze toolchains opgebouwd uit services en resources die in de cloud worden gehost, waardoor cloud-native ontwikkeling mogelijk wordt en gedistribueerde teams beter worden ondersteund.
• Microservices- een architectuur die wordt gebruikt met cloud-native applicaties om een grotere schaalbaarheid, beschikbaarheid en flexibiliteit mogelijk te maken. Microservices stellen teams in staat om applicaties en pijplijnen te bouwen die losjes gekoppeld zijn en eenvoudig kunnen worden gewijzigd of bijgewerkt.
• Infrastructure as code (IaaC)-een methode waarmee teams infrastructuur kunnen leveren, configureren en beheren via software en gecodeerde definitiebestanden. Deze methode maakt de automatisering van veel infrastructuurtaken mogelijk en ondersteunt massale implementaties zonder dat er aanzienlijk meer teamresources nodig zijn.

De kernprincipes van DevOps

Bij het creëren en werken volgens een DevOps-methodologie, zijn er verschillende kernprincipes die u zou moeten overwegen om te adopteren.

Cross-training

In DevOps worden inspanningen gedaan voor cross-training van teamleden op alle processen in de SDLC. Dit betekent niet dat alle teamleden even vaardig moeten zijn, maar ze moeten wel allemaal bekend zijn met de gebruikte processen, tooling en vaardigheden.

Wanneer de kennis van teamleden elkaar op deze manier overlapt, is het voor teamleden gemakkelijker om te communiceren. Het bevordert nieuwe oplossingen omdat de leden minder “gevangen” zijn door de verwachtingen van hoe dingen moeten worden gedaan. Kruisbestuiving kan ook knelpunten door afhankelijkheid van anderen voorkomen, waardoor de productiviteit wordt verhoogd.

Samenwerking

Samenwerking en de communicatie die daarvoor nodig is, zijn belangrijke elementen van DevOps. Deze methodologie vertrouwt op teamleden om soepel samen te werken en te reageren op feedback wanneer iets niet werkt zoals verwacht. Als teamleden niet in staat zijn om samen te werken, wordt het werk silo en wordt de productiviteit beperkt door de voltooiing van fasen.

Continue verbetering

DevOps gebruikt een iteratief proces met kleine veranderingen die worden verfijnd totdat een verandering inspectiedrempels passeert. Zodra een verandering is geaccepteerd, wordt met de volgende begonnen. Deze continue verbetering wordt toegepast op alle aspecten van DevOps, waaronder productontwikkeling, pijplijnprestaties en procesefficiëntie.

Accountability

Een DevOps-model vereist accountability voor alle taken – of het nu ontwikkelingstaken of operationele taken zijn – en beide moeten evenveel eigendom zijn van alle leden van de organisatie. Dit elimineert het traditionele denken van “iemand anders probleem”, helpt ervoor te zorgen dat teams zorgvuldig zijn in hun acties, of ze nu betrekking hebben op ontwikkeling of operaties. Het helpt ook bij het opbouwen en verstevigen van relaties binnen een team, omdat alle leden een gelijke inspanning en verantwoordelijkheid verwachten.

Transparantie

Transparantie van processen, configuraties, tooling, en verwachtingen zijn allemaal belangrijk in DevOps. Zonder transparantie kunnen teams niet effectief samenwerken en blijft er een gevoel van “wij tegen zij”. Dit verhindert communicatie en maakt het moeilijk om anderen verantwoordelijk te houden. Met transparantie kunnen alle teamleden helpen bij het identificeren van eventuele problemen die zich voordoen en kunnen ze verbeteringen voorstellen in de context van het grotere geheel.

Automatisering

DevOps automatisering helpt teams het werk te stroomlijnen en te standaardiseren. Het helpt ook bij het creëren van transparantie, omdat het vereist dat procedures worden gedefinieerd en gedocumenteerd. Door vervelende of tijdrovende taken te automatiseren, kunnen DevOps-teams zich richten op werk op een hoger niveau. Deze focus kan de kwaliteit verbeteren en innovatie aanmoedigen.

Het DevOps-proces

Hoewel individuele procedures binnen het DevOps-proces kunnen variëren, volgt het algemene proces een reeks vrij uniforme stappen. Deze stappen komen voor in een cyclus en kunnen veranderen of teruglussen naar eerdere stappen, afhankelijk van feedback loops. Een DevOps-levenscyclus omvat gewoonlijk de volgende stappen:

• Plan – aan het begin van een project, sprint/iteratie, of dag, wordt het werk gepland en geprioriteerd. Dit helpt ervoor te zorgen dat alle teamleden de huidige doelstellingen begrijpen en definieert welk werk wordt verwacht.
• Code-ontwikkelaars maken en dienen codewijzigingen of -toevoegingen in die voldoen aan de taken die zijn gedefinieerd voor de huidige iteratie. Deze zijn gebaseerd op een master code base waar alle ontwikkelaars toegang toe hebben. Deze stap omvat ook code review en eventuele verduidelijkingen of aanpassingen die nodig zijn. Wanneer ingediende code niet door de testen komt, wordt het teruggestuurd naar deze stap voor aanpassing.
• Build-ingediende code wordt gecompileerd, unit getest, en verpakt. Dit is over het algemeen de eerste geautomatiseerde stap in de CI / CD pijplijn. Als een build mislukt, wordt feedback gestuurd naar de ontwikkelaar, en de ingediende wijziging wordt afgewezen. Als de build succesvol is, wordt deze doorgegeven voor aanvullend testen.
• Test-succesvolle builds worden door een reeks van tests geleid om de functionaliteit, kwaliteit en vaak ook de veiligheid te waarborgen. Idealiter worden de snelste of meest kritische tests het eerst uitgevoerd. Op deze manier, als een test faalt, kan de oorspronkelijke codewijziging zo snel mogelijk worden teruggestuurd met feedback, en wordt er geen moeite verspild. Als alle tests slagen, wordt de build doorgegeven aan de oplevering, en worden de wijzigingen samengevoegd in de master code branch. Dit zorgt ervoor dat alle ontwikkelaars blijven werken vanuit dezelfde basis.
• Opleveren-de laatste build die geslaagd is, wordt behouden en bewaard voor uitrol.
• Deploy-een build kan worden uitgerold naar een testomgeving voor extra testen, zoals gebruikers acceptatie. Of, het kan worden geleverd aan staging-of productie-omgevingen voor release.
• Monitor – na de release worden de versies gemonitord om eventuele problemen te identificeren die zijn gemist en om gebruiksgegevens te verzamelen die kunnen worden toegepast op toekomstige verbeteringen. U kunt meer leren over DevOps-monitoring in ons artikel: DevOps Monitoring: The Abridged Guide.

DevOps vs. Agile: What’s the Difference and How Are They Related?

Wanneer we het hebben over de DevOps-methodologie, wordt deze vaak geassocieerd met Agile. Dit is logisch als je bedenkt dat veel DevOps-teams Agile-praktijken gebruiken. Ook zijn beide methodologieën gericht op het verbeteren van snelheid, efficiency en kwaliteit. Desondanks verschillen de methodologieën, en de een vereist niet noodzakelijkerwijs de ander.

Communicatie

In Agile-methodologieën ligt de nadruk op communicatie tussen teams en het betrekken van klanten bij het gehele projectproces. Ook komt de meeste feedback in Agile-processen van klanten.

In DevOps is de communicatie gecentreerd op ontwikkelaars en operations. Feedback van klanten speelt een rol in de planningsstappen en opleveringsstappen, maar is over het algemeen niet aanwezig tijdens tussenliggende stappen. In plaats daarvan vertrouwen teams op feedback van tooling en andere teamleden om het werk te sturen.

Teamstructuur

Zowel Agile als DevOps geven prioriteit aan het delen van vaardigheden en cross-training. Echter, DevOps heeft de neiging om deze vaardigheden meer toe te passen op communicatie en samenwerking dan op verantwoordelijkheid. In DevOps-teams zijn ontwikkelaars verantwoordelijk voor het maken van code, en test- en operationele teams (DevOps-teams genoemd) zijn verantwoordelijk voor pijplijnbeheer, omgevingsconfiguratie en implementatie.

In tegenstelling hiermee vervagen in Agile-teams vaak de grenzen tussen verantwoordelijkheden. Binnen een Agile-team wordt iedereen aangemoedigd om alle taken op zich te nemen die nodig zijn en zijn rollen minder gescheiden. Als gevolg hiervan heeft Agile de neiging om beter te werken met kleinere teams, terwijl DevOps beter is in het bieden van de structuur die nodig is voor grotere teams.

Tijdplanning

Agile-methodologieën volgen een sprint of in de tijd beperkte iteratie. Meerdere sprints worden uitgevoerd totdat een project is voltooid met specifieke taken en doelen gedefinieerd in elk. Sprints en het verwachte werk worden vaak aangepast aan de output van het team.

In DevOps implementaties is het doel om altijd een opleverbaar product te hebben. Teams kunnen echter sprints of iteraties gebruiken om het werk te definiëren dat naar verwachting in een specifieke release zal gaan. Bovendien worden DevOps-teams vaak gehouden aan meer specifieke deadlines en benchmarks en hebben ze minder flexibiliteit bij het definiëren van wanneer een product klaar is.

Automatisering voor de DevOps-methodologie: Continuous Operations, Monitoring, and Feedback With StackPulse

Naarmate onze bedrijven steeds digitaler worden, wordt de betrouwbaarheid van softwarediensten die ze mogelijk maken een bedrijfskritische kwestie. Elk softwaresysteem, hoe goed ontworpen ook, zal productie-alerts hebben. Dit kunnen lokale problemen zijn die weinig tot geen invloed hebben op de eindgebruikers, of kritieke problemen die van invloed zijn op de beschikbaarheid van de dienst voor zijn gebruikers.

In beide gevallen moeten de problemen worden onderzocht, geanalyseerd en zo nodig verholpen door de betreffende eigenaren. Zonder de juiste automatisering zal het grote aantal incidenten en alerts in de meeste organisaties leiden tot:

• Negatieve productiviteitsimpact op R&D- en DevOps-teams
• “Alert-moeheid” voor eigenaren en ondersteunende teams
• Langere downtime voor productiediensten.

StackPulse is een automatiseringsplatform voor de operations-, monitoring-, en feedbackfasen van de DevOps-cyclus. Het stelt DevOps en engineering teams in staat om gecodificeerde playbooks voor deze processen te definiëren. Dit stelt uw organisatie in staat om processen op een herhaalbare en meetbare manier te automatiseren en ze zo vaak als nodig te triggeren, zonder extra handmatige arbeid.

Krijg vroegtijdige toegang tot StackPulse en probeer als een van de eersten ons DevOps / SRE-automatiseringsplatform.