DevOps-tools

Tijdens de ontdekkingsfase onderzoekt en definieert een DevOps-team de scope van een project. Dit omvat voornamelijk activiteiten zoals gebruikersonderzoek, het stellen van doelen en het definiëren van succes.

Tools zoals Mural en Miro stellen het hele softwareteam in staat om ideeën te verzamelen en onderzoek te doen. Jira Product Discovery ordent deze informatie in bruikbare invoer en geeft prioriteit aan acties voor ontwikkelingsteams. Bij het stellen van prioriteiten moet je ook rekening houden met je backlog van gebruikersfeedback.

Product Discovery is de allereerste activiteit in het ontwerpen van een product, en daarop wordt dan de besluitvorming gebaseerd. Tijdens de Product Discovery kun je alle cruciale informatie over eventuele gebruikersproblemen verzamelen en daar vervolgens oplossingen voor bieden.

We raden aan om naar tools te zoeken die "asynchroon brainstormen" aanmoedigen. Het is belangrijk dat iedereen alles kan delen en erop kan reageren: ideeën, strategieën, doelen, vereisten, roadmaps en documentatie.

Productie-identieke omgevingen voor ontwikkeling

Hoewel Puppet en Chef vooral de activiteiten ten goede komen, gebruiken ontwikkelaars open source-tools zoals Kubernetes en Docker om individuele ontwikkelomgevingen te voorzien. Codering tegen virtuele wegwerpreplica's van productie helpt je om meer werk gedaan te krijgen.

Wanneer elk teamlid vanuit identiek ingerichte omgevingen werkt, is 'Het werkt op mijn machine!' niet meer grappig omdat het waar is (nu is het gewoon grappig).

Infrastructure as Code

Ontwikkelaars streven ernaar om modulaire applicaties te maken die in elkaar gezet kunnen worden omdat die betrouwbaarder en gemakkelijker te onderhouden zijn. Dus waarom zou je dat denken niet uitbreiden naar de IT-infrastructuur? Dit kan lastig zijn om op systemen toe te passen omdat ze altijd veranderen. Dus we gaan dat omzeilen door code te gebruiken voor provisioning.

Infrastructuur als code betekent dat herinrichting sneller gaat dan repareren — en dat het consistenter en reproduceerbaarder is. Het betekent ook dat je eenvoudig variaties van je ontwikkelomgeving kunt laten draaien met een vergelijkbare configuratie als de productie. Inrichtingscode kan worden toegepast en opnieuw worden toegepast om een server op een bekende basislijn te plaatsen. Deze kan worden opgeslagen in versiebeheer. Deze kan worden getest, geïntegreerd in CI (continue integratie) en peer-reviewed.

Wanneer institutionele kennis, nou ja, gecodificeerd is in code, vervaagt de behoefte aan geleide boeken en interne documentatie. Wat naar voren komt zijn herhaalbare processen en betrouwbare systemen.

Bronbeheer en codering voor samenwerking

Het is belangrijk om de broncode te beheren. Met bronbesturingstools kun je de code in verschillende ketens opslaan, zodat je elke wijziging kunt zien en gemakkelijker kunt samenwerken door deze wijzigingen te delen. In plaats van te wachten op boards om wijzigingen goed te keuren voordat je kunt implementeren naar productie, kun je de codekwaliteit en doorvoer verbeteren met peer reviews die worden gedaan via pull requests.

Wat zijn pull requests, vraag je? Pull requests vertellen je team over wijzigingen die je hebt gepusht naar een development branch in je repository. Je team kan vervolgens de voorgestelde wijzigingen bekijken en wijzigingen bespreken voordat je ze in de hoofdcoderegel integreert. Pull requests verhogen de kwaliteit van de software, wat resulteert in minder bugs/incidenten, wat de operationele kosten verlaagt en resulteert in een snellere ontwikkeling.

Bronbesturingstools moeten worden geïntegreerd met andere tools, zodat je de verschillende onderdelen van de ontwikkeling en levering van code kunt verbinden. Hierdoor kun je weten of de code van de functie in productie is. Als er zich een incident voordoet, kan de code worden opgehaald om licht te werpen op het incident.

Continue integratie is de werkwijze waarbij code meerdere keren per dag in een gedeelde repository wordt gezet en deze elke keer wordt getest. Op die manier detecteer je problemen automatisch en vroegtijdig, repareer je ze wanneer ze het gemakkelijkst te repareren zijn en introduceer je zo snel mogelijk nieuwe functies voor je gebruikers.

Codereview door middel van pull requests vereist branches en is helemaal in de mode. De DevOps North Star is een workflow die resulteert in minder en snellere branches en de strengheid van de test handhaaft zonder in te boeten aan ontwikkelingssnelheid.

Zoek tools die je tests automatisch toepassen op ontwikkelingsbranches en je de mogelijkheid geven om naar de hoofdbranch te pushen wanneer branchbuilds succesvol zijn. Daarnaast krijg je continue feedback via realtime chatwaarschuwingen van je team dankzij een eenvoudige integratie.

Ontdek hoe Bitbucket Pipelines je helpt je code te automatiseren, van test tot productie.

Geautomatiseerd testen

Testtools omvatten vele behoeften en mogelijkheden, waaronder verkennend testen, testbeheer en orkestratie. Voor de DevOps-toolchain is automatisering echter een essentiële functie. Geautomatiseerd testen loont zich in de loop der tijd door je ontwikkelings- en testcycli op de lange termijn te versnellen. En in een DevOps-omgeving is het om nog een reden belangrijk: bewustwording.

