Criando um pipeline de integração contínua e implantação contínua com DSCBuilding a Continuous Integration and Continuous Deployment pipeline with DSC

Este exemplo demonstra como criar um pipeline de CI/CD (implantação contínua/integração contínua) usando o PowerShell, a DSC, o Pester e o 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).

Depois que o pipeline é criado e configurado, você pode usá-lo para implantar, configurar e testar completamente um servidor DNS e os registros de host associados.After the pipeline is built and configured, you can use it to fully deploy, configure and test a DNS server and associated host records. Esse processo simula a primeira parte de um pipeline que seria usado em um ambiente de desenvolvimento.This process simulates the first part of a pipeline that would be used in a development environment.

Um pipeline de CI/CD automatizado ajuda a atualizar softwares com mais rapidez e confiança, garantir que todo o código seja testado e que um build atual do código esteja sempre disponível.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.

Pré-requisitosPrerequisites

Para usar este exemplo, você deve estar familiarizado com o seguinte:To use this example, you should be familiar with the following:

O que será necessárioWhat you will need

Para compilar e executar esse exemplo, você precisará de um ambiente com vários computadores e/ou máquinas virtuais.To build and run this example, you will need an environment with several computers and/or virtual machines.

RemotaClient

Este é o computador no qual você fará todo o trabalho de configurar e executar o exemplo.This is the computer where you'll do all of the work setting up and running the example.

O computador cliente deve ser um computador Windows com o seguinte instalado:The client computer must be a Windows computer with the following installed:

TFSSrv1TFSSrv1

O computador que hospeda o servidor do TFS no qual você definirá o build e a versão.The computer that hosts the TFS server where you will define your build and release. Este computador deve ter o Team Foundation Server 2017 instalado.This computer must have Team Foundation Server 2017 installed.

BuildAgentBuildAgent

O computador que executa o agente de build do Windows que compila o projeto.The computer that runs the Windows build agent that builds the project. Este computador deve ter um agente de build do Windows instalado e em execução.This computer must have a Windows build agent installed and running. Consulte Deploy an agent on Windows (Implantar um agente no Windows ) para obter instruções de como instalar e executar um agente de build do Windows.See Deploy an agent on Windows for instructions on how to install and run a Windows build agent.

Você também precisa instalar os módulos de DSC xDnsServer e xNetworking nesse computador.You also need to install both the xDnsServer and xNetworking DSC modules on this computer.

TestAgent1TestAgent1

Este é o computador que está configurado como um servidor DNS pela configuração DSC neste exemplo.This is the computer that is configured as a DNS server by the DSC configuration in this example. O computador deve estar executando o Windows Server 2016.The computer must be running Windows Server 2016.

TestAgent2TestAgent2

Este é o computador que hospeda o site, que este exemplo configura.This is the computer that hosts the website this example configures. O computador deve estar executando o Windows Server 2016.The computer must be running Windows Server 2016.

Adicione o código no TFSAdd the code to TFS

Vamos começar criando um repositório Git no TFS e importando o código de seu repositório local no computador cliente.We'll start out by creating a Git repository in TFS, and importing the code from your local repository on the client computer. Se você ainda não clonou o repositório Demo_CI no computador cliente, faça isso agora, executando o seguinte comando git: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. No computador cliente, navegue até o servidor do TFS em um navegador da Web.On your client computer, navigate to your TFS server in a web browser.
  2. No TFS, Crie um novo projeto de equipe chamado Demo_CI.In TFS, Create a new team project named Demo_CI.

    Verifique se o Controle de versão é definido como Git.Make sure that Version control is set to Git.

  3. No computador cliente, adicione um remoto no repositório que você acabou de criar no TFS com o seguinte comando:On your client computer, add a remote to the repository you just created in TFS with the following command:

    git remote add tfs <YourTFSRepoURL>

    Em que <YourTFSRepoURL> é a URL clone para o repositório do TFS que você criou na etapa anterior.Where <YourTFSRepoURL> is the clone URL to the TFS repository you created in the previous step.

    Se você não souber onde encontrar essa URL, consulte Clone an existing Git repo (Clonar um repositório Git existente).If you don't know where to find this URL, see Clone an existing Git repo.

  4. Envie o código por push de seu repositório local para o repositório do TFS com o seguinte comando:Push the code from your local repository to your TFS repository with the following command:

    git push tfs --all

  5. O repositório do TFS será preenchido com o código Demo_CI.The TFS repository will be populated with the Demo_CI code.

