Você aprendeu os comandos do Git, mas quer imaginar como a integração contínua (CI) funciona na realidade? Ou talvez você queira otimizar suas atividades diárias? Este curso lhe dará habilidades práticas em integração contínua usando um repositório GitHub. Este curso não pretende ser um assistente no qual você pode simplesmente clicar; pelo contrário, você realizará as mesmas ações que as pessoas realmente realizam no trabalho, da mesma maneira que o fazem. Explicarei a teoria à medida que você seguir as etapas envolvidas.

O que nós fazemos?

À medida que avançamos, criaremos gradualmente uma lista de etapas típicas do CI, o que é uma ótima maneira de lembrar essa lista. Em outras palavras, criaremos uma lista de ações que os desenvolvedores realizam ao fazerem integração contínua, fazendo integração contínua. Também usaremos um conjunto simples de testes para aproximar nosso processo de CI do real.

Este GIF mostra esquematicamente os commits em seu repositório conforme você avança no curso. Como você pode ver, não há nada complicado aqui e apenas o mais necessário.

Você passará pelos seguintes cenários de CI padrão:

• Trabalhe em um recurso;
• Aplicação de testes automatizados para garantir qualidade;
• Implementação da tarefa prioritária;
• Resolução de conflitos na fusão de filiais (mesclar conflito);
• Ocorre um erro em um ambiente de produção.

O que você vai aprender?

Você será capaz de responder às seguintes perguntas:

• O que é integração contínua (CI)?
• Que tipos de testes automatizados são usados ​​na CI e em resposta a quais ações eles são acionados?
• O que são solicitações pull e quando são necessárias?
• O que é Test Driven Development (TDD) e como ele se relaciona com CI?
• Devo mesclar ou refazer as alterações?
• Reverter ou corrigir na próxima versão?

No início traduzi coisas como “pull requests” em todos os lugares, mas como resultado decidi retornar frases em inglês em alguns lugares para reduzir o grau de loucura do texto. Às vezes usarei “programador surzhik” como o maravilhoso verbo “commit”, onde as pessoas realmente o usam no trabalho.

O que é integração contínua?

Integração contínua, ou CI, é uma prática técnica em que cada membro da equipe integra seu código em um repositório comum pelo menos uma vez por dia, e o código resultante deve pelo menos ser construído sem erros.

Existem divergências sobre este termo

O ponto de discórdia é a frequência da integração. Alguns argumentam que mesclar código apenas uma vez por dia não é suficiente para realmente integrar continuamente. É dado um exemplo de uma equipe onde todos pegam o código novo pela manhã e o integram uma vez à noite. Embora esta seja uma objecção razoável, acredita-se geralmente que a definição de uma vez por dia é razoavelmente prática, específica e adequada para equipas de diferentes tamanhos.

Outra objeção é que C++ não é mais a única linguagem usada no desenvolvimento e simplesmente exigir montagem sem erros como forma de validação é fraco. Alguns conjuntos de testes (por exemplo, testes unitários executados localmente) também devem ser concluídos com êxito. No momento, a comunidade está caminhando para tornar isso um requisito e, no futuro, "build + testes unitários" provavelmente se tornará uma prática comum, se é que ainda não o fez.

Integração contínua diferente de entrega contínua (Entrega Contínua, CD), pois não requer um release candidate após cada ciclo de integração.

Lista de etapas que usaremos ao longo do curso

1. Extraia o código mais recente. Crie uma ramificação de master. Comece a trabalhar.
2. Crie commits em seu novo branch. Crie e teste localmente. Passar? Vá para a próxima etapa. Falhar? Corrija erros ou testes e tente novamente.
3. Envie para seu repositório remoto ou branch remoto.
4. Crie uma solicitação pull. Discuta as mudanças, adicione mais commits à medida que a discussão continua. Faça os testes passarem no ramo de recursos.
5. Mesclar/rebase commits do master. Faça os testes passarem no resultado da mesclagem.
6. Implante da ramificação do recurso para a produção.
7. Se tudo estiver bem em produção por algum período de tempo, mescle as alterações no master.

️ Preparação

Certifique-se de ter o software certo

Para fazer este curso você precisará Node.js и Cliente Git.

Você pode usar qualquer cliente Git, mas fornecerei apenas comandos para a linha de comando.

Certifique-se de ter um cliente Git instalado que suporte a linha de comando

