Het bouwen van een pijplijn continue integratie en continue implementatie met DSCBuilding a Continuous Integration and Continuous Deployment pipeline with DSC

In dit voorbeeld laat zien hoe een continue integratie met doorlopend implementatie (CI/CD)-pijplijn maken met behulp van PowerShell, DSC, Pester en Visual Studio Team Foundation Server (TFS).This example demonstrates how to build a Continuous Integration/Continuous Deployment (CI/CD) pipeline by using PowerShell, DSC, Pester, and Visual Studio Team Foundation Server (TFS).

Nadat de pijplijn is gemaakt en geconfigureerd, kunt u gebruiken deze volledig implementeren, configureren en testen van een DNS-server en host-records die zijn gekoppeld.After the pipeline is built and configured, you can use it to fully deploy, configure and test a DNS server and associated host records. Dit proces wordt het eerste deel van een pijplijn die moet worden gebruikt in een ontwikkelingsomgeving gesimuleerd.This process simulates the first part of a pipeline that would be used in a development environment.

Een geautomatiseerde CI/CD-pijplijn, kunt u software sneller en betrouwbaarder, ervoor te zorgen dat alle code wordt getest en dat er een huidige build van uw code is beschikbaar te allen tijde.An automated CI/CD pipeline helps you update software faster and more reliably, ensuring that all code is tested, and that a current build of your code is available at all times.

VereistenPrerequisites

Dit voorbeeld kunt gebruiken, moet u bekend bent met het volgende:To use this example, you should be familiar with the following:

Wat u nodig hebtWhat you will need

Voor het bouwen en uitvoeren van dit voorbeeld, moet u een omgeving met meerdere computers en/of virtuele machines.To build and run this example, you will need an environment with several computers and/or virtual machines.

ClientClient

Dit is de computer waar u doet al het werk instellen en uitvoeren in het voorbeeld.This is the computer where you'll do all of the work setting up and running the example.

De clientcomputer moet een Windows-computer met het volgende zijn geïnstalleerd:The client computer must be a Windows computer with the following installed:

TFSSrv1TFSSrv1

De computer die als host fungeert voor de TFS-server waar u uw build definieert en release.The computer that hosts the TFS server where you will define your build and release. Deze computer Team Foundation Server 2017 geïnstalleerd.This computer must have Team Foundation Server 2017 installed.

BuildAgentBuildAgent

De computer met de Windows-agent die wordt gemaakt van het project bouwen.The computer that runs the Windows build agent that builds the project. Deze computer moet een agent geïnstalleerd en uitgevoerd bouwen Windows hebben.This computer must have a Windows build agent installed and running. Zie implementeren van een agent op Windows voor instructies over het installeren en uitvoeren van een Windows-build agent.See Deploy an agent on Windows for instructions on how to install and run a Windows build agent.

U moet ook installeren op zowel de xDnsServer en xNetworking DSC-modules op deze computer.You also need to install both the xDnsServer and xNetworking DSC modules on this computer.

TestAgent1TestAgent1

Dit is de computer die is geconfigureerd als een DNS-server door de DSC-configuratie in dit voorbeeld.This is the computer that is configured as a DNS server by the DSC configuration in this example. De computer moet worden uitgevoerd Windows Server 2016.The computer must be running Windows Server 2016.

TestAgent2TestAgent2

Dit is de computer die als host fungeert voor de website die in dit voorbeeld configureert.This is the computer that hosts the website this example configures. De computer moet worden uitgevoerd Windows Server 2016.The computer must be running Windows Server 2016.

Voeg de code naar TFSAdd the code to TFS

We beginnen uit door het maken van een Git-opslagplaats in TFS en importeren van de code van uw lokale opslagplaats op de clientcomputer.We'll start out by creating a Git repository in TFS, and importing the code from your local repository on the client computer. Als u de opslagplaats Demo_CI hebt niet op uw clientcomputer hebt gekloond, dit nu doen met de volgende git-opdracht:If you have not already cloned the Demo_CI repository to your client computer, do so now by running the following git command:

