streamalism.org

1. Overzicht

In dit artikel zullen we de basisprincipes van DevOps-principes en -praktijken begrijpen. We zullen zien waarom dit relevant en nuttig is bij softwareontwikkeling. We zullen ook begrijpen hoe we DevOps zinvol kunnen toepassen en welke tools er zijn om ons op deze reis te helpen.

2. Historische context

We zullen DevOps zoals het er nu uitziet niet kunnen waarderen zonder een beetje terug te kijken in de geschiedenis. De vroege dagen van softwareontwikkeling werden vooral gekenmerkt door wat we watervalmethodologie noemen. Wat dit effectief betekent, is dat software werd achtereenvolgens geconceptualiseerd, ontworpen, ontwikkeld, getest en gedistribueerd.

Elke stap was zo gedetailleerd mogelijk, zoals teruggaan was erg duur. Wat dit in feite betekende, was een veel langere wachttijd tussen denken en handelen. Dit was echter niet zo'n probleem, aangezien het technologielandschap veel minder vluchtig was en de verstoringen veel te verspreid waren.

Interessant genoeg duurde dit model niet lang. Naarmate het tempo van de technologie veranderde en verstoringen vaak voorkwamen, begonnen bedrijven de hitte te voelen. Zij hadden nodig nieuwe ideeën om sneller te testen. Dit betekende snellere veranderingen in alle aspecten van het bedrijf, inclusief software.

Dit gaf geboorte aan een hele nieuwe wereld van softwareontwikkelingsmethodologieën die losjes worden gezien onder de paraplu van Agile. Het agile manifest beschrijft een reeks principes die gevolgd moeten worden softwarelevering in kleine stappen met een snellere feedbacklus. Er zijn verschillende agile frameworks zoals Scrum en Kanban in de praktijk.

3. Wat is DevOps?

We hebben gezien dat incrementele ontwikkeling met snellere feedback tegenwoordig de hoeksteen van de softwarelevering is geworden. Maar hoe bereiken we dat? Hoewel traditionele agile-methodologieën ons tot een redelijk punt brengen, is het nog steeds niet ideaal.

Agile methodologieën blijven zichzelf verfijnen terwijl ze er voortdurend naar streven om silo's te doorbreken.

Traditioneel hadden we altijd verschillende teams die verantwoordelijk waren voor het ontwikkelen en leveren van software. Deze teams opereerden vaak in hun silo's. Dit vertaalde zich effectief in een veel langere feedbackcyclus, wat we niet willen met agile methodieken.

Er is dus niet veel redenering voor nodig om te begrijpen dat goed geïntegreerde, multifunctionele agile teams veel beter geschikt zijn om hun doelstellingen te behalen. DevOps is de praktijk die communicatie, samenwerking, integratie en automatisering tussen softwareontwikkelings- en operationele teams stimuleert. Dit stelt ons beter in staat om incrementele ontwikkeling te realiseren met snellere feedback.

In het volgende diagram wordt een mogelijke workflow voor het oefenen van DevOps uitgelegd:

Hoewel we de details van deze stappen later in de tutorial zullen bespreken, laten we enkele van de belangrijkste principes van DevOps begrijpen:

• Waardegerichte benadering (zoals gerealiseerd door eindgebruiker)
• Samenwerkingscultuur (met effectieve communicatie, processen en tools)
• Automatisering van processen (om de efficiëntie te verhogen en fouten te verminderen)
• Meetbare resultaten (om af te meten aan de doelen)
• Continue feedback (met de neiging om snel te verbeteren)

4. Hoe start je de reis?

Hoewel de theorie eenvoudig en aantrekkelijk is, zijn de echte uitdagingen het zinvol oefenen van DevOps. Zoals we tot nu toe hebben gezien, DevOps gaat vooral over mensen, in plaats van teams.

Gemeenschappelijke doelstellingen, effectieve communicatie en functieoverschrijdende vaardigheden zijn de kenmerken van dergelijke teams. Aangezien een groot deel van deze verandering cultureel is, verloopt het vaak traag en niet zonder wrijving.

4.1. Motivatie

Alleen omdat er een populaire praktijk is, maakt het niet noodzakelijkerwijs geschikt voor ons. We moeten onze motivatie voor elke verschuiving begrijpen, zeker als we een omslag naar agile maken. Haar nuttig om uiteen te zetten door de doelen te definiëren die we willen bereiken.

