Exercício – Criar uma solicitação de pull

12 minutos

Nesta unidade, você vai colocar em prática o processo de enviar uma solicitação de pull e mesclar suas alterações no branch main para que todos possam se beneficiar de seu trabalho.

Em Criar um pipeline de build com o Azure Pipelines, você criou um GIT branch chamado build-pipeline, no qual definiu um pipeline de build básico para o site do Space Game. Lembre-se de que sua definição de build fica em um arquivo chamado azure-pipelines.yml.

Embora seu branch produza um artefato de compilação, esse trabalho existe somente no branch build-pipeline. Você precisa mesclar seu branch no branch main.

Lembre-se que uma solicitação de pull informa aos outros desenvolvedores que você tem código pronto para revisão, se necessário, e que deseja que suas alterações sejam mescladas a outro branch, como o branch main.

Antes de começar, vamos conferir o que Clara e Paulo estão fazendo.

Paulo: Olá, Clara. Sei que você tem um pipeline de build em execução no Azure. Estou adicionando um recurso ao site e quero ver o processo de build. Estamos prontos para fazer isso?

Clara: Com certeza. Eu criei o pipeline em um branch. Por que não criamos uma solicitação de pull e a mesclamos a main para que você também possa usar o pipeline?

Paulo: Parece ótimo. Vamos conferir isso.

Criar um branch e adicionar o código inicial

Embora você possa usar o pipeline de build criado no módulo anterior, vamos criar um branch, chamado code-workflow. Esse branch é baseado em main, para que você possa praticar o processo desde o início.

No Visual Studio Code, abra o terminal integrado.
Alterne para o branch main:
```
git checkout main
```
Verifique se você tem a versão mais recente do código no GitHub:
```
git pull origin main
```
Crie um branch chamado code-workflow:
```
git checkout -B code-workflow
```
O argumento -b especifica que um novo branch deverá ser criado se ele não existir. Omita o argumento -b quando quiser alternar para um branch existente.

Por padrão, o novo branch é baseado no branch anterior em que você executou o comando git checkout. Aqui, o branch pai é main, mas o branch pai pode ser outro, como um branch de recurso iniciado por outra pessoa que você deseja usar como base ou para fazer experimentos.

Agora, é seguro fazer qualquer alteração necessária, porque você está em seu próprio branch local. Se quiser ver qual branch você está usando, execute git branch -v.

No Explorador de Arquivos, abra azure-pipelines.yml e substitua seu conteúdo por isto:

trigger:
- '*'

pool:
  vmImage: 'ubuntu-20.04'
  demands:
  - npm

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Build the project - $(buildConfiguration)'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration $(buildConfiguration)'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - $(buildConfiguration)'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

Essa configuração é semelhante à básica que você criou no módulo anterior. Para fins de brevidade, ela cria apenas a configuração de Versão do seu projeto.

Efetuar push do branch para o GitHub

Aqui, você efetuará push do seu branch code-workflow para o GitHub e verá o Azure Pipelines compilar o aplicativo.

No terminal, execute git status para ver qual trabalho não confirmado existe em seu branch:
```
git status
```
Você verá que o azure-piplines.yml foi modificado. Você fará o commit dessas modificações no branch em breve, mas primeiro precisará garantir que o Git esteja acompanhando esse arquivo, o que é chamado de preparo do arquivo.

Somente as alterações preparadas são confirmadas quando você executa git commit. Em seguida, execute o comando git add para adicionar azure-pipelines.yml à área de preparo ou ao índice.
Execute o seguinte git add comando para adicionar o azure-piplines.yml à área de preparo:
```
git add azure-pipelines.yml
```
Execute o comando git commit a seguir para fazer commit do arquivo preparado no branch code-workflow:
```
git commit -m "Add the build configuration"
```
O argumento -m especifica a mensagem de confirmação. A mensagem de confirmação se torna parte do histórico do arquivo alterado. Ela ajuda os revisores a entenderem a alteração e ajuda futuros profissionais responsáveis pela manutenção a entender como o arquivo foi alterado ao longo do tempo.

Dica

As melhores mensagens de confirmação completam a frase "Se aplicar este commit, você vai..."

Se você omitir o argumento -m, o Git abrirá um editor de texto no qual é possível detalhar a alteração. Esta opção é útil quando você quer especificar uma mensagem de confirmação que abrange várias linhas. O texto até a primeira linha em branco especifica o título de confirmação.
Execute o comando git push para efetuar push (ou fazer upload) do branch code-workflow para seu repositório no GitHub:
```
git push origin code-workflow
```
Como uma etapa opcional, acesse o seu projeto no Azure Pipelines e rastreie o build à medida que ele é executado.

Esse build é chamado de build de CI. Sua configuração de pipeline usa o que chamamos de um gatilho para controlar quais branches participam do processo de build. Aqui, "*" especifica todos os branches.
```
trigger:
- '*'
```
Posteriormente, você verá como controlar sua configuração de pipeline para compilar apenas dos branches de que você precisa.

Você verá que o build é concluído com êxito e produz um artefato que contém o aplicativo Web criado.

Criar uma solicitação de pull

Aqui, você criará uma solicitação de pull para seu branch:

