Als uw bedrijf alleen DevOps- of CI/CD-tools implementeert, kan het nuttig voor u zijn om kennis te maken met de meest voorkomende fouten, zodat u ze niet herhaalt en op iemand anders zijn hark stapt.
Team het artikel vertaald .
Onwil om cultuur en processen te veranderen
Kijkend naar het cyclusdiagram , is het duidelijk dat in DevOps-praktijken testen een continu werk is, een fundamenteel onderdeel van elke individuele implementatie.
DevOps eindeloze cyclusdiagram
Testen en kwaliteitsborging tijdens ontwikkeling en levering is een essentieel onderdeel van alles wat ontwikkelaars doen. Dit vereist een mentaliteitsverandering om testen in elke taak op te nemen.
Testen wordt onderdeel van het dagelijkse werk van elk teamlid. De overstap naar continu testen is niet eenvoudig, daar moet je op voorbereid zijn.
Gebrek aan feedback
De effectiviteit van DevOps is afhankelijk van constante feedback. Continu verbeteren is niet mogelijk als er geen ruimte is voor samenwerking en communicatie.
Bedrijven die geen retrospectieve bijeenkomsten organiseren, vinden het moeilijk om een cultuur van continue feedback in CI/CD te implementeren. Aan het einde van elke iteratie worden retrospectieve bijeenkomsten gehouden, waar groepsleden bespreken wat er goed ging en wat er fout ging. Terugblikbijeenkomsten vormen de basis van Scrum/Agile, maar zijn ook essentieel voor DevOps.
Dit komt omdat retrospectieve bijeenkomsten de gewoonte bijbrengen om feedback en meningen uit te wisselen. Een van de belangrijkste momenten bij de start is het organiseren van terugkerende retromeetings zodat deze begrijpelijk en vertrouwd worden voor het hele team.
Als het gaat om softwarekwaliteit, zijn alle teamleden verantwoordelijk voor het onderhoud ervan. Ontwikkelaars kunnen bijvoorbeeld zowel unittests als code schrijven met testbaarheid in het achterhoofd, waardoor risico's vanaf het begin worden beperkt.
Een gemakkelijke manier om de veranderende perceptie van testen weer te geven, is door testers geen QA te noemen, maar softwaretester of kwaliteitsingenieur. Deze wijziging lijkt misschien te simpel of zelfs dom. Maar iemand een "software quality assurance specialist" noemen, geeft een verkeerd beeld van wie verantwoordelijk is voor de productkwaliteit. In Agile-, CI/CD- en DevOps-praktijken is iedereen verantwoordelijk voor de softwarekwaliteit.
Een ander belangrijk punt is begrijpen wat kwaliteit betekent voor het hele team en elk van zijn leden, organisatie, belanghebbenden.
Misverstand van fase voltooiing
Als kwaliteit een continu en gedeeld proces is, is een gemeenschappelijk begrip van de voltooiing van een fase nodig. Hoe te begrijpen dat het podium voorbij is? Wat gebeurt er wanneer een mijlpaal wordt gemarkeerd als voltooid op een Trello-bord of ander kanban-bord?
Het bepalen van een voltooide mijlpaal (DoD) is een krachtige tool in de context van CD DevOps/CI. Het helpt om de kwaliteitsnormen van wat en hoe het team bouwt beter te begrijpen.
Het ontwikkelteam moet beslissen wat "Gereed" betekent. Ze moeten gaan zitten en een lijst maken van de kenmerken waaraan in elke fase moet worden voldaan, zodat deze als volledig kan worden beschouwd.
DoD maakt het proces transparanter en vergemakkelijkt de implementatie van CI/CD, als het voor alle teamleden duidelijk is en onderling overeengekomen.
Gebrek aan realistische, duidelijk omschreven doelen
Dit is een van de meest geciteerde tips, maar het is voor herhaling vatbaar. Om elke serieuze onderneming te laten slagen, inclusief het implementeren van CI/CD of DevOps, moet u realistische doelen stellen en de prestaties daaraan afmeten. Wat probeer je te bereiken met CI/CD? Maakt het snellere releases met betere kwaliteit mogelijk?
Alle gestelde doelen moeten niet alleen transparant en realistisch zijn, maar ook consistent zijn met de huidige activiteiten van het bedrijf. Hoe vaak hebben uw klanten bijvoorbeeld nieuwe patches of versies nodig? Het is niet nodig om processen te overbelasten en sneller vrij te geven als er geen extra voordeel voor gebruikers is.
Ook hoeft u niet altijd zowel CD als CI te implementeren. Sterk gereguleerde bedrijven zoals banken en medische klinieken mogen bijvoorbeeld alleen met CI werken.
CI is een goed startpunt voor elk bedrijf dat DevOps implementeert. Wanneer het in een bedrijf wordt geïmplementeerd, veranderen de benaderingen van softwarelevering aanzienlijk. Als je CI eenmaal onder de knie hebt, kun je nadenken over het verbeteren van het hele proces, het verhogen van de uitrolsnelheid en andere wijzigingen.
Voor veel organisaties is één CI voldoende en dient CD alleen te worden geïmplementeerd als het waarde toevoegt.
Gebrek aan relevante dashboards en statistieken
Nadat je doelen hebt gesteld, kan het ontwikkelteam een dashboard maken om KPI's te meten. Voorafgaand aan de ontwikkeling is het de moeite waard om de parameters die zullen worden gecontroleerd te evalueren.
Verschillende rapporten en toepassingen zijn nuttig voor verschillende teamleden. Scrummasters zijn meer bezig met status en bereik. Terwijl het senior management mogelijk geïnteresseerd is in de mate van burn-out van specialisten.
Sommige teams gebruiken ook dashboards met rode, gele en groene indicatoren om de status van CI/CD te beoordelen, om te begrijpen of ze alles goed doen of dat er een fout is opgetreden. Rood betekent dat je aandacht moet besteden aan wat er gebeurt.
Als dashboards echter niet gestandaardiseerd zijn, kunnen ze misleidend zijn. Analyseer welke gegevens iedereen nodig heeft en maak vervolgens een gestandaardiseerde beschrijving van wat het betekent. Ontdek wat logischer is voor uw belanghebbenden: afbeeldingen, tekst of cijfers.
Gebrek aan handmatige tests
Testautomatisering legt de basis voor een goede CI/CD-pijplijn. Maar geautomatiseerd testen in alle stadia betekent niet dat u geen handmatig testen moet doen.
Om een efficiënte 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 te overwegen om handmatige testinspanningen in de pijplijn te integreren. Zodra het handmatig testen van enkele testcases is voltooid, kunt u doorgaan naar de implementatiefase.
Probeer geen tests te verbeteren
Een effectieve CI/CD-pijplijn vereist toegang tot de juiste tools, of het nu gaat om testbeheer of integratie en voortdurende monitoring.
Het creëren van een sterke, kwaliteitsgerichte cultuur beoogt , bewaak de klantervaring na implementatie en volg verbeteringen.
Hier zijn enkele praktische tips die u gemakkelijk kunt implementeren:
- Zorg ervoor dat de tests gemakkelijk te schrijven zijn en flexibel genoeg om niet te breken wanneer de code opnieuw wordt gecodeerd.
- Ontwikkelteams moeten worden opgenomen in het testproces - bekijk een lijst met gebruikersproblemen en verzoeken die belangrijk zijn om te testen tijdens CI-pijplijnen.
- Je hebt misschien geen volledige testdekking, maar zorg er altijd voor dat de stromen die belangrijk zijn voor UX en klantervaring worden getest.
Last but not least punt
De overgang naar CI/CD wordt meestal van onderop geïnitieerd, maar uiteindelijk is het een transformatie die de deelname van management, tijd en middelen van het bedrijf vereist. CI / CD is immers een set van vaardigheden, processen, tools en culturele herstructurering, dergelijke veranderingen kunnen alleen systematisch worden doorgevoerd.
Wat nog meer te lezen over het onderwerp:
- .
- .
- .
Bron: www.habr.com