git clone https://github.com/PowerShell/Demo_CI

  1. Navigeer naar de TFS-server in een webbrowser op de clientcomputer.On your client computer, navigate to your TFS server in a web browser.
  2. In TFS, maken van een nieuw teamproject Demo_CI met de naam.In TFS, Create a new team project named Demo_CI.

    Zorg ervoor dat versiebeheer is ingesteld op Git.Make sure that Version control is set to Git.

  3. Op de clientcomputer voegt u een externe toe aan de opslagplaats die u zojuist hebt gemaakt in TFS met de volgende opdracht:On your client computer, add a remote to the repository you just created in TFS with the following command:

    git remote add tfs <YourTFSRepoURL>

    Waar <YourTFSRepoURL> de kloon-URL naar de TFS-opslagplaats die u in de vorige stap hebt gemaakt.Where <YourTFSRepoURL> is the clone URL to the TFS repository you created in the previous step.

    Als u niet waar deze URL zoeken weet, Zie klonen van een bestaande Git-opslagplaats.If you don't know where to find this URL, see Clone an existing Git repo.

  4. De code van uw lokale opslagplaats pushen naar uw opslagplaats TFS met de volgende opdracht:Push the code from your local repository to your TFS repository with the following command:

    git push tfs --all

  5. De opslagplaats TFS worden ingevuld met de code Demo_CI.The TFS repository will be populated with the Demo_CI code.

Opmerking: in dit voorbeeld wordt de code in de ci-cd-example vertakking van de Git-opslagplaats.Note: This example uses the code in the ci-cd-example branch of the Git repo. Zorg ervoor dat de vertakking opgeven als de standaardvertakking in TFS-project en voor de CI/CD-triggers die u maakt.Be sure to specify this branch as the default branch in your TFS project, and for the CI/CD triggers you create.

Wat is de code?Understanding the code

Voordat we het build- en pijplijnen maken, bekijken we enkele van de code te begrijpen wat er gebeurt.Before we create the build and deployment pipelines, let's look at some of the code to understand what is going on. Open uw favoriete teksteditor op de clientcomputer en navigeer naar de hoofdmap van uw Demo_CI Git-opslagplaats.On your client computer, open your favorite text editor and navigate to the root of your Demo_CI Git repository.

De DSC-configuratieThe DSC configuration

Open het bestand DNSServer.ps1 (in de hoofdmap van de lokale Demo_CI opslagplaats ./InfraDNS/Configs/DNSServer.ps1).Open the file DNSServer.ps1 (from the root of the local Demo_CI repository, ./InfraDNS/Configs/DNSServer.ps1).

Dit bestand bevat de DSC-configuratie instellen van de DNS-server.This file contains the DSC configuration that sets up the DNS server. Dit is in zijn geheel:Here it is in its entirety:

configuration DNSServer
{
    Import-DscResource -module 'xDnsServer','xNetworking', 'PSDesiredStateConfiguration'

    Node $AllNodes.Where{$_.Role -eq 'DNSServer'}.NodeName
    {
        WindowsFeature DNS
        {
            Ensure  = 'Present'
            Name    = 'DNS'
        }

        xDnsServerPrimaryZone $Node.zone
        {
            Ensure    = 'Present'
            Name      = $Node.Zone
            DependsOn = '[WindowsFeature]DNS'
        }

        foreach ($ARec in $Node.ARecords.keys) {
            xDnsRecord $ARec
            {
                Ensure    = 'Present'
                Name      = $ARec
                Zone      = $Node.Zone
                Type      = 'ARecord'
                Target    = $Node.ARecords[$ARec]
                DependsOn = '[WindowsFeature]DNS'
            }
        }

        foreach ($CName in $Node.CNameRecords.keys) {
            xDnsRecord $CName
            {
                Ensure    = 'Present'
                Name      = $CName
                Zone      = $Node.Zone
                Type      = 'CName'
                Target    = $Node.CNameRecords[$CName]
                DependsOn = '[WindowsFeature]DNS'
            }
        }
    }
}

U ziet de Node instructie:Notice the Node statement:

Node $AllNodes.Where{$_.Role -eq 'DNSServer'}.NodeName