Em um navegador, entre no GitHub.
Acesse o repositório mslearn-tailspin-spacegame-web.
Na lista suspensa Branch, selecione seu branch code-workflow.
Para iniciar sua solicitação de pull, selecione Contribuir e Abrir solicitação de pull.
Verifique se a base especifica seu repositório bifurcado, e não o repositório da Microsoft.

Sua seleção tem a seguinte aparência:

Importante

Essa etapa é importante porque você não poderá mesclar suas alterações ao repositório da Microsoft. O repositório base deve apontar para sua conta do GitHub, e não para MicrosoftDocs.

Se você terminar com uma solicitação de pull no MicrosoftDocs, basta fechar a solicitação e repetir essas etapas.

Esse processo envolve uma etapa extra porque você está trabalhando em um repositório bifurcado. Quando você trabalha diretamente com seu próprio repositório, não com uma bifurcação, seu branch main é selecionado por padrão.
Insira um título e uma descrição para sua solicitação de pull.
- Título:
  
  Configurar o Azure Pipelines
- Descrição:
  
  Esta configuração de pipeline compila o aplicativo e produz um build para a configuração de Versão.
Para concluir sua solicitação de pull, selecione Criar solicitação de pull.

Esta etapa não mescla nenhum código. Ele informa a outras pessoas que você propôs alterações a serem mescladas no branch main.

A janela de solicitação de pull é exibida. Você pode ver que o status do build no Azure Pipelines está configurado para aparecer como parte da solicitação de pull. Dessa forma, você e outras pessoas podem visualizar o status do build enquanto ele está em execução.

Assim como quando você efetua push de um branch para o GitHub, uma solicitação de pull, por padrão, dispara o Microsoft Azure Pipelines para criar seu aplicativo.

Dica

Se o status do build não for exibido imediatamente, aguarde alguns minutos ou atualize a página.
Como etapa opcional, clique no link Detalhes e rastreie o build à medida que ele percorre o pipeline.

Você pode passar o build para a próxima etapa do processo, por exemplo, a garantia de qualidade. Mais tarde, você poderá configurar o pipeline para efetuar push de sua alteração até o laboratório de garantia de qualidade ou a produção.
Volte para a solicitação de pull no GitHub.

Aguarde a conclusão do build. Agora, você está pronto para mesclar a solicitação de pull.
Selecione Mesclar solicitação pull e escolha Confirmar mesclagem.
Para excluir o branch code-workflow do GitHub, selecione Excluir branch.

É completamente seguro excluir um branch do GitHub depois de mesclar a solicitação de pull. Na verdade, trata-se de uma prática comum, porque o branch deixa de ser necessário. As alterações são mescladas e você ainda pode encontrar os detalhes sobre as alterações no GitHub ou usando a linha de comando. Excluir um branch mesclado também ajuda outras pessoas a ver apenas o trabalho que está ativo no momento.

GIT branches devem ser de curta duração. Após mesclar um branch, não efetue push de commits adicionais para ele nem o mescle novamente. Na maioria dos casos, sempre que você começa um novo recurso ou correção de bug, faz isso com um branch limpo baseado no branch main.

Excluir um branch no GitHub não o exclui de seu sistema local. Para fazer isso, você passaria o switch -d para o comando git branch.

Quantas vezes uma alteração é compilada?

A resposta depende da forma como sua configuração de build está definida. O Azure Pipelines permite que você defina gatilhos que especificam quais eventos causam compilações. Você pode controlar quais branches são compilados ou até mesmo quais arquivos disparam a compilação.

Por exemplo, digamos que você queira que um build aconteça quando uma alteração for enviada por push ao GitHub em qualquer GIT branch. No entanto, você não quer que o build ocorra quando as únicas alterações forem em arquivos da pasta docs de seu projeto. Talvez seja interessante incluir esta seção trigger em sua configuração de build:

trigger:
  branches:
    include:
    - '*'     # build all branches
  paths:
    exclude:
    - docs/*  # exclude the docs folder

Por padrão, um build é disparado quando uma alteração é enviada por push para qualquer arquivo em qualquer branch.

Um build de CI (integração contínua) é executado quando você efetua push de uma alteração para um branch.

Um build de PR (solicitação de pull) é executado quando você abre uma solicitação de pull ou quando efetua push de alterações adicionais para uma solicitação de pull existente.

As alterações feitas usando o branch code-workflow são compiladas sob três condições:

Um build de CI acontece quando você envia alterações por push para o branch code-workflow.
Um build de PR acontece quando você abre uma solicitação de pull no branch code-workflow referente ao branch main.
Um build de CI final ocorre depois que a solicitação de pull é mesclada ao branch main.

Os builds de PR ajudam a verificar se as alterações propostas funcionarão corretamente após serem mescladas a main ou a outro branch de destino.

O build de CI final verifica se as alterações ainda são válidas após a PR ser mesclada.

Como etapa opcional, vá até o Azure Pipelines e observe o build de CI final acontecer no branch main.

Exercício – Criar uma solicitação de pull

Criar um branch e adicionar o código inicial

Efetuar push do branch para o GitHub

Criar uma solicitação de pull

Quantas vezes uma alteração é compilada?

Comentários