Dag in het leven van een devops-ontwikkelaar: nieuwe code schrijven voor een gebruikersverhaal

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

In deze zelfstudie wordt uitgelegd hoe u en uw team optimaal kunnen profiteren van de meest recente versies van Team Foundation Version Control (TFVC) en Visual Studio om uw app te bouwen. De zelfstudie bevat voorbeelden van hoe u Visual Studio en TFVC kunt gebruiken om code uit te checken en bij te werken, werk op te schorten wanneer u wordt onderbroken, een codebeoordeling aan te vragen, uw wijzigingen in te checken en andere taken uit te voeren.

Wanneer een team Visual Studio en TFVC in gebruik neemt om hun code te beheren, stellen ze hun server- en clientcomputers in, maken ze een achterstand, plannen ze een iteratie en voltooien ze andere planning die nodig is om hun app te gaan ontwikkelen.

Ontwikkelaars controleren hun achterstand om taken te selecteren waaraan ze moeten werken. Ze schrijven eenheidstests voor de code die ze willen ontwikkelen. Normaal gesproken voeren ze de tests meerdere keren in een uur uit, schrijven ze geleidelijk meer gedetailleerde tests en schrijven ze vervolgens de code die ze doorgeeft. Ontwikkelaars bespreken vaak hun code-interfaces met collega's die de methode gebruiken die ze schrijven.

Met de hulpprogramma's van Visual Studio My Work en Code Review kunnen ontwikkelaars hun werk beheren en samenwerken met collega's.

Notitie

Visual Studio My Work en Code Review-functies zijn beschikbaar met de volgende edities:

• Visual Studio 2022: Visual Studio Community, Visual Studio Professional en Visual Studio Enterprise
• Visual Studio 2019: Visual Studio Professional en Visual Studio Enterprise

Werkitems controleren en voorbereiden om aan de slag te gaan

Het team heeft afgesproken dat u tijdens de huidige sprint werkt aan de status van de factuur evalueren, een item met de hoogste prioriteit in de productachterstand. U besluit te beginnen met wiskundige functies implementeren, een onderliggende taak van het achterstallige item met de hoogste prioriteit.

In Visual Studio Team Explorer sleept u deze taak op de pagina Mijn werk vanuit de lijst Beschikbare werkitems naar de lijst Werkvoortgang .

Uw achterstand controleren en taken voorbereiden om aan de slag te gaan

1. Als u in Team Explorer nog niet bent verbonden met het project waarin u wilt werken, maakt u verbinding met het project.

2. Selecteer Mijn werk op de startpagina.

3. Sleep op de pagina Mijn werk de taak van de lijst Beschikbare werkitems naar de sectie In voortgangswerk .

   U kunt ook de taak selecteren in de lijst Beschikbare werkitems en vervolgens Start selecteren.

Concept van incrementeel werkplan

U ontwikkelt code in een reeks kleine stappen. Elke stap duurt doorgaans niet langer dan een uur en kan maximaal 10 minuten duren. In elke stap schrijft u een nieuwe eenheidstest en wijzigt u de code die u ontwikkelt, zodat deze de nieuwe test doorstaat, naast de tests die u al hebt geschreven. Soms schrijft u de nieuwe test voordat u de code wijzigt en soms wijzigt u de code voordat u de test schrijft. Soms herstructureer je. Dat wil gezegd, u verbetert alleen de code zonder nieuwe tests toe te voegen. U wijzigt nooit een test die is geslaagd, tenzij u besluit dat deze niet juist een vereiste vertegenwoordigt.

Aan het einde van elke kleine stap voert u alle eenheidstests uit die relevant zijn voor dit gebied van de code. U beschouwt de stap pas als elke test is voltooid.

U checkt de code pas in bij Azure DevOps Server als u de hele taak hebt voltooid.

U kunt een ruw plan voor deze reeks kleine stappen opschrijven. U weet dat de exacte details en volgorde van de latere waarschijnlijk veranderen terwijl u werkt. Hier volgt de eerste lijst met stappen voor deze specifieke taak:

1. Maak testmethode stub, dat wil gezegd, alleen de handtekening van de methode.
2. Voldoen aan een specifieke typische case.
3. Test een breed scala. Zorg ervoor dat de code correct reageert op een groot bereik met waarden.
4. Uitzondering op negatief. Probleemloos omgaan met onjuiste parameters.
5. Codedekking. Zorg ervoor dat ten minste 80% van de code wordt uitgevoerd door de eenheidstests.

Sommige ontwikkelaars schrijven dit soort plannen in opmerkingen in hun testcode. Anderen onthouden hun plan. Het kan handig zijn om uw lijst met stappen te schrijven in het veld Beschrijving van het taakwerkitem. Als u tijdelijk moet overschakelen naar een urgentere taak, weet u waar u de lijst kunt vinden wanneer u terug kunt keren naar de lijst.

De eerste eenheidstest maken

Begin met het maken van een eenheidstest. Begin met de eenheidstest omdat u een voorbeeld wilt schrijven van code die gebruikmaakt van uw nieuwe klasse.

Dit is de eerste eenheidstest voor de klassebibliotheek die u test, dus u maakt een nieuw eenheidstestproject.

1. Selecteer Bestand>nieuw project.
2. Selecteer in het dialoogvenster Een nieuw project maken de pijl naast Alle talen en selecteer C#, selecteer de pijl naast Alle projecttypen en kies Testen en selecteer vervolgens MSTest Test Project.
3. Selecteer Volgende en selecteer vervolgens Maken.

Vervang in de code-editor de inhoud van UnitTest1.cs door de volgende code. In deze fase wilt u alleen laten zien hoe een van uw nieuwe methoden wordt aangeroepen:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Fabrikam.Math.UnitTest
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        // Demonstrates how to call the method.
        public void SignatureTest()
        {
            // Create an instance:
            var math = new Fabrikam.Math.LocalMath();

            // Get a value to calculate:
            double input = 0.0;

            // Call the method:
            double actualResult = math.SquareRoot(input);

            // Use the result:
            Assert.AreEqual(0.0, actualResult);
        }
    }
}

U schrijft het voorbeeld in een testmethode omdat u het voorbeeld op het moment dat u uw code schrijft, moet werken.

Een eenheidstestproject en -methoden maken

Meestal maakt u een nieuw testproject voor elk project dat wordt getest. Als er al een testproject bestaat, kunt u gewoon nieuwe testmethoden en -klassen toevoegen.

In deze zelfstudie wordt gebruikgemaakt van het Visual Studio Unit Test Framework, maar u kunt ook frameworks van andere providers gebruiken. Test Explorer werkt net zo goed met andere frameworks, mits u de juiste adapter installeert.

1. Maak een testproject met behulp van de voorgaande stappen. U kunt talen kiezen, zoals C#, F# en Visual Basic.

2. Voeg uw tests toe aan de opgegeven testklasse. Elke eenheidstest is één methode.

   • Elke eenheidstest moet worden voorafgegaan door het TestMethod kenmerk en de eenheidstestmethode mag geen parameters hebben. U kunt elke gewenste naam gebruiken voor een eenheidstestmethode:

     [TestMethod]
     public void SignatureTest()
     {...}
     

     <TestMethod()>
     Public Sub SignatureTest()
     ...
     End Sub
     

   • Elke testmethode moet een methode van de klasse aanroepen om aan te geven of deze Assert is geslaagd of mislukt. Normaal gesproken controleert u of de verwachte en werkelijke resultaten van een bewerking gelijk zijn aan:

     Assert.AreEqual(expectedResult, actualResult);
     

     Assert.AreEqual(expectedResult, actualResult)
     

   • Uw testmethoden kunnen andere gewone methoden aanroepen die niet over het TestMethod kenmerk beschikken.

   • U kunt uw tests in meer dan één klasse organiseren. Elke klasse moet worden voorafgegaan door het TestClass kenmerk.

     [TestClass]
     public class UnitTest1
     { ... }
     

     <TestClass()>
     Public Class UnitTest1
     ...
     End Class
     

Zie Schrijfeenheidtests voor C/C++ met het Microsoft Unit Testing Framework voor C++voor meer informatie over het schrijven van eenheidstests in C++.

Een stub voor de nieuwe code maken

Maak vervolgens een klassebibliotheekproject voor uw nieuwe code. Er is nu een project voor de code die wordt ontwikkeld en een project voor de eenheidstests. Voeg een projectreferentie uit het testproject toe aan de code die wordt ontwikkeld.