Hiermee vindt u alle knooppunten die zijn gedefinieerd als bestanden met de rol DNSServer in de configuratiegegevens, die wordt gemaakt door de DevEnv.ps1 script.This finds any nodes that were defined as having a role of DNSServer in the configuration data, which is created by the DevEnv.ps1 script.

Met behulp van de configuratiegegevens voor het definiëren van knooppunten is belangrijk bij het uitvoeren van CI omdat knooppunt informatie waarschijnlijk tussen omgevingen veranderen zullen en configuratiegegevens met kunt u gemakkelijk wijzigingen aanbrengen in knooppunt informatie zonder de configuratiecode te wijzigen.Using configuration data to define nodes is important when doing CI because node information will likely change between environments, and using configuration data allows you to easily make changes to node information without changing the configuration code.

In de eerste resource blok, de configuratie roept de WindowsFeature om ervoor te zorgen dat de DNS-functie is ingeschakeld.In the first resource block, the configuration calls the WindowsFeature to ensure that the DNS feature is enabled. De resource-blokken die resources van de aanroep van volgen de xDnsServer module voor het configureren van de primaire zone en DNS-records.The resource blocks that follow call resources from the xDnsServer module to configure the primary zone and DNS records.

U ziet dat de twee xDnsRecord blokken zijn samengevoegd in foreach lussen die matrices in de configuratiegegevens doorlopen.Notice that the two xDnsRecord blocks are wrapped in foreach loops that iterate through arrays in the configuration data. De configuratiegegevens wordt opnieuw gemaakt door de DevEnv.ps1 script, dat zullen we op volgende.Again, the configuration data is created by the DevEnv.ps1 script, which we'll look at next.

ConfiguratiegegevensConfiguration data

De DevEnv.ps1 bestand (in de hoofdmap van de lokale Demo_CI opslagplaats ./InfraDNS/DevEnv.ps1) Hiermee geeft u de omgeving-specifieke configuratiegegevens in een hashtabel en vervolgens die hashtabel doorgegeven aan een aanroep van de New-DscConfigurationDataDocument functie, die is gedefinieerd in DscPipelineTools.psm (./Assets/DscPipelineTools/DscPipelineTools.psm1).The DevEnv.ps1 file (from the root of the local Demo_CI repository, ./InfraDNS/DevEnv.ps1) specifies the environment-specific configuration data in a hashtable, and then passes that hashtable to a call to the New-DscConfigurationDataDocument function, which is defined in DscPipelineTools.psm (./Assets/DscPipelineTools/DscPipelineTools.psm1).

De DevEnv.ps1 bestand:The DevEnv.ps1 file:

param(
    [parameter(Mandatory=$true)]
    [string]
    $OutputPath
)

Import-Module $PSScriptRoot\..\Assets\DscPipelineTools\DscPipelineTools.psd1 -Force

# Define Unit Test Environment
$DevEnvironment = @{
    Name                        = 'DevEnv';
    Roles = @(
        @{  Role                = 'DNSServer';
            VMName              = 'TestAgent1';
            Zone                = 'Contoso.com';
            ARecords            = @{'TFSSrv1'= '10.0.0.10';'Client'='10.0.0.15';'BuildAgent'='10.0.0.30';'TestAgent1'='10.0.0.40';'TestAgent2'='10.0.0.50'};
            CNameRecords        = @{'DNS' = 'TestAgent1.contoso.com'};
        }
    )
}

Return New-DscConfigurationDataDocument -RawEnvData $DevEnvironment -OutputPath $OutputPath

De New-DscConfigurationDataDocument functie (gedefinieerd in \Assets\DscPipelineTools\DscPipelineTools.psm1) via een programma maakt een configuratiebestand voor de gegevens van de hash-tabel (knooppuntgegevens) en de matrix (niet-knooppunt gegevens) die worden doorgegeven als de RawEnvData en OtherEnvData parameters.The New-DscConfigurationDataDocument function (defined in \Assets\DscPipelineTools\DscPipelineTools.psm1) programmatically creates a configuration data document from the hashtable (node data) and array (non-node data) that are passed as the RawEnvData and OtherEnvData parameters.