Se você ainda não possui um cliente Git que suporte a linha de comando, você pode encontrar instruções de instalação aqui.

Prepare o repositório

Você precisará criar uma cópia pessoal (fork) repositório de modelos com código para o curso no GitHub. Vamos concordar em chamar esta cópia pessoal repositório do curso.

Feito? Se você não alterou as configurações padrão, o repositório do seu curso provavelmente se chamará continuous-integration-team-scenarios-students, ele está localizado na sua conta GitHub e o URL é semelhante a este

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

Vou simplesmente ligar para este endereço <URL репозитория>.

Colchetes angulares como <тут> significará que você deve substituir tal expressão pelo valor apropriado.

Certifique-se de que Ações do GitHub incluído para este repositório do curso. Se eles não estiverem habilitados, habilite-os clicando no botão grande no meio da página, que você pode acessar clicando em Ações na interface do GitHub.

Você não poderá concluir o curso seguindo minhas instruções se o GitHub Actions não estiver habilitado.

Você sempre pode usar a capacidade do GitHub de renderizar Markdown para ver o estado atual da lista que estamos compondo aqui

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

Sobre as respostas

Embora a melhor maneira de concluir este curso seja fazê-lo sozinho, você pode ter algumas dificuldades.

Se você acha que não entende o que fazer e não pode continuar, você pode dar uma olhada no tópico solution, que está em seu repositório inicial.
Por favor, não mescle solution в master durante o curso. Você pode usar esse branch para descobrir o que fazer ou para comparar seu código com o do autor, usando todos os recursos que o Git nos oferece. Se você estiver completamente perdido, poderá substituir completamente sua filial master em um galho solution e, em seguida, redefina seu diretório de trabalho para a etapa do curso necessária.

Só use isso se você realmente precisar

Confirme seu código

git add .
git commit -m "Backing up my work"

Esses comandos

• renomear master в master-backup;
• renomear solution в master;
• check-out para uma nova filial master e reescrever o conteúdo do diretório de trabalho;
• Crie uma ramificação "solução" a partir de "mestre" (que costumava ser "solução") caso você precise de uma ramificação "solução" no futuro.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

Após essas etapas você pode usar git log master para descobrir qual commit você precisa.
Você pode redefinir seu diretório de trabalho para este commit assim:

git reset --hard <the SHA you need>

Se você estiver satisfeito com o resultado, em algum momento você precisará publicar sua versão do repositório em um repositório remoto. Não se esqueça de especificar explicitamente a ramificação remota ao fazer isso.

git push --force origin master

Observe que usamos git push --force. É improvável que você queira fazer isso com muita frequência, mas temos um cenário muito específico aqui com um usuário do repositório que, além disso, entende o que está fazendo.

Começando a trabalhar

Vamos começar a compilar nossa lista de etapas de CI. Normalmente você iniciaria esta etapa verificando a versão mais recente do código do repositório remoto, mas ainda não temos um repositório local, então, em vez disso, clonamos-o do repositório remoto.

️ Tarefa: atualize o repositório local, crie um branch de master, comece a trabalhar

1. Clone o repositório do curso de <URL репозитория>.
2. Executar npm install no diretório do repositório do curso; Precisamos dele para instalar o Jest, que usamos para executar testes.
3. Crie um branch e nomeie-o feature. Mude para este tópico.

4. Adicione o código de teste a ci.test.js entre comentários me pedindo para fazer isso.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Adicione texto com as primeiras 4 etapas ao arquivo ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   Equipes

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

Crie commits em um novo branch, construa e teste localmente

Vamos configurar os testes para serem executados antes do commit e depois confirmar o código.

Cenários típicos quando os testes são executados automaticamente

• Localmente:
  • Continuamente ou em resposta a alterações de código apropriadas;
  • Ao salvar (para linguagens interpretadas ou compiladas por JIT);
  • Durante a montagem (quando é necessária compilação);
  • Ao confirmar;
  • Ao publicar em um repositório compartilhado.

• No servidor de compilação ou ambiente de compilação:
  • Quando o código é publicado em uma filial/repositório pessoal.
  • O código neste tópico está sendo testado.
  • O resultado potencial da fusão é testado (geralmente com master).
  • Como um estágio de integração contínua/pipeline de entrega contínua

Normalmente, quanto mais rápido um conjunto de testes for executado, mais frequentemente você poderá executá-lo. Uma distribuição de palco típica pode ser assim.