Observação: este exemplo usa o código na ramificação ci-cd-example do repositório Git.Note: This example uses the code in the ci-cd-example branch of the Git repo. Assegure-se de especificar essa ramificação como a ramificação padrão em seu projeto do TFS e para os gatilhos de CI/CD que você criar.Be sure to specify this branch as the default branch in your TFS project, and for the CI/CD triggers you create.

Noções básicas sobre o códigoUnderstanding the code

Antes de criar os pipelines de build e implantação, vamos analisar parte do código para entender o que está acontecendo.Before we create the build and deployment pipelines, let's look at some of the code to understand what is going on. No computador cliente, abra o editor de texto favorito e navegue até a raiz do repositório Git Demo_CI.On your client computer, open your favorite text editor and navigate to the root of your Demo_CI Git repository.

A configuração DSCThe DSC configuration

Abra o arquivo DNSServer.ps1 (da raiz do repositório local Demo_CI, ./InfraDNS/Configs/DNSServer.ps1).Open the file DNSServer.ps1 (from the root of the local Demo_CI repository, ./InfraDNS/Configs/DNSServer.ps1).

Este arquivo contém a configuração DSC que configura o servidor DNS.This file contains the DSC configuration that sets up the DNS server. Aqui está ele por inteiro: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'
            }
        }
    }
}

Observe a instrução Node:Notice the Node statement:

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

Isso localiza todos os nós que foram definidos como tendo uma função de DNSServer nos dados de configuração, que são criados pelo script DevEnv.ps1.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.

Usar dados de configuração para definir nós é importante ao fazer CI porque as informações do nó provavelmente serão alteradas entre os ambientes e usar dados de configuração permite fazer alterações facilmente nas informações do nó sem alterar o código de configuração.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.

No primeiro bloco de recurso, a configuração chama o WindowsFeature para garantir que o recurso DNS esteja habilitado.In the first resource block, the configuration calls the WindowsFeature to ensure that the DNS feature is enabled. Os blocos de recurso que seguem chamam recursos do módulo xDnsServer para configurar os registros DNS e a zona primária.The resource blocks that follow call resources from the xDnsServer module to configure the primary zone and DNS records.

Observe que os dois blocos xDnsRecord são encapsulados em loops foreach que iteram em matrizes nos dados de configuração.Notice that the two xDnsRecord blocks are wrapped in foreach loops that iterate through arrays in the configuration data. Novamente, os dados de configuração são criados pelo script DevEnv.ps1, o que veremos a seguir.Again, the configuration data is created by the DevEnv.ps1 script, which we'll look at next.

Dados de configuraçãoConfiguration data

O arquivo DevEnv.ps1 (da raiz do repositório local Demo_CI, ./InfraDNS/DevEnv.ps1) especifica os dados de configuração específicos ao ambiente em uma tabela de hash e, em seguida, passa essa tabela de hash para uma chamada da função New-DscConfigurationDataDocument, que é definida em 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).

O arquivo DevEnv.ps1: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

A função New-DscConfigurationDataDocument (definida em \Assets\DscPipelineTools\DscPipelineTools.psm1) cria programaticamente um documento de dados de configuração da tabela de hash (dados do nó) e da matriz (dados que não são do nó) que são passados como parâmetros RawEnvData e OtherEnvData.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.

Em nosso caso, somente o parâmetro RawEnvData é usado.In our case, only the RawEnvData parameter is used.

O script de build psakeThe psake build script

O script de build psake definido em Build.ps1 (da raiz do repositório Demo_CI, ./InfraDNS/Build.ps1) define as tarefas que fazem parte do build.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. Ele também define de quais outras tarefas cada tarefa depende.It also defines which other tasks each task depends on. Quando chamado, o script psake garante que a tarefa especificada (ou a tarefa chamada Default se não houver nenhuma especificada) seja executada e que todas as dependências também sejam executadas (isso é recursivo, para que as dependências das dependências sejam executadas e assim por diante).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).