In ons geval alleen de RawEnvData parameter wordt gebruikt.In our case, only the RawEnvData parameter is used.

Het psake build scriptThe psake build script

De psake bouwen script gedefinieerd in Build.ps1 (in de hoofdmap van de opslagplaats Demo_CI ./InfraDNS/Build.ps1) taken die deel van de build uitmaken definieert.The psake build script defined in Build.ps1 (from the root of the Demo_CI repository, ./InfraDNS/Build.ps1) defines tasks that are part of the build. Het definieert ook welke andere elke taak afhankelijk van is taken.It also defines which other tasks each task depends on. Als deze wordt aangeroepen, het script psake zorgt ervoor dat de opgegeven taak (of de taak met de naam Default als niets wordt opgegeven) wordt uitgevoerd en dat alle afhankelijkheden ook uitvoeren (dit is recursieve, zodat de afhankelijkheden van afhankelijkheden hebt uitgevoerd, enzovoort).When invoked, the psake script ensures that the specified task (or the task named Default if none is specified) runs, and that all dependencies also run (this is recursive, so that dependencies of dependencies run, and so on).

In dit voorbeeld wordt de Default taak is gedefinieerd als:In this example, the Default task is defined as:

Task Default -depends UnitTests

De Default taak geen implementatie zelf, maar afhankelijk is van de CompileConfigs taak.The Default task has no implementation itself, but has a dependency on the CompileConfigs task. De resulterende reeks taakafhankelijkheden zorgt ervoor dat alle taken in het build-script worden uitgevoerd.The resulting chain of task dependencies ensures that all tasks in the build script are run.

In dit voorbeeld wordt het script psake opgeroepen door een aanroep naar Invoke-PSake in de Initiate.ps1 bestand (te vinden in de hoofdmap van de opslagplaats Demo_CI):In this example, the psake script is invoked by a call to Invoke-PSake in the Initiate.ps1 file (located at the root of the Demo_CI repository):

param(
    [parameter()]
    [ValidateSet('Build','Deploy')]
    [string]
    $fileName
)

#$Error.Clear()

Invoke-PSake $PSScriptRoot\InfraDNS\$fileName.ps1

<#if($Error.count)
{
    Throw "$fileName script failed. Check logs for failure details."
}
#>

Wanneer de build-definitie we in ons voorbeeld in TFS maken, geven we onze scriptbestand psake als de fileName parameter voor dit script.When we create the build definition for our example in TFS, we will supply our psake script file as the fileName parameter for this script.

Het script build definieert de volgende taken:The build script defines the following tasks:

GenerateEnvironmentFilesGenerateEnvironmentFiles

Wordt uitgevoerd DevEnv.ps1, die het bestand met configuratiegegevens genereert.Runs DevEnv.ps1, which generates the configuration data file.

InstallModulesInstallModules

De door de configuratie van de vereiste modules installeert DNSServer.ps1.Installs the modules required by the configuration DNSServer.ps1.

ScriptAnalysisScriptAnalysis

Aanroepen van de PSScriptAnalyzer.Calls the PSScriptAnalyzer.

UnitTestsUnitTests

Voert de Pester eenheidstests.Runs the Pester unit tests.

CompileConfigsCompileConfigs

De configuratie wordt gecompileerd (DNSServer.ps1) naar een MOF-bestand met behulp van de configuratiegegevens die worden gegenereerd door de GenerateEnvironmentFiles taak.Compiles the configuration (DNSServer.ps1) into a MOF file, using the configuration data generated by the GenerateEnvironmentFiles task.

OpruimenClean

De mappen die wordt gebruikt voor het voorbeeld maakt en verwijdert u alle testresultaten, gegevens configuratiebestanden en modules uit vorige wordt uitgevoerd.Creates the folders used for the example, and removes any test results, configuration data files, and modules from previous runs.

De psake script wilt implementerenThe psake deploy script

