Exercício – Criar um pedido Pull

12 minutos

Nesta unidade, você praticará o processo de enviar uma solicitação pull e mesclar suas alterações na main ramificação para que todos possam se beneficiar do seu trabalho.

Embora sua ramificação produza um artefato de construção, esse trabalho existe apenas na build-pipeline ramificação. Você precisa mesclar sua filial na main filial.

Lembre-se de que um pull request informa aos outros desenvolvedores que tens o código pronto para revisão, se necessário, e desejas que as tuas alterações sejam fundidas noutro branch, como o branch main.

Antes de começarmos, vamos ver o que a Teresa e o Guilherme têm para dizer.

Andy: Olá, Mara. Eu sei que tem um pipeline de compilação em execução no Azure. Estou adicionando um recurso ao site e quero ver o processo de compilação por mim mesmo. Estamos prontos para tal?

Mara: Sem dúvida. Criei o pipeline num ramo. Por que não criamos uma solicitação pull e a mesclamos para main que você também possa usar o pipeline?

Andy: Parece ótimo. Vamos dar uma vista de olhos.

Criar uma ramificação e adicionar código inicial

Embora você possa usar o pipeline de compilação criado no módulo anterior, vamos criar uma nova ramificação chamada code-workflow. Este ramo é baseado em main, para que você possa praticar o processo desde o início.

No Visual Studio Code, abra o terminal integrado.
Mude para a main filial:
```
git checkout main
```
Certifique-se de ter a versão mais recente do código do GitHub:
```
git pull origin main
```
Crie uma ramificação chamada code-workflow:
```
git checkout -B code-workflow
```
O argumento -b especifica para criar um novo ramo, caso não exista. Omita o argumento -b quando quiser mudar para um ramo existente.

Por predefinição, o novo ramo baseia-se no ramo anterior de onde executou o comando git checkout. Aqui, a ramificação pai é main, mas a ramificação pai pode ser outra, como uma ramificação de recurso iniciada por outra pessoa que você deseja desenvolver ou experimentar.

Agora é seguro fazer as alterações necessárias, porque você está em sua própria filial local. Se você quiser ver em qual ramificação você está, execute git branch -v.

No explorador de ficheiros, abra azure-pipelines.yml e substitua o seu conteúdo pelo seguinte:

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()

Esta configuração é semelhante à básica que você criou no módulo anterior. Para maior brevidade, ele cria apenas a configuração Release do seu projeto.

Emitir o ramo para o GitHub

Aqui, você enviará sua filial para o GitHub e verá o code-workflow Azure Pipelines criar o aplicativo.

No terminal, corra git status para ver que trabalho não comprometido existe na sua filial:
```
git status
```
Você verá que azure-pipelines.yml foi modificado. Você confirmará isso na sua ramificação em breve, mas primeiro precisa garantir que o Git esteja rastreando este arquivo, chamado staging.

Somente alterações em estágios são confirmadas quando você executa git commito . Em seguida, execute o comando git add para adicionar azure-pipelines.yml à área de preparo ou índice.
Execute o seguinte git add comando para adicionar azure-pipelines.yml à área de preparação.
```
git add azure-pipelines.yml
```
Execute o seguinte git commit comando para confirmar seu arquivo em estágios na code-workflow ramificação:
```
git commit -m "Add the build configuration"
```
O argumento -m especifica a mensagem de consolidação. A mensagem de consolidação torna-se parte do histórico de um ficheiro alterado. Ele ajuda os revisores a entender a alteração e ajuda os futuros mantenedores a entender como o arquivo mudou ao longo do tempo.

Gorjeta

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

Se omitir o argumento -m, o Git apresentará um editor de texto onde poderá detalhar a alteração. Esta opção é útil quando pretender especificar uma mensagem de consolidação que abrange várias linhas. O texto até à primeira linha em branco especifica o título de consolidação.
Execute este git push comando para enviar ou carregar a code-workflow ramificação para seu repositório no GitHub:
```
git push origin code-workflow
```
Como uma etapa opcional, vá para seu projeto no Azure Pipelines e rastreie a compilação enquanto ela é executada.

Essa compilação é chamada de compilação CI. Sua configuração de pipeline usa o que é chamado de gatilho para controlar quais ramificações participam do processo de compilação. Aqui, "*" especifica todas as ramificações.
```
trigger:
- '*'
```
Mais tarde, você verá como controlar a configuração do pipeline para construir apenas a partir das ramificações necessárias.

Você verá que a compilação é concluída com êxito e produz um artefato que contém o aplicativo Web compilado.

Criar um pedido Pull

Aqui, você criará uma solicitação pull para sua filial:

Em um navegador, faça login no GitHub.
Vá para o repositório mslearn-tailspin-spacegame-web .
Na lista suspensa Ramo, selecione a sua code-workflow filial.
Para iniciar sua solicitação pull, selecione Contribute e, em seguida, Open pull request.
Certifique-se de que a base especifica seu repositório bifurcado e não o repositório da Microsoft.

A sua seleção tem o seguinte aspeto:

Importante

Esta etapa é importante porque você não pode mesclar suas alterações no repositório da Microsoft. Certifique-se de que o repositório base aponte para sua conta do GitHub e não para o MicrosoftDocs.

Se você acabar com uma solicitação pull contra o MicrosoftDocs, feche a solicitação pull e repita essas etapas.

Esse processo envolve uma etapa extra porque você está trabalhando a partir de um repositório bifurcado. Quando trabalha diretamente com o seu próprio repositório e não com um fork, o ramo main está selecionado por predefinição.
Insira um título e uma descrição para o seu pull request.
- Título:
  
  Configurar Pipelines do Azure
- Descrição:
  
  Esta configuração de pipeline cria a aplicação e gera uma compilação para a configuração de lançamento.
Para concluir sua solicitação pull, selecione Create pull request.

Esta etapa não mescla nenhum código. Ele diz aos outros que você propôs mudanças para serem fundidas no main ramo.

A janela pull request é exibida. Você pode ver que o status da compilação no Azure Pipelines está configurado para aparecer como parte da solicitação pull. Dessa forma, você e outras pessoas podem visualizar o status da compilação enquanto ela está sendo executada.

Assim como quando você envia uma ramificação para o GitHub, uma solicitação pull, por padrão, aciona o Microsoft Azure Pipelines para criar seu aplicativo.

Gorjeta

Se você não vir o status da compilação aparecer imediatamente, aguarde alguns momentos ou atualize a página.
Opcionalmente, selecione o link Detalhes e, em seguida, acompanhe a compilação à medida que ela avança pelo pipeline.

Pode transferir a compilação para a fase seguinte do processo, como o controlo de qualidade. Mais tarde, pode configurar o pipeline para emitir a sua alteração para o laboratório de controlo de qualidade ou produção.
Volte para sua solicitação pull no GitHub.

Aguarde a conclusão da compilação. Agora, está pronto para intercalar o pedido Pull.
Selecione Mesclar solicitação pull e, em seguida, selecione Confirmar mesclagem.
Para excluir a code-workflow ramificação do GitHub, selecione Excluir ramificação.

É completamente seguro excluir uma ramificação do GitHub depois de mesclar sua solicitação pull. Na verdade, é uma prática comum, porque o ramo não é mais 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. A exclusão de uma ramificação mesclada também ajuda outras pessoas a verem apenas o trabalho que está ativo no momento.

Os ramos Git são feitos para serem de curta duração. Depois de mesclar uma ramificação, você não empurra confirmações adicionais para ela ou a mescla uma segunda vez. Na maioria dos casos, toda vez que você inicia um novo recurso ou correção de bug, você começa com uma ramificação limpa baseada na main ramificação.

Eliminar um ramo no GitHub não elimina esse ramo do sistema local. Para tal, teria de passar o comutador -d para o comando git branch.

Quantas vezes é compilada uma alteração?

A resposta depende de como está definida a configuração de compilação. O Azure Pipelines permite definir gatilhos que especificam quais eventos causam a ocorrência de compilações. Pode controlar que ramos são compilados ou até mesmo que ficheiros acionam a compilação.

Como exemplo, digamos que você queira que uma compilação aconteça quando uma alteração é enviada por push para o GitHub em qualquer ramificação do Git. Mas você não quer que a compilação aconteça quando as únicas alterações são nos arquivos na pasta de documentos do seu projeto. Talvez você queira incluir esta trigger seção em sua configuração de compilação:

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

Por padrão, uma compilação é acionada quando uma alteração é enviada por push para qualquer arquivo em qualquer ramificação.

Uma compilação de integração contínua (CI) é uma compilação que é executada quando você envia uma alteração para uma ramificação.

Uma build de pull request (PR) é uma build que é executada quando se abre um pull request ou se envia alterações adicionais para um pull request existente.

As alterações feitas por meio da code-workflow ramificação são feitas sob três condições:

Ocorre uma compilação CI quando envia alterações para o ramo code-workflow.
Ocorre uma compilação PR quando abre um pedido Pull no ramo code-workflow em relação ao ramo main.
Uma compilação de CI final acontece depois que a solicitação pull é mesclada à main ramificação.

As compilações de RP ajudam a verificar se as alterações propostas funcionarão corretamente depois de serem integradas em main ou noutra ramificação de destino.

A compilação CI final verifica se as alterações ainda são válidas depois de ter sido intercalado o PR.

Como uma etapa opcional, vá para Azure Pipelines e observe a compilação final de CI acontecer na main ramificação.

Feedback

Esta página foi útil?