De doelen van DevOps in elke organisatie zijn afhankelijk van de ambitie, cultuur en volwassenheid van die organisatie. Hier zijn enkele van de meest voorkomende DevOps-doelen:

• Betere ervaring voor eindgebruikers
• Snellere time-to-market
• Verbeterde gemiddelde tijd tot herstel

4.2. Adoptie

Onthoud dat DevOps geen eindtoestand is, maar een continu proces van verbetering om de doelen te bereiken. Daarom moet iedereen in het team streven om belemmeringen te identificeren en ze snel weg te nemen. Hier zijn een paar activiteiten die ons op weg kunnen helpen:

• Begrijp duidelijk de huidige stand van zaken in de productiecyclus
• Verzamel enkele van de voor de hand liggende knelpunten en gebruik statistieken om feitelijke beslissingen te nemen
• Geef prioriteit aan de knelpunten die de meeste waarde toevoegen wanneer ze worden verwijderd
• Definieer een iteratief plan om incrementeel waarde te leveren voor items met prioriteit
• Volg de korte cycli van Develop-Deploy-Measure om de doelen te bereiken

5. DevOps-praktijken

Er zijn verschillende praktijken die moeten worden gevolgd, maar het idee zou geen enkele als gouden standaard moeten gebruiken. We moeten elke praktijk zorgvuldig onderzoeken op de achtergrond van onze staat en doelstellingen, en dan weloverwogen beslissingen nemen. Bijna alle praktijken hebben echter de neiging om zich zoveel mogelijk te concentreren op het automatiseren van processen.

5.1. Agile planning

Agile planning is de praktijk om het werk in korte stappen te definiëren. Hoewel het einddoel duidelijk moet zijn, is het niet nodig om de hele applicatie vooraf te definiëren en uit te werken. De sleutel hier is prioriteit geven aan werk op basis van de waarde die het kan opleveren.

Vervolgens moet het worden verbroken in een iteratie van korte maar functionerende stappen.

5.2. Infrastructure-as-Code (IaC)

Dit is de praktijk van het beheren en inrichten van infrastructuur via machineleesbare configuratiebestanden. We beheren deze configuraties ook in een versiebeheersysteem zoals we onze codebase beheren. Er zijn veel domeinspecifieke talen beschikbaar om deze configuratiebestanden declaratief te maken.

5.3. Test automatisering

Het testen van software is van oudsher een handmatige inspanning die vaak in silo's wordt uitgevoerd. Dit gaat niet goed samen met agile principes. Daarom is het absoluut noodzakelijk dat we het proberen om softwaretests op alle niveaus te automatiseren, zoals het testen van eenheden, functionele tests, beveiligingstests en prestatietests.

5.4. Continue integratie (CI)

Continue integratie is het praktijk om werkende code vaker in kleine stappen samen te voegen tot een gedeelde repository. Meestal worden er geautomatiseerde builds en controles uitgevoerd op deze gedeelde repository om ons zo snel mogelijk op de hoogte te stellen van code-onderbrekingen.

5.5. Continue levering / implementatie (cd)

Continue levering is het praktijk om software in kleine stappen vrij te geven zodra deze alle controles heeft doorstaan. Dit wordt vaak samen met Continuous Integration toegepast en kan profiteren van een geautomatiseerd vrijgavemechanisme (ook wel Continuous Deployment genoemd).

5.6. Voortdurende monitoring

Monitoring - misschien wel het centrum van DevOps - maakt snellere feedbackloops mogelijk. Identificeren de juiste metrics om alle aspecten van de software te monitoren, inclusief de infrastructuur, is cruciaal. Het hebben van de juiste statistieken, gekoppeld aan realtime en effectieve analyses, kan helpen bij het sneller identificeren en oplossen van problemen. Bovendien wordt het direct meegenomen in de agile planning.

Deze lijst is verre van compleet en evolueert voortdurend. Teams die DevOps beoefenen, zoeken voortdurend naar betere manieren om hun doelen te bereiken. Enkele van de andere praktijken die het vermelden waard zijn, zijn Containerization, Cloud-Native Development en Microservices, om er maar een paar te noemen.

6. Tools of the Trade

Geen enkele discussie over DevOps kan compleet zijn zonder over de tools te praten. Dit is een gebied waar de afgelopen jaren een explosie heeft plaatsgevonden. Mogelijk is er een nieuwe tool beschikbaar tegen de tijd dat we deze tutorial hebben gelezen! Hoewel dit verleidelijk en overweldigend is, is voorzichtigheid geboden.