De psake gedefinieerd in een script voor implementatie Deploy.ps1 (in de hoofdmap van de opslagplaats Demo_CI ./InfraDNS/Deploy.ps1) taken die implementeren en uitvoeren van de configuratie definieert.The psake deployment script defined in Deploy.ps1 (from the root of the Demo_CI repository, ./InfraDNS/Deploy.ps1) defines tasks that deploy and run the configuration.

Deploy.ps1 definieert de volgende taken:Deploy.ps1 defines the following tasks:

DeployModulesDeployModules

Een PowerShell-sessie begint op TestAgent1 en installeert u de modules die met de DSC-resources die vereist zijn voor de configuratie.Starts a PowerShell session on TestAgent1 and installs the modules containing the DSC resources required for the configuration.

DeployConfigsDeployConfigs

Aanroepen van de Start DscConfiguration cmdlet uit te voeren van de configuratie op TestAgent1.Calls the Start-DscConfiguration cmdlet to run the configuration on TestAgent1.

IntegrationTestsIntegrationTests

Voert de Pester integratie tests.Runs the Pester integration tests.

AcceptanceTestsAcceptanceTests

Voert de Pester acceptatie tests.Runs the Pester acceptance tests.

OpruimenClean

Hiermee verwijdert u alle modules geïnstalleerd in de vorige wordt uitgevoerd en zorgt ervoor dat de map test resultaat bestaat.Removes any modules installed in previous runs, and ensures that the test result folder exists.

Scripts testenTest scripts

Acceptatie, integratie en eenheid tests worden gedefinieerd in scripts in de Tests map (in de hoofdmap van de opslagplaats Demo_CI ./InfraDNS/Tests), elk in bestanden met de naam DNSServer.tests.ps1 in de bijbehorende mappen.Acceptance, Integration, and Unit tests are defined in scripts in the Tests folder (from the root of the Demo_CI repository, ./InfraDNS/Tests), each in files named DNSServer.tests.ps1 in their respective folders.

De test scripts gebruik Pester en PoshSpec syntaxis.The test scripts use Pester and PoshSpec syntax.

EenheidstestsUnit tests

De eenheid test test de DSC-configuraties zelf om ervoor te zorgen dat de configuraties wordt verwacht doet wanneer ze worden uitgevoerd.The unit tests test the DSC configurations themselves to ensure that the configurations will do what is expected when they run. De eenheid testen script gebruikt Pester.The unit test script uses Pester.

Integratie-testsIntegration tests

De tests integratie test de configuratie van het systeem om ervoor te zorgen dat indien geïntegreerd met andere onderdelen, het systeem is geconfigureerd zoals verwacht.The integration tests test the configuration of the system to ensure that when integrated with other components, the system is configured as expected. Deze tests uitgevoerd op het doelknooppunt nadat deze is geconfigureerd met DSC.These tests run on the target node after it has been configured with DSC. Het testscript integratie maakt gebruik van een combinatie van Pester en PoshSpec syntaxis.The integration test script uses a mixture of Pester and PoshSpec syntax.

Acceptatie van de testsAcceptance tests

Acceptatie van de tests test het systeem om ervoor te zorgen dat deze functie werkt zoals verwacht.Acceptance tests test the system to ensure that it behaves as expected. Bijvoorbeeld: test om te controleren of dat een webpagina retourneert de juiste informatie wanneer opgevraagd.For example, it tests to ensure a web page returns the right information when queried. Deze tests uitvoeren op afstand vanaf het doelknooppunt real-world scenario's testen.These tests run remotely from the target node in order to test real world scenarios. Het testscript integratie maakt gebruik van een combinatie van Pester en PoshSpec syntaxis.The integration test script uses a mixture of Pester and PoshSpec syntax.

Definieer de buildDefine the build

Nu dat we onze code hebt geüpload naar TFS en bekeken wat het geval is, gaan we onze build definiëren.Now that we've uploaded our code to TFS and looked at what it does, let's define our build.

Hier komen aan bod de build-stappen die u aan de build toevoegen zult.Here, we'll cover only the build steps that you'll add to the build. Zie voor instructies over het maken van een definitie van de build in TFS maken en de definitie van een build wachtrij.For instructions on how to create a build definition in TFS, see Create and queue a build definition.