Testautomatisering kan de kwaliteit van de software verhogen en risico's verminderen door dit vroeg en vaak te doen. Ontwikkelingsteams kunnen herhaaldelijk geautomatiseerde tests uitvoeren, die verschillende gebieden bestrijken, zoals UI-testen, beveiligingsscans of load testing. Ze leveren ook rapporten en trendgrafieken op die helpen bij het identificeren van risicovolle gebieden.

Risico hoort bij softwareontwikkeling, maar je kunt niet verzachten wat je niet kunt verwachten. Doe je operationele team een plezier en laat ze samen met je onder de motorkap gluren. Zoek naar tools die wallboards ondersteunen en laat iedereen die betrokken is bij het project commentaar geven op specifieke build- of implementatieresultaten. Bonuspunten voor tools die het gemakkelijk maken om Operations te betrekken bij blitztesten en verkennend testen.

Implementatiedashboards

Een van de meest stressvolle onderdelen van software leveren is om alle informatie over de verandering, tests en implementatie voor een aanstaande release op één plek te krijgen. Het laatste wat iemand nodig heeft voor een release is een lange vergadering om te rapporteren over de status. Dit is waar release-dashboards van pas komen.

Zoek naar tools met één dashboard dat is geïntegreerd met je codeopslagplaats en implementatietools. Zoek iets dat je volledig zicht geeft op branches, builds, pull requests en implementatiewaarschuwingen op één plek.

Geautomatiseerde implementatie

Er is geen magisch recept voor geautomatiseerde implementatie dat geschikt is voor elke toepassing en IT-omgeving. Maar het omzetten van het runbook van het werk naar een cmd-uitvoerbaar script met Ruby of bash is een gebruikelijke manier om te starten. Goede technische praktijken zijn van vitaal belang. Gebruik variabelen om hostnamen te bepalen — het bijhouden van unieke scripts of code voor elke omgeving is niet leuk (en mist toch de helft van het punt). Maak hulpprogramma's of scripts om dubbele code te voorkomen. En peer review je scripts om ze goed te controleren.

Probeer eerst implementaties te automatiseren naar je omgeving op het laagste niveau, waar je die automatisering het vaakst gebruikt, en repliceer dat vervolgens helemaal tot aan de productie. Op zijn minst markeert deze oefening de verschillen tussen je omgevingen en genereert hij een lijst met taken om ze te standaardiseren. Bovendien vermindert standaardisering door middel van automatisering de 'serverdrift' binnen en tussen omgevingen.

Incidenten, wijzigingen en probleemopsporing

Het belangrijkste aspect om samenwerking tussen DevOps-teams mogelijk te maken is ervoor te zorgen dat ze hetzelfde werk bekijken. Wat gebeurt er als er incidenten worden gemeld? Zijn ze gekoppeld en herleidbaar naar softwareproblemen? Wanneer er wijzigingen worden aangebracht, worden ze dan gekoppeld aan releases?

Niets blokkeert Dev's samenwerking met Ops meer dan incidenten en softwareontwikkelingsprojecten die bijgehouden worden in verschillende systemen. Zoek naar tools die incidenten, veanderingen, problemen en softwareprojecten op één platform bewaren, zodat je problemen sneller kunt identificeren en oplossen.

Monitoring van prestaties toepassingen en server

Er zijn twee soorten monitoring die geautomatiseerd moeten worden: servermonitoring en monitoring van de prestaties van toepassingen.

Handmatig een vakje afvinken of je API halen met een test is prima voor spot-checks. Maar om de trends en de algehele gezondheid van je toepassing (en omgevingen) te begrijpen, heb je software nodig die 24/7 luistert en gegevens opneemt. Voortdurende observatie is een belangrijke mogelijkheid voor succesvolle DevOps-teams.

Zoek naar tools die kunnen worden geïntegreerd met je groepschatclient, zodat waarschuwingen rechtstreeks naar de ruimte van je team gaan, of een speciale ruimte voor incidenten.

Klanten vertellen je al of je het juiste hebt gebouwd — je hoeft alleen maar te luisteren. Continue feedback omvat zowel de cultuur als de processen om regelmatig feedback te verzamelen, en tools om conclusies op te maken uit de feedback. Continue feedbackpraktijken omvatten het verzamelen en beoordelen van NPS-gegevens, verloop-enquêtes, bugrapporten, ondersteuningstickets en zelfs tweets. In een DevOps-cultuur heeft iedereen in het productteam toegang tot gebruikersreacties omdat ze alles helpen, van releaseplanning tot verkennende testsessies.

Zoek naar toepassingen die je chattool integreren met je favoriete enquêteplatform voor feedback in NPS-stijl. Twitter en/of Facebook kunnen ook worden geïntegreerd met chat voor realtime feedback. Voor een diepere kijk op de feedback van sociale media, is het de moeite waard om te investeren in een beheerplatform voor sociale media dat rapporten kan ophalen met behulp van historische gegevens.

Het analyseren en opnemen van feedback kan het gevoel geven dat het het tempo van de ontwikkeling op korte termijn vertraagt, maar het is op de lange termijn efficiënter dan nieuwe functies releasen die niemand wil.

Bij Atlassian geloven we in het belang van een DevOps-toolchain die integreert met de tools die ontwikkelings- en operationele teams graag gebruiken. Daarom hebben we ons DevOps-platform gebouwd om te integreren met meer dan 171 toonaangevende externe leveranciers, zodat je de beste beslissingen kunt nemen over de tools die je gebruikt. Omdat DevOps niet bij één leverancier gekocht kan worden, maar gebouwd moet worden.

Probeer de gratis DevOps-oplossing van Atlassian om aan de slag te gaan.