• Testes de unidade rápidos – durante a construção, no pipeline de CI
• Testes unitários lentos, testes rápidos de componentes e integração - no commit, no pipeline de CI
• Testes lentos de componentes e integração – no pipeline de CI
• Testes de segurança, testes de carga e outros testes demorados ou caros - em pipelines de CI/CD, mas apenas em determinados modos/estágios/pipelines da construção, por exemplo, ao preparar um release candidate ou ao executar manualmente.

️Tarefa

Sugiro executar os testes manualmente primeiro usando o comando npm test. Depois disso, vamos adicionar um git hook para executar nossos testes no commit. Há um problema: os ganchos Git não são considerados parte do repositório e, portanto, não podem ser clonados do GitHub junto com o restante dos materiais do curso. Para instalar o hook você precisa executar install_hook.sh ou copie o arquivo repo/hooks/pre-commit para o diretório local .git/hooks/.
Ao confirmar, você verá que os testes são executados e eles verificam se determinadas palavras-chave estão presentes na lista.

1. Execute os testes manualmente executando o comando npm test na pasta do repositório do seu curso. Verifique se os testes foram concluídos.
2. Defina um gancho de commit (gancho de pré-commit) executando install_hook.sh.
3. Confirme suas alterações em seu repositório local.
4. Certifique-se de que os testes sejam executados antes de confirmar.

Seu repositório deve ficar assim depois de seguir estas etapas.

Equipes

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

Publicar código em um repositório remoto ou branch remoto

Depois de terminarem de trabalhar localmente, os desenvolvedores normalmente disponibilizam seu código publicamente para que ele possa eventualmente ser integrado ao público. Com o GitHub, isso normalmente é conseguido publicando o trabalho em uma cópia pessoal do repositório (fork pessoal) ou em uma ramificação pessoal.