Een nieuwe build-definitie maken (Selecteer de leeg sjabloon) met de naam 'InfraDNS'.Create a new build definition (select the Empty template) named "InfraDNS". Voeg dat de volgende stappen uit om u te bouwen definitie:Add the following steps to you build definition:

  • PowerShell-ScriptPowerShell Script
  • Testresultaten publicerenPublish Test Results
  • Bestanden kopiërenCopy Files
  • Publiceren van artefactenPublish Artifact

Na het toevoegen van deze stappen te bouwen, bewerk de eigenschappen van elke stap als volgt:After adding these build steps, edit the properties of each step as follows:

PowerShell-ScriptPowerShell Script

  1. Stel de Type eigenschap File Path.Set the Type property to File Path.
  2. Stel de scriptpad eigenschap initiate.ps1.Set the Script Path property to initiate.ps1.
  3. Voeg -fileName build naar de argumenten eigenschap.Add -fileName build to the Arguments property.

Deze stap build wordt uitgevoerd de initiate.ps1 -bestand, dat het psake build script aanroept.This build step runs the initiate.ps1 file, which calls the psake build script.

Testresultaten publicerenPublish Test Results

  1. Stel Resultaatindeling testen naar NUnitSet Test Result Format to NUnit
  2. Stel testresultaten bestanden naar InfraDNS/Tests/Results/*.xmlSet Test Results Files to InfraDNS/Tests/Results/*.xml
  3. Stel testen uitvoeren titel naar Unit.Set Test Run Title to Unit.
  4. Zorg ervoor dat beheeropties ingeschakeld en altijd uitgevoerd zijn beide ingeschakeld.Make sure Control Options Enabled and Always run are both selected.

Deze stap build wordt uitgevoerd de eenheidstests in het Pester-script dat we eerder bekeken en slaat de resultaten in de InfraDNS/Tests/Results/*.xml map.This build step runs the unit tests in the Pester script we looked at earlier, and stores the results in the InfraDNS/Tests/Results/*.xml folder.

Bestanden kopiërenCopy Files

  1. Elk van de volgende regels toevoegen inhoud:Add each of the following lines to Contents:

    initiate.ps1
    **\deploy.ps1
    **\Acceptance\**
    **\Integration\**
    
  2. Stel TargetFolder naar $(Build.ArtifactStagingDirectory)\Set TargetFolder to $(Build.ArtifactStagingDirectory)\

Deze stap kopieert de build en test scripts aan de staging-map zodanig dat het kan worden gepubliceerd als artefacten bouwen door de volgende stap.This step copies the build and test scripts to the staging directory so that the can be published as build artifacts by the next step.

Publiceren van artefactenPublish Artifact

  1. Stel pad voor het publiceren van naar $(Build.ArtifactStagingDirectory)\Set Path to Publish to $(Build.ArtifactStagingDirectory)\
  2. Stel artefact naam naar DeploySet Artifact Name to Deploy
  3. Stel artefact Type naar ServerSet Artifact Type to Server
  4. Selecteer Enabled in opties instellenSelect Enabled in Control Options

Continue integratie inschakelenEnable continuous integration

Nu we een trigger die ervoor zorgt het project stellen dat voor het bouwen van elk gewenst moment een wijziging wordt ingecheckt bij de ci-cd-example vertakking van de git-opslagplaats.Now we'll set up a trigger that causes the project to build any time a change is checked in to the ci-cd-example branch of the git repository.

  1. In TFS, klikt u op de bouwen & Release tabbladIn TFS, click the Build & Release tab
  2. Selecteer de DNS Infra definitie bouwen en klikt u op bewerkenSelect the DNS Infra build definition, and click Edit
  3. Klik op de Triggers tabbladClick the Triggers tab
  4. Selecteer continue integratie (CI), en selecteer refs/heads/ci-cd-example in de vervolgkeuzelijst vertakkingSelect Continuous integration (CI), and select refs/heads/ci-cd-example in the branch drop-down list
  5. Klik op opslaan en vervolgens OKClick Save and then OK

Nu wijziging elke in de TFS git-opslagplaats triggers een geautomatiseerde build.Now any change in the TFS git repository triggers an automated build.

De release-definitie makenCreate the release definition

De definitie van een release we maken zodat het project wordt geïmplementeerd op de ontwikkelomgeving met elke code incheckt.Let's create a release definition so that the project is deployed to the development environment with every code check-in.

U doet dit door een nieuwe toevoegen release die zijn gekoppeld aan de InfraDNS bouwen definitie die u eerder hebt gemaakt.To do this, add a new release definition associated with the InfraDNS build definition you created previously. Selecteer continue implementatie zodat een nieuwe release geactiveerd elk gewenst moment een nieuwe build is voltooid.Be sure to select Continuous deployment so that a new release will be triggered any time a new build is completed. (How to: werken met release definities) en configureer deze als volgt:(How to: Work with release definitions) and configure it as follows:

De volgende stappen toevoegen aan de definitie van de release:Add the following steps to the release definition:

  • PowerShell-ScriptPowerShell Script
  • Testresultaten publicerenPublish Test Results
  • Testresultaten publicerenPublish Test Results

Bewerk de stappen uit als volgt:Edit the steps as follows:

PowerShell-ScriptPowerShell Script

  1. Stel de scriptpad veld $(Build.DefinitionName)\Deploy\initiate.ps1"Set the Script Path field to $(Build.DefinitionName)\Deploy\initiate.ps1"
  2. Stel de argumenten veld -fileName DeploySet the Arguments field to -fileName Deploy

Testresultaten eerst publicerenFirst Publish Test Results

  1. Selecteer NUnit voor de Resultaatindeling Test veldSelect NUnit for the Test Result Format field
  2. Stel de resultaat testbestanden veld $(Build.DefinitionName)\Deploy\InfraDNS\Tests\Results\Integration*.xmlSet the Test Result Files field to $(Build.DefinitionName)\Deploy\InfraDNS\Tests\Results\Integration*.xml
  3. Stel de testen uitvoeren titel naar IntegrationSet the Test Run Title to Integration
  4. Onder beheeropties, Controleer altijd worden uitgevoerdUnder Control Options, check Always run

Tweede publiceren testresultatenSecond Publish Test Results

  1. Selecteer NUnit voor de Resultaatindeling Test veldSelect NUnit for the Test Result Format field
  2. Stel de resultaat testbestanden veld $(Build.DefinitionName)\Deploy\InfraDNS\Tests\Results\Acceptance*.xmlSet the Test Result Files field to $(Build.DefinitionName)\Deploy\InfraDNS\Tests\Results\Acceptance*.xml
  3. Stel de testen uitvoeren titel naar AcceptanceSet the Test Run Title to Acceptance
  4. Onder beheeropties, Controleer altijd worden uitgevoerdUnder Control Options, check Always run

De resultaten controlerenVerify your results

Nu elk gewenst moment u push-wijzigingen de ci-cd-example vertakking naar TFS, een nieuwe build wordt gestart.Now, any time you push changes in the ci-cd-example branch to TFS, a new build will start. Als de build voltooid is, wordt een nieuwe implementatie wordt geactiveerd.If the build completes successfully, a new deployment is triggered.

U kunt het resultaat van de implementatie controleren door een browser op de clientcomputer openen en te navigeren naar www.contoso.com.You can check the result of the deployment by opening a browser on the client machine and navigating to www.contoso.com.

Volgende stappenNext steps

In dit voorbeeld configureert de DNS-server TestAgent1 zodat de URL www.contoso.com wordt omgezet naar TestAgent2, maar deze een website niet daadwerkelijk implementeren.This example configures the DNS server TestAgent1 so that the URL www.contoso.com resolves to TestAgent2, but it does not actually deploy a website. Het basisproject hiertoe vindt u in de opslagplaats onder de WebApp map.The skeleton for doing so is provided in the repo under the WebApp folder. U kunt de stubs voor het maken van psake scripts, Pester tests en DSC-configuraties gebruiken voor het implementeren van uw eigen website.You can use the stubs provided to create psake scripts, Pester tests, and DSC configurations to deploy your own website.