Exercício – Criar um pedido Pull
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.
Em Criar um pipeline de compilação com o Azure Pipelines, você criou uma ramificação do Git chamada build-pipeline
, onde definiu um pipeline de compilação básico para o site do Jogo Espacial. Lembre-se de que sua definição de compilação está em um arquivo chamado azure-pipelines.yml.
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 uma solicitação pull informa aos outros desenvolvedores que você tem o código pronto para revisão, se necessário, e deseja que suas alterações sejam mescladas em outra ramificação, como a main
ramificação.
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: Com certeza. 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 em sua ramificação em breve, mas primeiro precisa garantir que o Git esteja rastreando esse arquivo, que é chamado de preparo do arquivo.
Somente alterações em estágios são confirmadas quando você executa
git commit
o . Em seguida, execute ogit add
comando 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 nacode-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 acode-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 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, basta fechar a solicitação pull e repetir 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 o Azure Pipelines
Descrição:
Essa configuração de pipeline cria o aplicativo e produz uma compilação para a configuração de versão.
Para concluir sua solicitação pull, selecione Create pull request.
Este passo não intercala 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, rastreie a compilação à medida que ela se move 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 intercaladas e ainda é possível encontrar os detalhes sobre as alterações no GitHub ou na linha de comandos. 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 comandogit branch
.
Quantas vezes é compilada uma alteração?
A resposta depende de como está definida a configuração de compilação. O Azure Pipelines permite-lhe definir acionadores que especificam que eventos fazem com que as compilações ocorram. 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 compilação de solicitação pull (PR) é uma compilação que é executada quando você abre uma solicitação pull ou quando você envia por push alterações adicionais para uma solicitação pull 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 ramomain
. - 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 que forem mescladas com main
outra 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.