In het nieuwe project voegt u de nieuwe klasse en een minimale versie van de methode toe waarmee de test ten minste kan worden gebouwd. De snelste manier om dit te doen, is door een klasse en methode-stub te genereren op basis van de aanroep in de test.

public double SquareRoot(double p)
{
    throw new NotImplementedException();
}

Klassen en methoden genereren op uit tests

Maak eerst het project waaraan u de nieuwe klasse wilt toevoegen, tenzij deze al bestaat.

Een klasse genereren

1. Plaats de cursor op een voorbeeld van de klasse die u wilt genereren, LocalMathbijvoorbeeld en selecteer Snelle acties en herstructureringen.
2. Kies nieuw type genereren in het snelmenu.
3. Stel Project in het dialoogvenster Type genereren in op het klassebibliotheekproject. In dit voorbeeld is het Fabrikam.Math.

Een methode genereren

1. Plaats de cursor op een aanroep naar de methode, bijvoorbeeld SquareRoot, en selecteer Snelle acties en herstructureringen.
2. Kies 'SquareRoot' genereren in het snelmenu.

De eerste test uitvoeren

Bouw en voer de test uit. Het testresultaat toont een rode indicator Mislukt en de test wordt weergegeven onder de lijst met mislukte tests.

Breng een eenvoudige wijziging aan in de code:

public double SquareRoot(double p)
{
    return 0.0;
}

Voer de test opnieuw uit en deze wordt doorgegeven.

Eenheidstests uitvoeren

Eenheidstests uitvoeren:

• >Alle tests testen selecteren
• Als Test Explorer is geopend, kiest u Alle tests uitvoeren of uitvoeren in weergave.

Als er een test wordt weergegeven onder Mislukte tests, opent u de test, bijvoorbeeld door te dubbelklikken op de naam. Het punt waarop de test is mislukt, wordt weergegeven in de code-editor.

• Als u een volledige lijst met tests wilt zien, kiest u Alles weergeven.

• Als u de details van een testresultaat wilt bekijken, selecteert u de test in Test Explorer.

• Als u naar de code van een test wilt gaan, dubbelklikt u op de test in Test Explorer of kiest u Test openen in het snelmenu.

• Als u fouten in een test wilt opsporen, opent u het snelmenu voor een of meer tests en kiest u Debug.

• Als u tests op de achtergrond wilt uitvoeren wanneer u de oplossing bouwt, selecteert u de pijl naast het pictogram Instellingen en selecteert u Vervolgens Tests uitvoeren na build. Tests die eerder zijn mislukt, worden eerst uitgevoerd.

Akkoord gaan met de interface

U kunt samenwerken met collega's die uw onderdeel gaan gebruiken door uw scherm te delen. Een collega kan commentaar geven dat veel functies de vorige test doorstaan. Leg uit dat deze test alleen was om ervoor te zorgen dat de naam en parameters van de functie juist zijn en nu kunt u een test schrijven die de belangrijkste vereiste van deze functie vastlegt.

U werkt samen met collega's om de volgende test te schrijven:

[TestMethod]
public void QuickNonZero()
{
    // Create an instance to test:
    LocalMath math = new LocalMath();

    // Create a test input and expected value:
    var expectedResult = 4.0;
    var inputValue = expectedResult * expectedResult;

    // Run the method:
    var actualResult = math.SquareRoot(inputValue);

    // Validate the result:
    var allowableError = expectedResult/1e6;
    Assert.AreEqual(expectedResult, actualResult, allowableError,
        "{0} is not within {1} of {2}", actualResult, allowableError, expectedResult);
}

Tip

Voor deze functie gebruikt u de eerste testontwikkeling, waarin u eerst de eenheidstest schrijft voor een functie en vervolgens code schrijft die voldoet aan de test. In andere gevallen is deze praktijk niet realistisch, dus u schrijft de tests nadat u de code hebt geschreven. Maar het is erg belangrijk om eenheidstests te schrijven, ongeacht of deze vóór of na de code staan, omdat ze de code stabiel houden.

Rood, groen, herstructureren...