• Com os forks, um desenvolvedor clona um repositório compartilhado remoto, criando uma cópia remota pessoal dele, também conhecida como fork. Em seguida, ele clona esse repositório pessoal para trabalhar localmente. Quando o trabalho é concluído e os commits são feitos, ele os coloca em seu fork, onde ficam disponíveis para outros e podem ser integrados ao repositório comum. Essa abordagem é comumente usada em projetos de código aberto no GitHub. Também é usado em meu curso avançado [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Outra abordagem é usar apenas um repositório remoto e contar apenas a ramificação master repositório compartilhado "protegido". Neste cenário, desenvolvedores individuais publicam seu código em ramificações de um repositório remoto para que outros possam ver esse código, se tudo estiver em ordem, mesclá-lo com master repositório compartilhado.

Neste curso específico, usaremos um fluxo de trabalho que utiliza ramificações.

Vamos publicar nosso código.

️Tarefa

• Publique alterações em uma ramificação remota com o mesmo nome da sua ramificação de trabalho

Equipes

git push --set-upstream origin feature

Crie uma solicitação pull

Crie uma solicitação pull com um título Revisão de etapas... Instalar feature como "ramo principal" e master como "ramo base".

Certifique-se de ter instalado master antes bifurcar o repositório Como “branch base”, não responderei a solicitações de alterações no repositório de materiais do curso.

No jargão do GitHub, o "ramo base" é o ramo no qual você baseia seu trabalho, e o "ramo principal" é o ramo que contém as alterações propostas.

Discuta as mudanças, adicione novos commits à medida que a discussão continua

Solicitação pull (PR)

Solicitação pull (PR) é uma forma de discutir e documentar o código, bem como conduzir a revisão do código. As solicitações pull recebem o nome da forma geral de integração de alterações individuais no código geral. Normalmente, uma pessoa clona o repositório oficial remoto do projeto e trabalha no código localmente. Depois disso ele coloca o código em seu repositório remoto pessoal e pede aos responsáveis ​​pelo repositório oficial que peguem(puxar) seu código em seus repositórios locais onde eles revisam e possivelmente integram(fundir) dele. Este conceito também é conhecido por outros nomes, por exemplo, solicitação de mesclagem.

Na verdade, você não precisa usar o recurso de solicitação pull do GitHub ou plataformas semelhantes. As equipes de desenvolvimento podem usar outros métodos de comunicação, incluindo comunicação presencial, chamadas de voz ou e-mail, mas ainda há vários motivos para usar pull requests no estilo fórum. Aqui estão alguns deles:

• discussões organizadas relacionadas a mudanças específicas de código;
• como um local para visualizar feedback sobre o trabalho em andamento de autotestadores e colegas;
• formalização de revisões de código;
• para que mais tarde você possa descobrir as razões e considerações por trás deste ou daquele trecho de código.

Normalmente você cria uma solicitação pull quando precisa discutir algo ou obter feedback. Por exemplo, se estiver trabalhando em um recurso que pode ser implementado de mais de uma maneira, você pode criar uma solicitação pull antes de escrever a primeira linha do código para compartilhar suas ideias e discutir seus planos com seus colaboradores. Se o trabalho for mais simples, um pull request é aberto quando algo já foi feito, confirmado e pode ser discutido. Em alguns cenários, talvez você queira abrir um PR apenas por motivos de controle de qualidade: para executar testes automatizados ou iniciar revisões de código. O que quer que você decida, não se esqueça de @mencionar as pessoas cuja aprovação você deseja em sua solicitação pull.

Normalmente, ao criar um PR, você faz o seguinte.

• Indique o que você propõe mudar e onde.
• Escreva uma descrição explicando o propósito das alterações. Você pode querer:
  • adicione qualquer coisa importante que não seja óbvia no código ou algo útil para entender o contexto, como #bugs relevantes e números de commit;
  • @mencione qualquer pessoa com quem você deseja começar a trabalhar ou você pode @mencioná-la nos comentários mais tarde;
  • peça ajuda aos colegas em algo ou verifique algo específico.

Depois de abrir o PR, os testes configurados para serem executados nesses casos são executados. No nosso caso, será o mesmo conjunto de testes que executamos localmente, mas em um projeto real pode haver testes e verificações adicionais.

Aguarde enquanto os testes são concluídos. Você pode ver o status dos testes na parte inferior da discussão de RP na interface do GitHub. Continue quando os testes forem concluídos.

️ Adicione uma observação sobre a aleatoriedade da lista de etapas do CI

A lista utilizada neste curso é arbitrária e subjetiva, devemos acrescentar uma observação sobre isso.

️ Tarefa: crie uma solicitação pull para este comentário

1. Mudar para filial master.
2. Crie uma ramificação chamada bugfix.
3. Adicione texto de nota ao final do arquivo ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. Confirme as alterações.
5. Publique o tópico bugfix para um repositório remoto.
6. Crie uma solicitação pull chamada Adicionando uma observação com um galho de cabeça bugfix e o ramo basemaster.

Certifique-se de ter instalado master antes bifurcar o repositório Como “branch base”, não responderei a solicitações de alterações no repositório de materiais do curso.

Esta é a aparência do seu repositório.

Equipes

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

Aprovar solicitação pull "Adicionando uma observação"

️Tarefa

1. Crie uma solicitação pull.
2. Clique em "Mesclar solicitação pull".
3. Clique em "Confirmar mesclagem".
4. Clique em "Excluir branch", não precisamos mais dele.

Este é um diagrama de commits após uma mesclagem.

️ Continue trabalhando e adicionando testes

Colaborar em uma solicitação pull geralmente resulta em trabalho adicional. Geralmente, isso é o resultado de uma revisão ou discussão de código, mas em nosso curso vamos modelar isso adicionando novos itens à nossa lista de etapas de CI.

A integração contínua normalmente envolve alguma cobertura de teste. Os requisitos de cobertura de teste variam e geralmente são encontrados em um documento chamado algo como “diretrizes de contribuição”. Manteremos as coisas simples e adicionaremos um teste para cada linha em nossa lista de verificação.

Ao executar tarefas, tente primeiro submeter os testes. Se você instalou corretamente pre-commit hook anteriormente, o teste recém-adicionado será executado, falhará e nada será confirmado. Observe que é assim que sabemos que nossos testes estão realmente testando algo. Curiosamente, se começarmos com o código antes dos testes, passar nos testes poderia significar que o código funcionou conforme o esperado ou que os testes não estavam realmente testando nada. Além disso, se não tivéssemos escrito os testes, poderíamos tê-los esquecido completamente, já que nada nos teria lembrado disso.

Desenvolvimento Orientado a Testes (TDD)

TDD recomenda escrever testes antes do código. Um fluxo de trabalho típico usando TDD é assim.

1. Adicione um teste.
2. Execute todos os testes e certifique-se de que o novo teste falhe.
3. Escreva o código.
4. Execute os testes, certifique-se de que todos os testes sejam aprovados.
5. Refatore seu código.
6. Repetir.

Como os resultados dos testes que falham geralmente são mostrados em vermelho, e aqueles que foram aprovados geralmente são mostrados em verde, o ciclo também é conhecido como refatorador vermelho-verde.

️Tarefa

Primeiro, tente submeter os testes e deixá-los falhar, depois adicione e confirme o texto da própria lista de etapas do CI. Você verá que os testes estão passando ("verde").
Em seguida, publique o novo código no repositório remoto e observe a execução dos testes na interface do GitHub na parte inferior da discussão da solicitação pull e da atualização do status do PR.

1. Mudar para filial feature.

2. Adicione esses testes a ci.test.js depois da última chamada it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Tente confirmar os testes. Se pre-commit hook estiver instalado, a tentativa de commit falhará.
4. Em seguida, adicione este texto a ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. Faça e confirme alterações localmente.
6. Publicar alterações no branch feature.

Agora você deve ter algo assim

Equipes

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

Mesclar conflito

Vá para solicitação de alteração Revisão de etapas.

Mesmo que não tenhamos feito nada de errado e os testes do nosso código tenham sido aprovados, ainda não podemos mesclar o branch feature и master. É porque o outro tópico bugfix foi fundido com master enquanto estávamos trabalhando neste PR.
Isto cria uma situação em que a filial remota master tem uma versão mais recente do que aquela em que baseamos o branch feature. Por causa disso não podemos simplesmente retroceder HEAD master até o final do tópico feature. Nesta situação, precisamos mesclar ou aplicar commits feature rebase master. Na verdade, o GitHub pode realizar mesclagens automáticas se não houver conflitos. Infelizmente, em nossa situação, ambos os ramos têm alterações concorrentes no arquivo ci.md. Esta situação é conhecida como conflito de mesclagem e precisamos resolvê-la manualmente.

Mesclar ou rebase

ir

• Cria um commit de mesclagem adicional e salva o histórico de trabalho.
  • Preserva os commits originais das ramificações com seus carimbos de data/hora e autores originais.
  • Salva o SHA de commits e links para eles em discussões de solicitação de mudança.
• Requer resolução única de conflitos.
• Torna a história não linear.
  • A história pode ser difícil de ler devido ao grande número de ramificações (que lembra um cabo IDE).
  • Torna a depuração automática mais difícil, por ex. git bisect menos útil - ele encontrará apenas o commit de mesclagem.

rebase

• Reproduz os commits do branch atual no topo do branch base, um após o outro.
  • Novos commits com novos SHAs são gerados, fazendo com que os commits no GitHub correspondam às pull requests originais, mas não aos comentários correspondentes.
  • Os commits podem ser recombinados e modificados no processo, ou até mesmo mesclados em um só.
• Vários conflitos podem precisar ser resolvidos.
• Permite que você mantenha uma história linear.
  • A história pode ser mais fácil de ler, desde que não seja muito longa sem motivo razoável.
  • A depuração e solução de problemas automáticas são um pouco mais fáceis: torna possível git bisect, pode tornar as reversões automáticas mais claras e previsíveis.
• Requer a publicação de um branch com commits migrados com um sinalizador --force quando usado com solicitações pull.

Normalmente, as equipes concordam em usar sempre a mesma estratégia quando precisam mesclar alterações. Isso poderia ser uma mesclagem "pura" ou um commit "puro" no topo, ou algo intermediário, como fazer um commit no topo interativamente(git rebase -i) localmente para ramificações não publicadas no repositório público, mas mescladas para ramificações "públicas".

Aqui usaremos mesclagem.

️Tarefa

1. Certifique-se de que o código esteja em uma filial local master atualizado a partir de um repositório remoto.
2. Mudar para filial feature.
3. Iniciar uma fusão com uma ramificação master. Um conflito de mesclagem devido a alterações concorrentes no ci.md.
4. Resolva o conflito para que nossa lista de etapas do IC e uma nota sobre ela permaneçam no texto.
5. Publicar um commit de mesclagem em uma ramificação remota feature.
6. Verifique o status da solicitação pull na UI do GitHub e aguarde até que a mesclagem seja resolvida.

Equipes

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Bom trabalho!

Você concluiu a lista e agora precisa aprovar a solicitação pull em master.

️ Tarefa: Aprovar solicitação pull "Revisão de etapas"

1. Abra uma solicitação pull.
2. Clique em "Mesclar solicitação pull".
3. Clique em "Confirmar mesclagem".
4. Clique em “Excluir branch”, pois não precisamos mais dele.

Este é o seu repositório no momento

Erro do produto

Diz-se que “os testes podem ser usados ​​para mostrar a presença de erros, mas nunca para mostrar a sua ausência”. Embora tivéssemos testes e eles não mostrassem erros, um bug insidioso entrou em produção.

Num cenário como este, precisamos cuidar de:

• o que é implantado na produção;
• código no tópico master com um erro, a partir do qual os desenvolvedores podem iniciar um novo trabalho.

Devo reverter ou corrigir na próxima versão?

Reverter é o processo de implantar uma versão anterior em bom estado para produção e reverter commits que contêm o erro. "Fixing forward" é a adição de uma correção ao master e implantar a nova versão o mais rápido possível. Como as APIs e os esquemas de banco de dados mudam à medida que o código é implantado na produção, com entrega contínua e boa cobertura de testes, a reversão normalmente é muito mais difícil e arriscada do que corrigi-lo na próxima versão.

Como reverter não traz nenhum risco no nosso caso, seguiremos esse caminho, porque nos permite

• corrija o erro no produto o mais rápido possível;
• fazer código em master imediatamente adequado para começar um novo trabalho.

️Tarefa

1. Mudar para filial master localmente.
2. Atualize o repositório local do repositório remoto.
3. Reverter o commit de mesclagem de PR Revisão de etapas в master.
4. Publique alterações em um repositório remoto.

Este é o histórico de um repositório com um commit de mesclagem revertido

Equipes

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ Autoteste

Certifique-se de que ci.md não contém mais o texto "bug sorrateiro" após reverter um commit de mesclagem.

Corrija a lista de etapas do CI e devolva-a ao mestre

Revertemos completamente o commit de mesclagem do branch. feature. A boa notícia é que agora não temos erros em master. A má notícia é que nossa preciosa lista de etapas de integração contínua também desapareceu. Então, idealmente, precisamos aplicar a correção aos commits de feature e devolvê-los para master junto com a correção.

Podemos abordar o problema de diferentes maneiras:

• reverter um commit que desfaz uma mesclagem feature с master;
• mover commits do antigo feature.

Diferentes equipes de desenvolvimento usam abordagens diferentes neste caso, mas moveremos commits úteis para um branch separado e criaremos uma solicitação pull separada para esse novo branch.

️Tarefa

1. Crie um tópico chamado feature-fix e mude para ele.

2. Migrar todos os commits do branch anterior feature para um novo tópico. Resolva conflitos de mesclagem que ocorreram durante a migração.

   

3. Adicione um teste de regressão a ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. Execute os testes localmente para garantir que eles não falhem.
5. Remova o texto "com um bug sorrateiro" em ci.md.
6. Adicione alterações de teste e alterações na lista de etapas ao índice e confirme-as.
7. Publique o branch em um repositório remoto.

Você deve acabar com algo semelhante a isto:

Equipes

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

Crie uma solicitação pull.

Crie uma solicitação pull com um título Corrigindo o recurso... Instalar feature-fix como "ramo principal" e master como "ramo base".
Aguarde enquanto os testes são concluídos. Você pode ver o status dos testes na parte inferior da discussão de relações públicas.

Certifique-se de ter instalado master antes bifurcar o repositório Como “branch base”, não responderei a solicitações de alterações no repositório de materiais do curso.

Aprovar solicitação pull "Corrigindo o recurso"

Obrigado pela correção! Por favor, aprove as alterações em master da solicitação pull.

️Tarefa

1. Clique em "Mesclar solicitação pull".
2. Clique em "Confirmar mesclagem".
3. Clique em “Excluir branch”, pois não precisamos mais dele.

Isso é o que você deveria ter no momento.

Parabéns!

Você concluiu todas as etapas que as pessoas normalmente realizam durante a integração contínua.

Se você notar algum problema com o curso ou souber como melhorá-lo, crie um problema em repositórios com materiais do curso. Este curso também tem versão interativa usando GitHub Learning Lab como plataforma.

Fonte: habr.com