Neste exemplo, a tarefa Default é definida como:In this example, the Default task is defined as:

Task Default -depends UnitTests

A tarefa Default não tem nenhuma implementação em si, mas tem uma dependência da tarefa CompileConfigs.The Default task has no implementation itself, but has a dependency on the CompileConfigs task. A cadeia de dependências de tarefa resultante garante que todas as tarefas no script de build sejam executadas.The resulting chain of task dependencies ensures that all tasks in the build script are run.

Neste exemplo, o script psake é invocado por uma chamada para Invoke-PSake no arquivo Initiate.ps1 (localizado na raiz do repositório 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."
}
#>

Quando criarmos a definição de build para o nosso exemplo no TFS, forneceremos o arquivo de script psake como o parâmetro fileName para esse 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.

O script de build define as seguintes tarefas:The build script defines the following tasks:

GenerateEnvironmentFilesGenerateEnvironmentFiles

Executa DevEnv.ps1, que gera o arquivo de dados de configuração.Runs DevEnv.ps1, which generates the configuration data file.

InstallModulesInstallModules

Instala os módulos necessários para a configuração DNSServer.ps1.Installs the modules required by the configuration DNSServer.ps1.

ScriptAnalysisScriptAnalysis

Chama o PSScriptAnalyzer.Calls the PSScriptAnalyzer.

UnitTestsUnitTests

Executa os testes de unidade do Pester.Runs the Pester unit tests.

CompileConfigsCompileConfigs

Compila a configuração (DNSServer.ps1) em um arquivo MOF, usando os dados de configuração gerados pela tarefa GenerateEnvironmentFiles.Compiles the configuration (DNSServer.ps1) into a MOF file, using the configuration data generated by the GenerateEnvironmentFiles task.

CleanClean

Cria as pastas usadas para o exemplo e remove todos os resultados do teste, os arquivos de dados de configuração e os módulos das execuções anteriores.Creates the folders used for the example, and removes any test results, configuration data files, and modules from previous runs.

O script de implantação psakeThe psake deploy script

O script de implantação psake definido em Deploy.ps1 (da raiz do repositório Demo_CI, ./InfraDNS/Deploy.ps1) define as tarefas que implantam e executam a configuração.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 define as seguintes tarefas:Deploy.ps1 defines the following tasks:

DeployModulesDeployModules

Inicia uma sessão do PowerShell no TestAgent1 e instala os módulos que contêm os recursos de DSC necessários para a configuração.Starts a PowerShell session on TestAgent1 and installs the modules containing the DSC resources required for the configuration.

DeployConfigsDeployConfigs

Chama o cmdlet Start-DscConfiguration para executar a configuração em TestAgent1.Calls the Start-DscConfiguration cmdlet to run the configuration on TestAgent1.

IntegrationTestsIntegrationTests

Executa os testes de integração do Pester.Runs the Pester integration tests.

AcceptanceTestsAcceptanceTests

Executa os testes de aceitação do Pester.Runs the Pester acceptance tests.

CleanClean

Remove todos os módulos instalados nas execuções anteriores e verifica se a pasta de resultados do teste exista.Removes any modules installed in previous runs, and ensures that the test result folder exists.

Scripts de testeTest scripts

Os testes de unidade, integração e aceitação são definidos em scripts na pasta Tests (da raiz do repositório Demo_CI, ./InfraDNS/Tests), cada um em arquivos denominados DNSServer.tests.ps1 em suas respectivas pastas.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.

O teste de scripts usam as sintaxes Pester e PoshSpec.The test scripts use Pester and PoshSpec syntax.

Testes de unidadeUnit tests

Os testes de unidade testam as próprias configurações DSC para garantir que elas farão o que é esperado ao serem executadas.The unit tests test the DSC configurations themselves to ensure that the configurations will do what is expected when they run. O script de teste de unidade usa o Pester.The unit test script uses Pester.

Testes de integraçãoIntegration tests

