Als uw bedrijf net DevOps of CI/CD-tools implementeert, kan het nuttig zijn om de meest voorkomende fouten te leren kennen, om deze niet te herhalen en niet in dezelfde valkuilen te trappen.
Opdracht vertalde het artikel .
Onvoorbereidheid op veranderende culturen en processen
Als we kijken naar de cyclische diagram , dan zien we dat testen in DevOps-praktijken een doorlopende taak is, een fundamenteel onderdeel van elke afzonderlijke uitrol.
Oneindige cyclische diagram van DevOps
Testen en kwaliteitsborging in het ontwikkelings- en leveringsproces zijn een verplicht onderdeel van alles wat ontwikkelaars doen. Dit vereist een verandering in denkwijze om testen in elke taak op te nemen.
Testen wordt een deel van het dagelijkse werk van elk teamlid. De overgang naar continue testen verloopt niet soepel, je moet hierop voorbereid zijn.
Afwezigheid van feedback
De effectiviteit van DevOps hangt af van constante feedback. Continue verbetering is onmogelijk zonder ruimte voor samenwerking en communicatie.
Bedrijven die geen retrospectieve bijeenkomsten organiseren, hebben moeite om een cultuur van continue feedback in CI/CD te implementeren. Retrospectieve bijeenkomsten worden aan het einde van elke iteratie gehouden, waarin teamleden bespreken wat goed ging en wat slecht ging. Retrospectieve bijeenkomsten zijn een fundament van Scrum/Agile, maar zijn ook noodzakelijk voor DevOps.
Dit komt omdat retrospectieve bijeenkomsten de gewoonte ontwikkelen om feedback en meningen uit te wisselen. Een van de belangrijkste zaken bij de start is het organiseren van terugkerende retro-bijeenkomsten, zodat deze duidelijk en vertrouwd worden voor het hele team.
Als het gaat om de kwaliteit van software, zijn alle teamleden verantwoordelijk voor het behouden ervan. Bijvoorbeeld, ontwikkelaars kunnen unit tests schrijven en code schrijven met testbaarheid in gedachten, waardoor risico's vanaf het begin worden verminderd.
Een van de eenvoudige manieren om de veranderde opvattingen over testen weer te geven, is door testers niet QA te noemen, maar softwaretester of kwaliteitsingenieur. Deze verandering lijkt misschien te eenvoudig of zelfs dom. Maar als iemand wordt aangeduid als 'specialist in kwaliteitsborging van software', geeft dit een verkeerd beeld van wie verantwoordelijk is voor de kwaliteit van het product. In Agile-, CI/CD- en DevOps-praktijken is iedereen verantwoordelijk voor de kwaliteit van de software.
Een ander belangrijk aspect is het begrip wat kwaliteit betekent voor het hele team en elk lid daarvan, de organisatie en de belanghebbenden.
Verkeerd begrip van de voltooiing van een fase
Als kwaliteit een continu en gezamenlijk proces is, is er een algemeen begrip van de voltooiing van een fase nodig. Hoe weet je wanneer een fase is afgerond? Wat gebeurt er wanneer een fase is gemarkeerd als voltooid op een Trello-bord of een ander kanban-bord?
De definitie van een voltooid project (DoD) is een krachtig hulpmiddel in de context van CD DevOps/CI. Het helpt om de kwaliteitsnormen van wat het team bouwt en hoe, beter te begrijpen.
Het ontwikkelingsteam moet bepalen wat 'Klaar' betekent. Ze moeten samen zitten en een lijst opstellen van kenmerken die moeten worden vervuld voor elke fase om als voltooid te worden beschouwd.
DoD maakt het proces transparanter en vergemakkelijkt de implementatie van CI/CD, mits het duidelijk is voor alle teamleden en wederzijds is afgestemd.
Het ontbreken van realistische, duidelijk gedefinieerde doelen
Dit is een van de meest geciteerde adviezen, maar het is de moeite waard om het te herhalen. Voor het succes van elke serieuze onderneming, inclusief de implementatie van CI/CD of DevOps, moeten realistische doelen worden vastgesteld en de prestaties ten opzichte daarvan worden gemeten. Wat probeer je te bereiken met CI/CD? Maakt dit het mogelijk om sneller releases uit te brengen met een betere kwaliteit?
Elke gestelde doelstelling moet niet alleen transparant en realistisch zijn, maar ook aansluiten bij de huidige activiteiten van het bedrijf. Bijvoorbeeld, hoe vaak hebben jouw klanten nieuwe bugfixes of versies nodig? Het is niet nodig om processen te overbelasten en releases sneller uit te brengen, als er geen extra voordelen voor de gebruikers zijn.
Bovendien is het niet altijd nodig om zowel CD als CI te implementeren. Bijvoorbeeld, bedrijven met een hoge mate van regulering, zoals banken en medische klinieken, kunnen alleen met CI werken.
CI is een goede startpunt voor elk bedrijf dat DevOps wil implementeren. Bij de implementatie van CI veranderen de benaderingen voor softwarelevering aanzienlijk. Zodra CI onder de knie is, kan men nadenken over het verbeteren van het gehele proces, het verhogen van de uitrolsnelheid en andere wijzigingen.
Voor veel organisaties is één CI voldoende, en CD moet alleen worden geïmplementeerd als het extra voordelen biedt.
Ontbreken van de juiste dashboards en metrics
Zodra je doelstellingen hebt vastgesteld, kan het ontwikkelteam een dashboard creëren om KPI's te meten. Het is verstandig om een beoordeling uit te voeren van de parameters die zullen worden gevolgd voordat dit dashboard wordt ontwikkeld.
Verschillende rapporten en applicaties zijn nuttig voor verschillende teamleden. Scrum Masters zijn vooral geïnteresseerd in de status en dekking. Terwijl het hogere management mogelijk meer geïnteresseerd is in de snelheid waarmee medewerkers uitvallen.
Sommige teams gebruiken ook dashboards met rode, gele en groene indicatoren om de status van CI/CD te beoordelen, zodat ze kunnen begrijpen of ze alles goed doen of dat er een fout is opgetreden. Rood betekent dat er aandacht aan de situatie moet worden besteed.
Echter, als de dashboards niet gestandaardiseerd zijn, kunnen ze misleidend zijn. Analyseer welke gegevens iedereen nodig heeft en maak daarna een gestandaardiseerde beschrijving van wat ze betekenen. Ontdek wat meer zinvol is voor belanghebbenden: grafieken, tekst of getallen.
Ontbreken van handmatige tests
Automatisering van tests legt de basis voor een goed CI/CD-pijplijn. Maar geautomatiseerd testen in alle fasen betekent niet dat je geen handmatige tests moet uitvoeren.
Om een effectieve CI/CD-pijplijn op te bouwen, zijn ook handmatige tests nodig. Er zullen altijd enkele aspecten van testen zijn die menselijke analyse vereisen.
Het is de moeite waard om na te denken over de integratie van handmatige testinspanningen in de pijplijn. Zodra handmatige tests van enkele testgevallen zijn voltooid, kun je doorgaan naar de implementatiefase.
Probeer de tests niet te verbeteren
Een effectieve CI/CD-pijplijn vereist toegang tot de juiste tools, of het nu gaat om testbeheer of integratie en constante monitoring.
Het creëren van een sterke, kwaliteitsgerichte cultuur is gericht op , monitoring van klantinteracties na implementatie en het volgen van verbeteringen.
Hier zijn enkele praktische tips die je eenvoudig kunt toepassen:
- Zorg ervoor dat tests eenvoudig te schrijven zijn en flexibel genoeg om niet te breken bij het refactoren van code.
- Ontwikkelteams moeten betrokken worden bij het testproces — ze moeten de lijst zien met gebruikersproblemen en verzoeken die belangrijk zijn om te controleren tijdens CI-pijplijnen.
- Je hoeft misschien niet volledig testdekking te hebben, maar zorg ervoor dat de stromen die belangrijk zijn voor UX en klantinteractie getest worden.
Laatste maar niet minder belangrijke punt
De overgang naar CI/CD wordt doorgaans van onder naar boven geïnitieerd, maar uiteindelijk is het een transformatie die de betrokkenheid van het management, de tijd en middelen van het bedrijf vereist. CI/CD is immers een combinatie van vaardigheden, processen, tools en een culturele herstructurering; dergelijke veranderingen kunnen alleen systematisch worden doorgevoerd.
Wat verder te lezen over dit onderwerp:
- .
- .
- .
Bron: habr.com
