Aanbevelingen voor het gebruik van continue integratie
Is van toepassing op deze controlelijst voor Azure Well-Architected Framework Operational Excellence:
| OE:04 | Optimaliseer softwareontwikkelings- en kwaliteitsgarantieprocessen door bewezen procedures voor ontwikkeling en testen te volgen. Voor duidelijke rolaanduiding kunt u procedures standaardiseren voor onderdelen zoals hulpprogramma's, broncodebeheer, patronen voor toepassingsontwerp, documentatie en stijlhandleidingen. |
|---|
Verwante handleiding: Hulpprogramma's en processen voor het standaardiseren van buildsnelheid | verbeteren
Wanneer code wordt ontwikkeld, bijgewerkt of zelfs verwijderd, met een intuïtieve en veilige methode om deze wijzigingen te integreren in de hoofdcodebranch, kunnen ontwikkelaars waarde bieden.
Als ontwikkelaar kunt u kleine codewijzigingen aanbrengen, deze wijzigingen pushen naar een codeopslagplaats en vrijwel onmiddellijk feedback krijgen over de kwaliteit, testdekking en geïntroduceerde fouten. Met dit proces kunt u sneller en met meer vertrouwen en minder risico's werken.
Continue integratie (CI) is een praktijk waarbij broncodebeheersystemen en pijplijnen voor software-implementatie zijn geïntegreerd om geautomatiseerde mechanismen voor bouwen, testen en feedback te bieden voor softwareontwikkelingsteams.
Belangrijke ontwerpstrategieën
Continue integratie is een praktijk voor softwareontwikkeling die ontwikkelaars gebruiken om software-updates te integreren in een bronbeheersysteem op regelmatige basisfrequentie.
Het proces voor continue integratie wordt gestart wanneer een technicus een GitHub-pull-aanvraag maakt om aan te geven aan het CI-systeem dat codewijzigingen gereed zijn om te worden geïntegreerd. Idealiter valideert het integratieproces de code op basis van verschillende basislijnen en tests. Vervolgens geeft het de aanvragende technicus feedback over de status van deze tests.
Als de basislijncontroles en -tests goed verlopen, produceert en faseeert het integratieproces assets die de bijgewerkte software implementeren. Deze assets omvatten gecompileerde code en containerinstallatiekopieën.
Continue integratie kan u helpen om software van hoge kwaliteit sneller te leveren door de volgende acties uit te voeren:
- Voer geautomatiseerde tests uit op basis van de code om vroegtijdige detectie van belangrijke wijzigingen te bieden.
- Voer codeanalyse uit om codestandaarden, kwaliteit en configuratie te garanderen.
- Voer nalevings- en beveiligingscontroles uit om ervoor te zorgen dat de software geen bekende beveiligingsproblemen heeft.
- Voer acceptatie- of functionele tests uit om ervoor te zorgen dat de software werkt zoals verwacht.
- Geef snel feedback over gedetecteerde problemen.
- Maak, indien van toepassing, implementeerbare assets of pakketten die de bijgewerkte code bevatten.
Continue integratie met pijplijnen automatiseren
Voor continue integratie gebruikt u softwareoplossingen om het proces te beheren, integreren en automatiseren. Een veelvoorkomende procedure is het gebruik van een pijplijn voor continue integratie.
Een pijplijn voor continue integratie omvat een stukje software (vaak in de cloud gehost) dat het volgende biedt:
- Een platform voor het uitvoeren van geautomatiseerde tests.
- Nalevingsscans.
- Berichtgeving.
- Alle andere onderdelen waaruit het continue integratieproces bestaat.
In de meeste gevallen wordt de pijplijnsoftware gekoppeld aan broncodebeheer, zodat wanneer pull-aanvragen worden gemaakt of software wordt samengevoegd in een specifieke vertakking, de pijplijn voor continue integratie wordt uitgevoerd. Integratie van broncodebeheer biedt ook de mogelijkheid om CI-feedback rechtstreeks over pull-aanvragen te geven.
Veel oplossingen, zoals Azure Pipelines of GitHub Actions, bieden de mogelijkheden van pijplijnen voor continue integratie.
Pijplijnen integreren met broncodebeheer
De integratie van uw pijplijn voor continue integratie met uw broncodebeheersysteem is essentieel voor het inschakelen van snelle, selfservicecodebijdragen.
De CI-pijplijn wordt uitgevoerd op een nieuw gemaakte pull-aanvraag. De pijplijn bevat alle tests, beveiligingsevaluaties en andere controles. CI-testresultaten worden rechtstreeks in de pull-aanvraag weergegeven om bijna realtime feedback over kwaliteit mogelijk te maken.
Een andere veelgebruikte procedure is het maken van kleine rapporten of badges die in broncodebeheer kunnen worden gepresenteerd om de huidige buildstatussen zichtbaar te maken.
In de volgende afbeelding ziet u de integratie tussen GitHub en een Azure DevOps-pijplijn. In dit voorbeeld activeert het maken van een pull-aanvraag een Azure DevOps-pijplijn. De pijplijnstatus wordt weergegeven in de pull-aanvraag.
Geautomatiseerde tests opnemen
Een belangrijk element van continue integratie is het continu bouwen en testen van code wanneer ontwikkelaars codebijdragen leveren. Het testen van pull-aanvragen wanneer ze worden gemaakt, geeft snelle feedback dat de doorvoer geen wijzigingen heeft geïntroduceerd die fouten veroorzaken. Het voordeel is dat de tests in de pijplijn voor continue integratie dezelfde tests kunnen zijn die tijdens de testgestuurde ontwikkeling worden uitgevoerd.
In het volgende codefragment ziet u een teststap van een Azure DevOps-pijplijn. De stap heeft twee taken:
- De eerste taak maakt gebruik van een populair Python-testframework om CI-tests uit te voeren. Deze tests bevinden zich in broncodebeheer naast de Python-code. De testresultaten gaan naar een bestand met de naam test-results.xml.
- De tweede taak verbruikt de testresultaten en publiceert deze als geïntegreerd rapport naar de Azure DevOps-pijplijn.
- script: |
pip3 install pytest
pytest azure-vote/azure-vote/tests/ --junitxml=junit/test-results.xml
continueOnError: true
- task: PublishTestResults@2
displayName: 'Publish Test Results'
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/test-results.xml'
failTaskOnFailedTests: true
testRunTitle: 'Python $(python.version)'
In de volgende afbeelding ziet u testresultaten die worden weergegeven in de Azure DevOps-portal.
Mislukte tests
Mislukte tests moeten een implementatie tijdelijk blokkeren en leiden tot een diepere analyse van wat er is gebeurd. Mislukte tests moeten ook leiden tot een verfijning van de tests of een verbetering van de wijziging waardoor de tests zijn mislukt.
Buildstatus publiceren
Veel ontwikkelaars laten zien dat hun codekwaliteit hoog is door een statusbadge in hun opslagplaats weer te geven. In de volgende afbeelding ziet u een Azure Pipelines-badge die wordt weergegeven in het leesmij-bestand voor een opensource-project in GitHub.
Azure-facilitering
Azure DevOps is een verzameling services waarmee u een gezamenlijke, efficiënte en consistente ontwikkelpraktijk kunt bouwen.
Azure Pipelines biedt build- en releaseservices ter ondersteuning van continue integratie en continue levering (CI/CD) van uw toepassingen.
GitHub for Actions voor Azure maakt automatisering van CI/CD-processen mogelijk. Het integreert rechtstreeks met Azure om implementaties te vereenvoudigen. U kunt werkstromen maken die elke pull-aanvraag in uw opslagplaats bouwen en testen, of die samengevoegde pull-aanvragen implementeren in productie.
Verwante koppelingen
Meer informatie over het maken van een pijplijn voor continue integratie met behulp van GitHub of Azure DevOps:
Meer informatie over het weergeven van badges in uw opslagplaatsen:
- Een azure Pipelines-statusbadge toevoegen aan uw opslagplaats
- Een gitHub-werkstroomstatusbadge toevoegen aan uw opslagplaats