We moeten onze DevOps-reis niet beginnen met tools als eerste in ons hoofd. Wij moeten onze doelen, mensen (cultuur) en praktijken onderzoeken en vaststellen voordat we de juiste tools vinden. Om daar duidelijk over te zijn, laten we eens kijken wat enkele van de beproefde tools zijn die voor ons beschikbaar zijn.

6.1. Planning

Zoals we hebben gezien, begint een volwassen DevOps altijd met agile planning. Hoewel duidelijk over de doelstellingen, is het alleen nodig om prioriteiten te stellen en werk te definiëren voor enkele korte iteraties. De feedback van deze vroege iteraties is van onschatbare waarde bij het vormgeven van de toekomstige en de volledige software uiteindelijk. Een effectief hulpmiddel hier zou ons helpen dit proces gemakkelijk uit te voeren.

Jira is een best beoordeeld probleemopsporingsproduct, ontwikkeld door Atlassian. Het heeft veel ingebouwde agile planning- en monitoringtools. Het is grotendeels een commercieel product dat we ofwel on-premise kunnen draaien of als gehoste applicatie kunnen gebruiken.

6.2. Ontwikkeling

Het idee achter agile is om sneller prototypen te maken en feedback te krijgen over de daadwerkelijke software. Ontwikkelaars moeten wijzigingen aanbrengen en sneller samenvoegen tot een gedeelde versie van de software. Het is zelfs nog belangrijker dat de communicatie tussen teamleden vloeiend en snel verloopt.

Laten we eens kijken naar enkele van de alomtegenwoordige tools in dit domein.

Git is een gedistribueerd versiebeheersysteem. Het is redelijk populair en er zijn talloze gehoste services die git-repositories en functies met toegevoegde waarde bieden. Oorspronkelijk ontwikkeld door Linus Torvalds, maakt het de samenwerking tussen softwareontwikkelaars best gemakkelijk.

Confluence is een samenwerkingstool ontwikkeld door Atlassian. Samenwerking is de sleutel tot succes voor elk agile team. De feitelijke semantiek van samenwerking is behoorlijk contextueel, maar een tool die een naadloze inspanning levert, is niettemin van onschatbare waarde. Confluence past precies op deze plek. Bovendien integreert het goed met Jira!

Slack is een instant messaging-platform ontwikkeld door Slack Technologies. Zoals we hebben besproken, behendig teams moeten kunnen samenwerken en communiceren, bij voorkeur in realtime. Behalve instant messaging biedt Slack vele manieren om te communiceren met een enkele gebruiker of een groep gebruikers - en het kan goed worden geïntegreerd met andere tools zoals Jira en GitHub!

6.3. Integratie

Wijzigingen die door ontwikkelaars zijn samengevoegd, moeten continu worden gecontroleerd op naleving. Wat compliance inhoudt, is specifiek voor het team en de toepassing. Het is echter gebruikelijk om statische en dynamische code-analyse, evenals functionele en niet-functionele metrische metingen, te zien als componenten van compliance.

Laten we kort kijken naar een aantal populaire integratietools.

Jenkins is een aantrekkelijke, open-source en gratis automatiseringsserver. Het is al jaren in de branche aanwezig en is voldoende gerijpt om een ​​breed spectrum van automatiseringsdoeleinden te ondersteunen. Het biedt een declaratieve manier om een ​​automatiseringsroutine te definiëren en een verscheidenheid aan manieren om deze automatisch of handmatig te activeren. Bovendien heeft het een rijke set plug-ins die verschillende extra functies bieden om krachtige automatiseringspijplijnen te creëren.

SonarQube is een open-source platform voor continue inspectie ontwikkeld door SonarSource. SonarQube heeft een uitgebreide set regels voor statische analyse voor veel programmeertalen. Dit helpt codegeuren zo vroeg mogelijk te detecteren. Bovendien biedt SonarQube een dashboard dat andere statistieken kan integreren, zoals codedekking, codecomplexiteit en nog veel meer. En het werkt goed met Jenkins Server.

6.4. Levering

Het is belangrijk om snel wijzigingen en nieuwe functies aan software door te geven. Zodra we hebben vastgesteld dat de wijzigingen die in de repository zijn samengevoegd, voldoen aan onze standaarden en beleid, zouden we deze snel aan de eindgebruikers moeten kunnen leveren. Dit helpt ons feedback te verzamelen en de software beter vorm te geven.

