Delen via

Uw softwareontwikkeling moderniseren met continue integratie

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 wijzigingen in de code aanbrengen, deze wijzigingen naar een codeopslagplaats pushen en vrijwel onmiddellijk feedback krijgen over de kwaliteit, de testdekking en geïntroduceerde bugs. Met dit proces kunt u sneller werken, met meer vertrouwen en minder risico.

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.

Het continue integratieproces begint wanneer een ingenieur een GitHub-pull-aanvraag maakt om het CI-systeem aan te geven dat codewijzigingen klaar zijn voor integratie. Idealiter valideert het integratieproces de code aan de hand van verschillende basislijnen en tests. Vervolgens geeft het feedback aan de aanvragende technicus 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 sneller software van hoge kwaliteit te leveren door de volgende acties uit te voeren:

  • Voer geautomatiseerde tests uit op de code om vroegtijdige detectie van wijzigingen die fouten veroorzaken mogelijk te maken.
  • 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 naar verwachting werkt.
  • Geef snel feedback over gedetecteerde problemen.
  • Produceer, indien van toepassing, implementeerbare assets of pakketten met de bijgewerkte code.

Terminologie

Voordat u begint met het implementeren van continue integratie, moet u vertrouwd raken met deze belangrijke termen.

Termijn Definitie
Artefact Een implementeerbare uitvoer van het buildproces, zoals gecompileerde code, containerinstallatiekopieën of implementatiepakketten.
Geautomatiseerde test Een test die automatisch wordt uitgevoerd als onderdeel van de CI-pijplijn om de codekwaliteit te valideren en problemen te detecteren zonder handmatige tussenkomst.
Bouwen Het proces dat broncode compileert, tests uitvoert en artefacten produceert voor implementatie.
Buildagent Een zelf-hostende of in de cloud gehoste rekenresource waarmee de taken en bewerkingen in een CI-pijplijn worden uitgevoerd.
Continue Integratie (CI) Een praktijk die broncodebeheersystemen integreert met geautomatiseerde pijplijnen om automatisch codewijzigingen te bouwen, testen en valideren.
CI-pijplijn Een geautomatiseerde werkstroom waarmee codewijzigingen worden gebouwd, getest en gevalideerd wanneer ontwikkelaars zich doorvoeren in broncodebeheer.
Integratietest Een test waarmee wordt gevalideerd hoe verschillende onderdelen of services samenwerken, vaak uitgebreider dan eenheidstests.
Nachtbouw Een geplande build die met regelmatige tussenpozen (meestal 's nachts) wordt uitgevoerd om langer lopende testsuites uit te voeren, zoals integratie- en UI-tests.
Pull-aanvraag Een aanvraag voor het samenvoegen van codewijzigingen van de ene vertakking in een andere. Hiermee wordt de CI-pijplijn geactiveerd om de voorgestelde wijzigingen vóór de integratie te valideren.
Releasebuild Een uitgebreide build met compilatie, tests, documentatie, nalevingsrapporten en ondertekening. Produceert de uiteindelijke versie voor productie-implementatie.
Broncodebeheer Een systeem waarmee wijzigingen in code in de loop van de tijd worden bijgehouden en beheerd. Voorbeelden hiervan zijn Git, Azure-opslagplaatsen en GitHub.
Statusbadge Een visuele indicator (meestal een afbeelding) die de huidige status van builds of tests weergeeft, vaak weergegeven in de documentatie van de opslagplaats.
Testgestuurde ontwikkeling (TDD) Een ontwikkelpraktijk waarbij ontwikkelaars tests schrijven voordat ze de code schrijven die aan deze tests voldoet.
Eenheidstest Een test die afzonderlijke functies of onderdelen in isolatie valideert om ervoor te zorgen dat ze zich gedragen zoals verwacht.

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 op pull-aanvragen te geven.

Veel oplossingen, zoals Azure Pipelines of GitHub Actions, bieden de mogelijkheden van continue integratiepijplijnen.

Pijplijnen integreren met broncodebeheer

De integratie van uw continue integratiepijplijn met uw broncodebeheersysteem is essentieel om snelle, selfservice codebijdragen mogelijk te maken.

De CI-pijplijn wordt uitgevoerd op basis van een nieuw aangemaakte pull request. De pijplijn omvat alle tests, beveiligingsevaluaties en andere controles. CI-testresultaten verschijnen direct in de pull-aanvraag, waardoor vrijwel realtime feedback over de kwaliteit mogelijk is.

Een andere populaire werkwijze is het bouwen van kleine rapporten of badges die in broncodebeheer kunnen worden gepresenteerd om de huidige build-statussen zichtbaar te maken.

Op 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 verschijnt in de pull-aanvraag.

Schermopname van een Azure DevOps-statusbadge in een GitHub-opslagplaats.

Geautomatiseerde tests opnemen

Een belangrijk element van continue integratie is het voortdurend bouwen en testen van code terwijl ontwikkelaars codebijdragen leveren. Het testen van pull-aanvragen wanneer ze worden gemaakt, geeft snelle feedback dat de commit geen brekende veranderingen heeft geïntroduceerd. Het voordeel is dat de tests in de continue integratiepijplijn dezelfde tests kunnen zijn die worden uitgevoerd tijdens testgestuurde ontwikkeling.

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.

Schermopname van Azure DevOps-pijplijntests 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 tot een verbetering van de wijziging die ervoor heeft gezorgd dat de tests zijn mislukt.

Buildstatus publiceren

Veel ontwikkelaars laten zien dat hun codekwaliteit hoog is door een statusbadge in hun opslagplaats weer te geven. Op de volgende afbeelding ziet u een Azure Pipelines-badge die wordt weergegeven op het README-bestand van een opensourceproject op GitHub.

Schermopname van een Azure Pipelines-badge in een README-bestand op GitHub.

Bouwtijden optimaliseren

Als u snellere builds wilt uitvoeren, kunt u het volgende doen:

  • Kies agents die voldoen aan uw prestatievereisten: maak uw builds sneller door de juiste buildmachines te selecteren. Snelle machines kunnen het verschil maken tussen uren en minuten. Als uw pijplijnen zich in Azure Pipelines bevinden, kunt u uw taken uitvoeren met behulp van een door Microsoft gehoste agent. Wanneer u door Microsoft gehoste agents gebruikt, worden onderhoud en upgrades voor u geregeld. Raadpleeg door Microsoft gehoste agents voor meer informatie.

  • Optimaliseer de locatie van de buildserver: wanneer u uw code bouwt, worden gegevens via de kabel verzonden. Invoer voor de builds wordt opgehaald uit een opslagplaats voor broncodebeheer en de artefactopslagplaats. De uitvoer van het buildproces moet worden gekopieerd, inclusief de gecompileerde artefacten, testrapporten, resultaten van codedekking en foutopsporingssymbolen. Het is belangrijk dat deze kopieeracties snel worden uitgevoerd. Als u uw eigen buildserver gebruikt, moet u ervoor zorgen dat de buildserver zich in de buurt van de bronnen en een doellocatie bevindt. Snelle uploads en downloads kunnen de totale buildtijd verminderen.

  • Buildservers uitschalen: Een enkele buildserver kan voldoende zijn voor een klein product. Naarmate de grootte en het bereik van het product en het aantal teams dat aan het product werkt toeneemt, is één server mogelijk niet voldoende. Schaal uw infrastructuur horizontaal over meerdere machines wanneer u de limiet bereikt. Zie Agentpools maken en beheren voor meer informatie.

  • De build optimaliseren:

    • Voeg parallelle taken toe om het buildproces te versnellen. Zie Configureren en betalen voor parallelle taken voor meer informatie.

    • Schakel parallelle testsuiteuitvoeringen in, waardoor vaak veel tijd wordt bespaard, met name bij het uitvoeren van integratie- en UI-tests. Raadpleeg Tests parallel uitvoeren voor elke testrunner voor meer informatie.

    • Gebruik het idee van een vermenigvuldiger, waar u uw builds kunt uitschalen via meerdere buildagents. Zie voor meer informatie Taken specificeren in uw pijplijn.

    • Overweeg om integratie-, UI- en smoke tests te verplaatsen naar een release-pijplijn. Het overstappen naar een releasepijplijn verbetert de snelheid van het bouwen en de snelheid van de feedbackloop.

    • Publiceer de buildartefacten naar een oplossing voor pakketbeheer, zoals NuGet of Maven. Als u publiceert naar een oplossing voor pakketbeheer, kunt u uw buildartefact eenvoudiger opnieuw gebruiken.

Buildtypen implementeren om aan uw werkstromen te voldoen

Uw organisatie kan ervoor kiezen om verschillende soorten builds te maken om de buildtijden te optimaliseren. Mogelijke builds zijn:

  • Ci-build (Continue integratie): het doel van deze build is om ervoor te zorgen dat code wordt gecompileerd en eenheidstests worden uitgevoerd. Deze build wordt geactiveerd bij elke doorvoering. Het fungeert als de hartslag van het project en geeft het team direct kwaliteitsfeedback. Zie Gebeurtenissen opgeven die pijplijnen activeren voor meer informatie.

  • Nightly build: Het doel van een nachtelijke build is niet alleen om de code te compileren, maar ook om ervoor te zorgen dat grotere testsuites die inefficiënt zijn, regelmatig worden uitgevoerd voor elke build. Deze tests omvatten meestal integratie, UI of rooktests. Zie Planningen configureren voor pijplijnen voor meer informatie.

  • Release-build: Naast het compileren en uitvoeren van tests, compileert deze build ook de API-documentatie, nalevingsrapporten, ondertekening van code en andere stappen die niet telkens nodig zijn wanneer de code wordt gebouwd. Deze build biedt de gouden kopie die naar de releasepipeline wordt gepusht om uiteindelijk in de productieomgeving te implementeren.

De typen builds die uw organisatie nodig heeft, zijn afhankelijk van factoren, waaronder de volwassenheid van uw team en organisatie, het soort product waaraan u werkt en uw implementatiestrategie.

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:

  • Last updated on