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.

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 de que um pull request informa aos outros desenvolvedores que você tem código pronto para revisão, se necessário, e deseja que suas alterações sejam integradas em outro ramo, como o ramo main.

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

Andy: Olá, Mara. 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 compilação eu mesmo. Estamos prontos para fazer isso?

Mara: Absolutamente. 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?

Andy: Parece ótimo. Vamos dar uma olhada.

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 branch local. Se quiser ver qual branch está usando, execute git branch -v.

No explorador de arquivos, abra azure-pipelines.yml e substitua seu conteúdo por isso:

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 resumir, 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 no branch:
```
git status
```
Você verá que azure-pipelines.yml foi modificado. Você confirmará isso no seu branch em breve, mas primeiro precisará garantir que o Git esteja acompanhando esse arquivo, 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 commit 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 este comando git push para efetuar push (ou fazer upload) do branch code-workflow em seu repositório no GitHub:
```
git push origin code-workflow
```
Como uma etapa opcional, acesse o projeto no Azure Pipelines e rastreie o build à medida que ele é executado.

Esta compilação é chamada de compilação de CI. Sua configuração de pipeline usa o que é chamado de gatilho para controlar quais branches participam do processo de compilação. Aqui, “*” especifica todos os branches.
```
trigger:
- '*'
```
Posteriormente, você verá como controlar sua configuração de pipeline para compilar apenas dos branches de que 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.
Vá para 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 , em seguida, Abra a solicitação de pull.
Verifique se a base especifica o repositório bifurcado e não o repositório da Microsoft.

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

Importante

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

Se você concluir uma solicitação de pull request contra o MicrosoftDocs, feche a solicitação de solicitação de pull e repita essas etapas.

Esse processo envolve uma etapa extra porque você está trabalhando em um repositório com fork. 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 a pull request.
- Título:
  
  Configurar Azure Pipelines
- Descrição:
  
  Essa configuração de pipeline compila o aplicativo e produz uma compilação para a configuração de Release.
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 da pull request será exibida. Você pode ver que o status do build no Azure Pipelines está configurado para aparecer como parte da pull request. 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 pull request, por padrão, dispara o Microsoft Azure Pipelines para compilar seu aplicativo.

Dica

Se o status do build não for exibido imediatamente, aguarde alguns minutos ou atualize a página.
Opcionalmente, selecione o link Detalhes e, em seguida, rastreie a compilação conforme ela se move pelo 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 à pull request no GitHub.

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

É completamente seguro excluir um branch do GitHub depois de mesclar a pull request. 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 na 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 definir gatilhos que especificam quais eventos fazem com que os builds ocorram. 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. Mas você não quer que o build aconteça quando as únicas alterações forem nos arquivos na pasta de documentos do 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.

Uma compilação de integração contínua (CI) é executada quando você efetua push de uma alteração para um branch.

Uma compilação de solicitação de pull (PR) é executada quando você abre uma solicitação de pull ou quando efetua push das 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.

As compilações de PR o 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.

Comentários

Esta página foi útil?