Volg een cyclus waarin u herhaaldelijk een test schrijft en controleer of deze mislukt, schrijf code om de test geslaagd te maken en overweeg vervolgens de code te herstructureren, waardoor de code wordt verbeterd zonder de tests te wijzigen.

Rood

Voer alle tests uit, inclusief de nieuwe test die u hebt gemaakt. Nadat u een test hebt geschreven, voert u deze altijd uit om ervoor te zorgen dat deze mislukt voordat u de code schrijft waarmee deze wordt doorgegeven. Als u bijvoorbeeld vergeet om asserties te plaatsen in een aantal tests die u schrijft, ziet u dat wanneer u het resultaat mislukt, het testresultaat correct aangeeft dat aan een vereiste is voldaan.

Een andere handige procedure is het instellen van Run Tests After Build. Met deze optie worden de tests op de achtergrond uitgevoerd telkens wanneer u de oplossing bouwt, zodat u een continu rapport hebt van de teststatus van uw code. Het is mogelijk dat u zich zorgen maakt dat Visual Studio traag reageert, maar dit gebeurt zelden.

Groen

Hiermee schrijft u uw eerste poging in de code van de methode die u ontwikkelt:

public class LocalMath
{
    public double SquareRoot(double x)
    {
        double estimate = x;
        double previousEstimate = -x;
        while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
        {
            previousEstimate = estimate;
            estimate = (estimate * estimate - x) / (2 * estimate);
        }
        return estimate;
    }

Voer de tests opnieuw uit en alle tests zijn geslaagd.

Herstructureren

Nu de code de hoofdfunctie uitvoert, bekijkt u de code om manieren te vinden om deze beter te laten presteren of om het in de toekomst gemakkelijker te wijzigen. U kunt het aantal berekeningen dat in de lus wordt uitgevoerd verminderen:

public class LocalMath
{
    public double SquareRoot(double x)
    {
        double estimate = x;
        double previousEstimate = -x;
        while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
        {
            previousEstimate = estimate; 
            estimate = (estimate + x / estimate) / 2;
            //was: estimate = (estimate * estimate - x) / (2 * estimate);
        }
        return estimate;
    }

Controleer of de tests nog steeds zijn geslaagd.

Tips

• Elke wijziging die u aanbrengt tijdens het ontwikkelen van de code, moet een herstructurering of een extensie zijn:

  • Herstructureren betekent dat u de tests niet wijzigt omdat u geen nieuwe functionaliteit toevoegt.
  • Extensie betekent het toevoegen van tests en het aanbrengen van de codewijzigingen die nodig zijn om zowel bestaande als nieuwe tests door te geven.

• Als u bestaande code bijwerkt naar vereisten die zijn gewijzigd, verwijdert u ook oude tests die niet langer de huidige vereisten vertegenwoordigen.

• Vermijd het wijzigen van tests die al zijn geslaagd. Voeg in plaats daarvan nieuwe tests toe. Alleen schrijftests die een echte vereiste vertegenwoordigen.

• Voer de tests na elke wijziging uit.

... en herhaal

Ga verder met uw reeks uitbreidings- en herstructureringsstappen, met behulp van uw lijst met kleine stappen als een ruwe handleiding. U voert na elke extensie niet altijd een herstructureringsstap uit en soms voert u meer dan één herstructureringsstap achter elkaar uit. Maar u voert de eenheidstests altijd uit na elke wijziging in de code.

Soms voegt u een test toe waarvoor geen wijziging in de code is vereist, maar dat voegt uw vertrouwen toe dat de code correct werkt. U wilt er bijvoorbeeld voor zorgen dat de functie over een breed scala aan invoer werkt. U schrijft meer tests, zoals deze:

[TestMethod]
public void SqRtValueRange()
{
    LocalMath math = new LocalMath();
    for (double expectedResult = 1e-8;
        expectedResult < 1e+8;
        expectedResult = expectedResult * 3.2)
    {
        VerifyOneRootValue(math, expectedResult);
    }
}
private void VerifyOneRootValue(LocalMath math, double expectedResult)
{
    double input = expectedResult * expectedResult;
    double actualResult = math.SquareRoot(input);
    Assert.AreEqual(expectedResult, actualResult, expectedResult / 1e6);
}

Deze test geeft de eerste keer dat deze wordt uitgevoerd door.

Om ervoor te zorgen dat dit resultaat geen fout is, kunt u tijdelijk een kleine fout in uw test introduceren om dit te laten mislukken. Nadat u de fout hebt gezien, kunt u deze opnieuw oplossen.

Tip

Zorg ervoor dat een test mislukt voordat u deze doorgeeft.

Uitzonderingen

Ga nu verder met het schrijven van tests voor uitzonderlijke invoer:

[TestMethod]
public void RootTestNegativeInput()
{
    LocalMath math = new LocalMath();
    try
    {
        math.SquareRoot(-10.0);
    }
    catch (ArgumentOutOfRangeException)
    {
        return;
    }
    catch
    {
        Assert.Fail("Wrong exception on negative input");
        return;
    }
    Assert.Fail("No exception on negative input");
}

Met deze test wordt de code in een lus gebracht. U moet de knop Annuleren gebruiken in Test Explorer. Hiermee wordt de code binnen 10 seconden beëindigd.

U wilt ervoor zorgen dat een eindeloze lus niet kan plaatsvinden op de buildserver. Hoewel de server een time-out oplegt voor een volledige uitvoering, is het een zeer lange time-out en zou dit aanzienlijke vertraging veroorzaken. Daarom kunt u een expliciete time-out toevoegen aan deze test:

[TestMethod, Timeout(1000)]
public void RootTestNegativeInput()
{...

De expliciete time-out zorgt ervoor dat de test mislukt.

Werk de code bij om dit uitzonderlijke geval aan te pakken:

public double SquareRoot(double x)
{
    if (x <= 0.0) 
    {
        throw new ArgumentOutOfRangeException();
    }

Regressie

De nieuwe test is geslaagd, maar er is een regressie. Een test die nu is geslaagd, mislukt:

De fout zoeken en oplossen:

public double SquareRoot(double x)
{
    if (x < 0.0)  // not <=
    {
        throw new ArgumentOutOfRangeException();
    }

Nadat deze is opgelost, worden alle tests doorstaan:

Tip

Zorg ervoor dat elke test is geslaagd na elke wijziging die u aanbrengt in de code.

Codedekking

Haal tussenpozen tijdens uw werk en tot slot een codedekkingsrapport op voordat u de code incheckt. Dit laat zien hoeveel van de code is uitgevoerd door uw tests.

Uw team streeft naar dekking van ten minste 80%. Ze versoepelen deze vereiste voor gegenereerde code, omdat het lastig kan zijn om een hoge dekking voor dit type code te bereiken.

Een goede dekking is geen garantie dat de volledige functionaliteit van het onderdeel is getest en niet garandeert dat de code werkt voor elk bereik van invoerwaarden. Toch is er een redelijk nauwe correlatie tussen de dekking van coderegels en de dekking van de gedragsruimte van een onderdeel. Daarom versterkt een goede dekking het vertrouwen van het team dat ze het meeste gedrag testen dat ze zouden moeten doen.

Als u een codedekkingsrapport wilt ophalen, selecteert u In het menu Visual Studio Test de optie Codedekking analyseren voor alle tests. Alle tests worden opnieuw uitgevoerd.

Wanneer u het totaal in het rapport uitvouwt, ziet u dat de code die u ontwikkelt volledige dekking heeft. Dit is zeer bevredigend, omdat de belangrijke score is voor de code die wordt getest. De onopgedekte secties bevinden zich in de tests zelf.

Door de knop Codedekkingskleuring weergeven in te schakelen, kunt u zien welke onderdelen van de testcode niet zijn gebruikt. Code die niet in de tests is gebruikt, wordt oranje gemarkeerd. Deze secties zijn echter niet belangrijk voor dekking omdat ze zich in de testcode bevinden en alleen worden gebruikt als er een fout wordt gedetecteerd.

Als u wilt controleren of een specifieke test in specifieke vertakkingen van de code terechtkomt, kunt u Codedekkingskleuring weergeven instellen en vervolgens de enkele test uitvoeren met behulp van de opdracht Uitvoeren in het snelmenu.

Wanneer ben je klaar?

U blijft de code in kleine stappen bijwerken totdat u tevreden bent over het volgende:

• Alle beschikbare eenheidstests zijn geslaagd.

  In een project met een zeer grote set eenheidstests kan het onpraktisch zijn voor een ontwikkelaar om te wachten totdat ze allemaal zijn uitgevoerd. In plaats daarvan beheert het project een gated check-in service, waarin alle geautomatiseerde tests worden uitgevoerd voor elke ingecheckte plankenset voordat het wordt samengevoegd in de bronstructuur. Het inchecken wordt geweigerd als de uitvoering mislukt. Hierdoor kunnen ontwikkelaars een minimale set eenheidstests uitvoeren op hun eigen machines en vervolgens verdergaan met ander werk, zonder het risico te lopen dat de build wordt onderbroken. Zie Een gated check-in buildproces gebruiken om wijzigingen te valideren voor meer informatie.

• Codedekking voldoet aan de standaard van het team. 75% is een typische projectvereiste.

• Uw eenheidstests simuleren elk aspect van het gedrag dat vereist is, inclusief typische en uitzonderlijke invoer.

• Uw code is eenvoudig te begrijpen en uit te breiden.

Wanneer aan al deze criteria wordt voldaan, kunt u uw code controleren in broncodebeheer.

Principes van codeontwikkeling met eenheidstests

Pas de volgende principes toe tijdens het ontwikkelen van code:

• Ontwikkel eenheidstests samen met de code en voer ze regelmatig uit tijdens de ontwikkeling. De eenheidstests vertegenwoordigen de specificatie van uw onderdeel.
• Wijzig geen eenheidstests, tenzij de vereisten zijn gewijzigd of de tests onjuist waren. Voeg geleidelijk nieuwe tests toe wanneer u de functionaliteit van de code uitbreidt.
• Zorg ervoor dat ten minste 75% van uw code wordt gedekt door de tests. Bekijk de resultaten van de codedekking met intervallen en voordat u broncode incheckt.
• Controleer uw eenheidstests samen met de code, zodat deze worden uitgevoerd door de continue of reguliere server-builds.
• Waar praktisch, voor elk onderdeel van de functionaliteit, de eenheidstest eerst schrijft. Doe dit voordat u de code ontwikkelt die eraan voldoet.

De wijzigingen inchecken

Voordat u wijzigingen incheckt, deelt u uw scherm opnieuw met collega's, zodat ze informeel en interactief met u kunnen beoordelen wat u hebt gemaakt. De tests blijven de focus van uw discussie met collega's die voornamelijk geïnteresseerd zijn in wat de code doet, niet hoe het werkt. Deze collega's moeten ermee akkoord gaan dat wat u hebt geschreven aan hun behoeften voldoet.

Controleer alle wijzigingen die u hebt aangebracht, inclusief de tests en de code, en koppel ze aan de taken die u hebt voltooid. Tijdens het inchecken wordt het geautomatiseerde teambuildsysteem van het team in de wachtrij geplaatst om uw wijzigingen te valideren met behulp van het CI Build-buildproces van het team. Met dit buildproces kan het team fouten in hun codebasis minimaliseren door in een schone omgeving te bouwen en testen, gescheiden van hun ontwikkelcomputers, elke wijziging die het team aanbrengt.

U ontvangt een melding wanneer de build is voltooid. In het venster met buildresultaten ziet u dat de build is geslaagd en alle tests zijn geslaagd.

De wijzigingen inchecken

1. Selecteer Inchecken op de pagina Mijn werk in Teamverkenner.

   

2. Controleer op de pagina Wijzigingen in behandeling het volgende:

   • Alle relevante wijzigingen worden vermeld in Opgenomen wijzigingen.
   • Alle relevante werkitems worden vermeld in Gerelateerde werkitems.

3. Voer een opmerking in om uw team te helpen het doel van deze wijzigingen te begrijpen wanneer ze de versiebeheergeschiedenis van de gewijzigde bestanden en mappen bekijken.

4. Kies Inchecken.

   

De code continu integreren

Zie Een CI-build instellen voor meer informatie over het definiëren van een buildproces voor continue integratie. Nadat u dit buildproces hebt ingesteld, kunt u ervoor kiezen om op de hoogte te worden gesteld van de resultaten van teambuilds.

Zie Builds uitvoeren, bewaken en beheren voor meer informatie.

Volgende stappen

Werk onderbreken, een bug oplossen en een codebeoordeling uitvoeren