Er zijn hier verschillende tools die ons kunnen helpen om sommige aspecten van de levering te automatiseren tot het punt waarop we continue implementatie bereiken.

Docker is een veelgebruikte tool om elk type applicatie snel in een container te plaatsen. Het maakt gebruik van virtualisatie op OS-niveau om software te isoleren in pakketten die containers worden genoemd. Containerisatie heeft een onmiddellijk voordeel in termen van betrouwbaardere softwarelevering. Docker Containers praten met elkaar via welomschreven kanalen. Bovendien is dit vrij licht in vergelijking met andere manieren van isolatie, zoals virtuele machines.

Chef / Puppet / Ansible zijn tools voor configuratiebeheer. Zoals we weten, is een daadwerkelijk actief exemplaar van een softwareapplicatie een combinatie van de codebase-build en de bijbehorende configuraties. En hoewel de codebase-build vaak onveranderlijk is in verschillende omgevingen, zijn configuraties dat niet. Dit is waar we hebben een tool voor configuratiebeheer nodig om onze applicatie gemakkelijk en snel te implementeren. Er zijn verschillende populaire tools in deze ruimte, elk met hun eigenaardigheden, maar Chef, Puppet en Ansible bedekken vrijwel de basis.

HashiCorp Terraform kan ons helpen met het leveren van infrastructuur, wat een vervelende en tijdrovende taak is sinds de dagen van particuliere datacenters. Maar met steeds meer adoptie van de cloud, wordt infrastructuur vaak gezien als een wegwerpbare en herhaalbare constructie. Dit kan echter alleen worden bereikt als we dat hebben een tool waarmee we declaratief eenvoudige tot complexe infrastructuur kunnen definiëren en met een klik op de knop kunnen aanmaken. Het klinkt misschien als een droomsequentie, maar Terraform probeert actief die kloof te overbruggen!

6.5. Toezicht houden

Ten slotte is het essentieel om de inzet te kunnen observeren en af ​​te meten aan de doelstellingen. Er kunnen een groot aantal statistieken zijn die we uit systemen en applicaties kunnen verzamelen. Deze omvatten enkele van de bedrijfsstatistieken die specifiek zijn voor onze applicatie.

Het idee hier is om deze statistieken in bijna realtime te kunnen verzamelen, beheren, opslaan en analyseren. Er zijn verschillende nieuwe producten, zowel open source als commercieel, die in deze ruimte beschikbaar zijn.

Elastic-Logstash-Kibana (ELK) is een stapel van drie open-sourceprojecten - Elasticsearch, Logstash en Kibana. Elasticsearch is een zeer schaalbare zoek- en analyse-engine. Logstash biedt ons een gegevensverwerkingspijplijn aan de serverzijde die gegevens uit een breed scala aan bronnen kan verbruiken. Ten slotte helpt Kibana ons deze gegevens te visualiseren. Samen kan deze stapel zijn gebruikt om gegevens zoals logboeken van alle applicaties samen te voegen en deze in realtime te analyseren.

Prometheus is een open-source tool voor systeembewaking en -waarschuwing oorspronkelijk ontwikkeld door SoundCloud. Het wordt geleverd met een multidimensionaal gegevensmodel, een flexibele zoektaal en kan tijdreeksgegevens ophalen via HTTP. Grafana is een andere open-source analyse- en monitoringoplossing dat werkt met verschillende databases. Samen kunnen Prometheus en Grafana dat wel geef ons een real-time greep op vrijwel elke statistiek die onze systemen kunnen produceren.

7. DevOps-extensies (of zijn ze echt!)

We hebben gezien dat DevOp in wezen een voortdurende inspanning is om belemmeringen voor snellere en iteratieve op waarde gebaseerde levering van software weg te nemen. Nu is een van de onmiddellijke conclusies dat er hier geen eindtoestand kan zijn.

Wat mensen beseften als wrijving tussen ontwikkelingsteams en operationele teams, is niet de enige wrijving. Het doorbreken van silo's binnen een organisatie om de samenwerking te vergroten staat centraal. Nu begonnen de mensen dat al snel te beseffen soortgelijke wrijvingen bestaan ​​tussen ontwikkel- en testteams en tussen ontwikkelingsteams en beveiligingsteams. Veel traditionele opstellingen hebben toegewijde beveiligings- en prestatieteams.