Os testes de integração testam a configuração do sistema para garantir que quando for integrado com outros componentes, o sistema esteja configurado como esperado.The integration tests test the configuration of the system to ensure that when integrated with other components, the system is configured as expected. Esses testes são executados no nó de destino depois que ele foi configurado com DSC.These tests run on the target node after it has been configured with DSC. O script de teste de integração usa uma combinação da sintaxe Pester e PoshSpec.The integration test script uses a mixture of Pester and PoshSpec syntax.

Testes de aceitaçãoAcceptance tests

Os testes de aceitação testam o sistema para garantir que ele se comporte como esperado.Acceptance tests test the system to ensure that it behaves as expected. Por exemplo, ele testa para garantir que uma página da Web retorne as informações corretas quando consultada.For example, it tests to ensure a web page returns the right information when queried. Esses testes são executados remotamente do nó de destino para testar os cenários reais.These tests run remotely from the target node in order to test real world scenarios. O script de teste de integração usa uma combinação da sintaxe Pester e PoshSpec.The integration test script uses a mixture of Pester and PoshSpec syntax.

Definir o buildDefine the build

Agora que já carregado o código para o TFS e examinamos o que ele faz, vamos definir o build.Now that we've uploaded our code to TFS and looked at what it does, let's define our build.

Aqui, vamos abordar apenas as etapas de build que você adicionará ao build.Here, we'll cover only the build steps that you'll add to the build. Para obter instruções de como criar uma definição de build no TFS, consulte Create and queue a build definition (Criar e enfileirar uma fila uma definição de build).For instructions on how to create a build definition in TFS, see Create and queue a build definition.

Crie uma nova definição de build (selecione o modelo Vazio) denominado "InfraDNS".Create a new build definition (select the Empty template) named "InfraDNS". Adicione as seguintes etapas em sua definição de build:Add the following steps to you build definition:

  • Script do PowerShellPowerShell Script
  • Publicar resultados de testePublish Test Results
  • Copiar arquivosCopy Files
  • Publicar artefatoPublish Artifact

Depois de adicionar essas etapas de build, edite as propriedades de cada etapa da seguinte maneira:After adding these build steps, edit the properties of each step as follows:

Script do PowerShellPowerShell Script

  1. Defina a propriedade Tipo como File Path.Set the Type property to File Path.
  2. Defina a propriedade Caminho de script como initiate.ps1.Set the Script Path property to initiate.ps1.
  3. Adicione -fileName build na propriedade Argumentos.Add -fileName build to the Arguments property.

Essa etapa de build executa o arquivo initiate.ps1, que chama o script de build psake.This build step runs the initiate.ps1 file, which calls the psake build script.