Het volledige potentieel van DevOps kan pas worden gerealiseerd als we bijna alle grenzen tussen teams kunnen doorbreken en ze kunnen helpen veel efficiënter samen te werken. Dit inherent betekent teams als testen, beveiliging en prestaties in de plooi brengen.

De verwarring zit grotendeels in de nomenclatuur. DevOps laat ons begrijpen dat het vooral om ontwikkelings- en operationele teams gaat. Daarom zijn er in de loop van de tijd nieuwe termen ontstaan ​​die ook andere teams omvatten. Maar grotendeels is het gewoon DevOps die effectiever wordt gerealiseerd!

7.1. DevTestOps

De hoeksteen van DevOps is het leveren van hoogwaardige software in kleine stappen en vaker. De nadruk op kwaliteit heeft hier veel aspecten. In zekere zin gaan we er vaak van uit dat de DevOps-praktijken die we toepassen ons hierbij zullen helpen. En het is ook waar dat veel van de praktijken die we eerder bespraken, gericht zijn op het te allen tijde garanderen van hoge kwaliteit.

Maar functioneel testen van software heeft een veel bredere reikwijdte. Heel vaak hebben we de neiging om de hogere-orde testen, zoals end-to-end-testen, tegen het einde van de softwarelevering te houden. Wat nog belangrijker is, is dat dit vaak de verantwoordelijkheid is van een apart team dat zich laat in het proces betrekt. Dit is waar dingen beginnen af ​​te wijken van de DevOps-principes.

Wat we liever zouden moeten doen, is integreer softwaretests, op alle niveaus, vanaf het allereerste begin. Vanaf de planningsfase moet softwaretesting als een integraal aspect van de levering worden beschouwd. Bovendien zou hetzelfde team verantwoordelijk moeten zijn voor het ontwikkelen en testen van de software. Dit is wat de praktijk van DevTestOps algemeen bekend staat als. Dit wordt vaak ook wel continu testen en naar links verschuiven genoemd.

7.2. DevSecOps

Beveiliging is een integraal onderdeel van elke softwareontwikkeling en heeft een deel van de complexiteit. Dit betekent vaak dat we een apart team van beveiligingsspecialisten hebben met wie we een beroep doen op het moment dat we klaar zijn om het product te verzenden. De kwetsbaarheden die ze in dit stadium identificeren, kunnen kostbaar zijn om op te lossen. Dit sluit weer niet goed aan bij de principes van DevOps.

Tegen die tijd zouden we al de oplossing moeten hebben die we nodig hebben om toe te passen, en dat is ook wat we zouden moeten doen breng de veiligheidsproblemen en het personeel vroeg in het spel aan. We moeten teams motiveren om in elke fase na te denken over beveiliging. Beveiliging is ongetwijfeld een zeer gespecialiseerd domein en daarom moeten we mogelijk een specialist binnen het team inschakelen. Maar het idee hier is om vanaf het begin enkele van de beste praktijken in overweging te nemen.

Terwijl we verder gaan, zijn er Er zijn verschillende tools beschikbaar die het scannen op een groot aantal kwetsbaarheden kunnen automatiseren. We kunnen dit ook aansluiten op onze continue integratiecycli om snelle feedback te krijgen! Nu kunnen we niet alles in de continue integratie integreren, omdat we het licht moeten houden, maar er kunnen altijd andere periodieke scans afzonderlijk worden uitgevoerd.

8. Conclusie

In dit artikel hebben we de basisprincipes van DevOps-principes, -praktijken en -tools doorgenomen die beschikbaar zijn voor gebruik. We begrepen de context waarin DevOps relevant is en de redenen waarom het voor ons van nut kan zijn. We hebben ook kort besproken waar we moeten beginnen met het adopteren van DevOps.

Verder hebben we enkele van de populaire praktijken en hulpmiddelen besproken die we tijdens deze reis kunnen gebruiken. We begrepen ook enkele van de andere populaire termen rond DevOps, zoals DevTestOps en DevSecOps.

Ten slotte moeten we begrijpen dat DevOps geen eindtoestand is, maar eerder een reis die misschien nooit zal eindigen! Maar het leuke hier is de reis zelf. Al die tijd mogen we onze doelen nooit uit het oog verliezen en moeten we ons concentreren op de belangrijkste principes. Het is vrij gemakkelijk om te vallen voor de glans van een populaire tool of term in de branche. Maar we moeten altijd onthouden dat alles alleen nuttig is als het ons helpt om op efficiëntere wijze waarde aan ons publiek te leveren.