Publicar resultados de testePublish Test Results

  1. Defina o Formato de resultado do teste para NUnitSet Test Result Format to NUnit
  2. Defina os Arquivos de resultados de teste para InfraDNS/Tests/Results/*.xmlSet Test Results Files to InfraDNS/Tests/Results/*.xml
  3. Defina o Título da execução de teste para Unit.Set Test Run Title to Unit.
  4. Verifique se as Opções de controle Habilitado e Sempre executar estão selecionadas.Make sure Control Options Enabled and Always run are both selected.

Essa etapa de build executa os testes de unidade no script Pester que vimos anteriormente e armazena os resultados na pasta InfraDNS/Tests/Results/*.xml.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.

Copiar arquivosCopy Files

  1. Adicione cada uma das linhas a seguir em Conteúdo:Add each of the following lines to Contents:

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

Esta etapa copia os scripts de build e de teste no diretório de preparo para que eles possam ser publicados como artefatos de build na próxima etapa.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.

Publicar artefatoPublish Artifact

  1. Defina o Caminho para publicar para $(Build.ArtifactStagingDirectory)\Set Path to Publish to $(Build.ArtifactStagingDirectory)\
  2. Defina o Nome do artefato para DeploySet Artifact Name to Deploy
  3. Defina o Tipo de artefato para ServerSet Artifact Type to Server
  4. Selecione Enabled em Opções de controleSelect Enabled in Control Options

Habilitar integração contínuaEnable continuous integration

Agora vamos definir um gatilho que faz com que o projeto seja compilado sempre que uma alteração for verificada na ramificação ci-cd-example do repositório git.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. No TFS, clique na guia Build e versãoIn TFS, click the Build & Release tab
  2. Selecione a definição de build DNS Infra e, em seguida, clique em EditarSelect the DNS Infra build definition, and click Edit
  3. Clique na guia GatilhosClick the Triggers tab
  4. Selecione CI (integração contínua) e selecione refs/heads/ci-cd-example na lista suspensa da ramificaçãoSelect Continuous integration (CI), and select refs/heads/ci-cd-example in the branch drop-down list
  5. Clique em Salvar e em OKClick Save and then OK

Agora qualquer alteração no repositório git do TFS vai disparar um build automatizado.Now any change in the TFS git repository triggers an automated build.

Criar a definição de versãoCreate the release definition

Vamos criar uma definição de versão para que o projeto seja implantado no ambiente de desenvolvimento com cada verificação de código.Let's create a release definition so that the project is deployed to the development environment with every code check-in.

Para fazer isso, adicione uma nova definição de versão associada à definição de build InfraDNS que você criou anteriormente.To do this, add a new release definition associated with the InfraDNS build definition you created previously. Assegure-se de selecionar Implantação contínua para que uma nova versão seja disparada sempre que um novo build for concluído.Be sure to select Continuous deployment so that a new release will be triggered any time a new build is completed. [How to: Work with release definitions (Instruções: trabalhar com definições de versão)] e configure da seguinte maneira:(How to: Work with release definitions) and configure it as follows:

Adicione as seguintes etapas na definição de versão:Add the following steps to the release definition:

  • Script do PowerShellPowerShell Script
  • Publicar resultados de testePublish Test Results
  • Publicar resultados de testePublish Test Results

Edite as etapas da seguinte maneira:Edit the steps as follows:

Script do PowerShellPowerShell Script

  1. Defina o campo Caminho de script para $(Build.DefinitionName)\Deploy\initiate.ps1"Set the Script Path field to $(Build.DefinitionName)\Deploy\initiate.ps1"
  2. Defina o campo Argumentos para -fileName DeploySet the Arguments field to -fileName Deploy

Primeiro publicar resultados de testeFirst Publish Test Results

  1. Selecione NUnit para o campo Formato de resultado do testeSelect NUnit for the Test Result Format field
  2. Defina o campo Arquivos de resultados do teste para $(Build.DefinitionName)\Deploy\InfraDNS\Tests\Results\Integration*.xmlSet the Test Result Files field to $(Build.DefinitionName)\Deploy\InfraDNS\Tests\Results\Integration*.xml
  3. Defina o Título da execução de teste para IntegrationSet the Test Run Title to Integration
  4. Em Opções de controle, marque Sempre executarUnder Control Options, check Always run

Segundo publicar resultados de testeSecond Publish Test Results

  1. Selecione NUnit para o campo Formato de resultado do testeSelect NUnit for the Test Result Format field
  2. Defina o campo Arquivos de resultados do teste para $(Build.DefinitionName)\Deploy\InfraDNS\Tests\Results\Acceptance*.xmlSet the Test Result Files field to $(Build.DefinitionName)\Deploy\InfraDNS\Tests\Results\Acceptance*.xml
  3. Defina o Título da execução de teste para AcceptanceSet the Test Run Title to Acceptance
  4. Em Opções de controle, marque Sempre executarUnder Control Options, check Always run

Verifique os resultadosVerify your results

Agora, sempre que você enviar alterações por push na ramificação ci-cd-example para o TFS, será iniciado um novo build.Now, any time you push changes in the ci-cd-example branch to TFS, a new build will start. Se o build for concluído com êxito, uma nova implantação será disparada.If the build completes successfully, a new deployment is triggered.

Você pode verificar o resultado da implantação, abrindo um navegador no computador cliente e navegando para 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.

Próximas etapasNext steps

Este exemplo configura o servidor DNS TestAgent1 para que a URL www.contoso.com seja resolvida para TestAgent2, mas na verdade isso não implanta um site.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. O esqueleto para fazer isso é fornecido no repositório na pasta WebApp.The skeleton for doing so is provided in the repo under the WebApp folder. Você pode usar os stubs fornecidos para criar scripts psake, testes do Pester e configurações DSC para implantar seu próprio site.You can use the stubs provided to create psake scripts, Pester tests, and DSC configurations to deploy your own website.