Você aprendeu os comandos do Git, mas quer entender como a integração contínua (Continuous Integration, CI) acontece na prática? Ou talvez você queira otimizar suas ações diárias? Este curso lhe proporcionará habilidades práticas de integração contínua usando um repositório no GitHub. Este curso não foi projetado como um assistente que você pode apenas clicar, pelo contrário, você realizará as mesmas ações que as pessoas realmente fazem no trabalho, da mesma maneira que elas fazem. Eu irei explicar a teoria conforme você passará pelos passos relevantes.

O que faremos?

À medida que avançarmos, iremos gradualmente criar uma lista de passos típicos de CI, que é uma excelente maneira de memorizá-la. Em outras palavras, iremos compilar uma lista de ações que os desenvolvedores realizam ao realizar integração contínua. Também utilizaremos um conjunto simples de testes para aproximar nosso processo de CI da realidade.

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

Você irá passar por cenários padrão de CI:

• Trabalho em uma feature;
• Aplicação de testes automatizados para garantir a qualidade;
• Implementação de uma tarefa prioritária;
• Resolução de conflitos durante a mesclagem (merge conflict);
• Ocorrência de um erro em ambiente produtivo.

O que você aprenderá?

Você será capaz de responder a perguntas como:

• O que é integração contínua (CI)?
• Quais tipos de testes automatizados são usados em CI e quais ações eles disparam?
• O que é um pull request e quando eles são necessários?
• O que é desenvolvimento orientado a testes (Test Driven Development, TDD) e como isso se relaciona com CI?
• Realizar um merge ou aplicar changes via rebase?
• Reverter ou corrigir na próxima versão?

No início, traduzi expressões como 'pull request', mas acabei decidindo retornar algumas frases para o inglês em determinados lugares para reduzir a confusão no texto. Às vezes, usarei um 'portunhol' de programador, como o curioso verbo 'commitar', onde as pessoas realmente o utilizam no trabalho.

O que é integração contínua?

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

Existem divergências sobre esse termo.

O ponto de discórdia é a frequência de integração. Alguns afirmam que integrar o código apenas uma vez por dia não é suficiente; deve-se, na verdade, integrar continuamente. Um exemplo é uma equipe onde todos pegam o código atualizado pela manhã e integram uma vez à noite. Embora isso seja uma objeção razoável, em geral acredita-se que a definição "uma vez por dia" é suficientemente prática, específica e adequada para equipes de diferentes tamanhos.

Outra objeção é que C++ já não é a única linguagem usada no desenvolvimento, e o simples requisito de compilar sem erros, como forma de validação, é fraco. Um conjunto de testes (por exemplo, testes unitários, executados localmente) também deve ser bem-sucedido. Atualmente, a comunidade tende a considerar esse requisito obrigatório, e no futuro "compilação + testes unitários" provavelmente se tornará uma norma, se é que isso já não aconteceu.

Integração contínua diferencia-se de entrega contínua (Continuous Delivery, CD) por não exigir um candidato a lançamento após cada ciclo de integração.

Lista de passos que utilizaremos ao longo do curso.

1. Pule o último código. Crie uma branch a partir de master. Comece a trabalhar.
2. Crie commits na sua nova branch. Construa e teste localmente. Passou? Vá para o próximo passo. Falhou? Corrija erros ou testes e tente novamente.
3. Envie para seu repositório remoto ou branch remota.
4. Crie uma pull request. Discuta as mudanças, adicione mais commits conforme a discussão continua. Faça os testes passarem na branch de recurso.
5. Mescle/rebase commits do master. Faça os testes passarem no resultado da mesclagem.
6. Implemente da branch de recurso para a produção.
7. Se tudo estiver bem na produção por algum tempo, mescle as alterações no master.

️ Preparação

Certifique-se de ter o software necessário.

Para passar por este curso, você precisará de Node.js e um cliente Git..

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

Certifique-se de que você tenha um cliente Git instalado que suporte a linha de comando.

Se você ainda não tem um cliente Git instalado 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) do repositório modelo com o código para o curso no GitHub. Vamos concordar em chamar essa cópia pessoal de repositório do curso..

Fez? Se você não alterou as configurações padrão, seu repositório do curso provavelmente se chama continuous-integration-team-scenarios-students, ele está na sua conta do GitHub, e a URL se parece com

https://github.com//continuous-integration-team-scenarios-students

Vou me referir a esse endereço simplesmente como <URL репозитория>.

Os sinais de menor e maior como <тут> significarão que você deve substituir essa expressão pelo valor correspondente.

Certifique-se de que GitHub actions estão ativados para este repositório do curso. Se eles não estiverem ativados, por favor, ative-os clicando no grande botão no meio da página, que você pode acessar clicando em Actions na interface do GitHub.

Você não conseguirá seguir meu curso se as GitHub Actions não estiverem ativadas.

Você sempre pode usar a funcionalidade do GitHub de exibir Markdown para ver o estado atual da lista que estamos criando, aqui

https://github.com//continuous-integration-team-scenarios-students/blob/master/ci.md

Sobre as respostas

Embora a melhor maneira de completar este curso seja fazendo tudo você mesmo, você pode ter algumas dificuldades.

Se você sentir que não entende o que fazer e não consegue continuar, pode dar uma olhada na branch solution, que está no seu repositório inicial.
Por favor, não faça merge solution em master durante o curso. Você pode usar essa branch para entender o que fazer, ou para comparar seu código com o original, aproveitando todas as funcionalidades que o Git nos oferece. Se você se perder completamente, pode substituir sua branch master pela branch solution e então redefinir seu diretório de trabalho para o estágio do curso que você precisa.

Use isso apenas se for realmente necessário

Comite seu código

git add .
git commit -m "Fazendo backup do meu trabalho"

Esses comandos

• renomeiam master em master-backup;
• renomeiam solution em master;
• mudam (checkout) para a nova branch master e reescrevem o conteúdo do diretório de trabalho;
• criam a branch "solution" a partir de "master" (que antes era "solution") caso você precise da branch "solution" no futuro.

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

Após essas ações, você pode usar git log master para descobrir qual commit você precisa.
Você pode redefinir seu diretório de trabalho para esse commit assim:

git reset --hard

Se você estiver satisfeito com o resultado, em algum momento você precisará publicar suas versões do repositório em um repositório remoto. Não se esqueça de especificar claramente o ramo remoto ao fazer isso.

git push --force origin master

Por favor, note que estamos usando git push --force. É pouco provável que você queira fazer isso com frequência, mas temos um cenário bastante específico com um usuário do repositório que, além disso, entende o que está fazendo.

Começando a trabalhar

Vamos começar a elaborar nossa lista de etapas de CI. Normalmente, você começa essa etapa extraindo 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 repositório remoto.

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

1. Clone o repositório do curso a partir de <URL репозитория>.
2. Execute npm install no diretório do repositório do curso; isso é necessário para instalar o Jest, que usamos para executar os testes.
3. Crie um ramo e nomeie-o feature. Mude para esse ramo.

4. Adicione código de teste em ci.test.js entre os comentários solicitando para fazer isso.

   it('1. puxe o código mais recente', () => {
     expect(\/.*pull.*\/ig.test(fileContents)).toBe(true);
   });
   
   it('2. adicione commits', () => {
     expect(\/.*commit.*\/ig.test(fileContents)).toBe(true);
   });
   
   it('3. empurre para o ramo remoto com o mesmo nome', () => {
     expect(\/.*push.*\/ig.test(fileContents)).toBe(true);
   });
   
   it('4. crie uma solicitação de pull e continue trabalhando', () => {
     expect(\/.*pulls+request.*\/ig.test(fileContents)).toBe(true);
   });

5. Adicione o texto com os primeiros 4 passos no arquivo ci.md.

   1. Puxe o código mais recente. Crie um ramo a partir de `master`. Comece a trabalhar.    
   2. Crie commits em seu novo ramo. Construa e teste localmente.  
   Passou? Vá para a próxima etapa. Falhou? Corrija erros ou testes e tente novamente.  
   3. Empurre para seu repositório remoto ou ramo remoto.  
   4. Crie uma solicitação de pull. Discuta as mudanças, adicione mais commits  
   a medida que a discussão continua. Faça os testes passarem no ramo de funcionalidades.  

   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 no novo ramo, faça a compilação e teste localmente.

Estamos prestes a configurar os testes para que sejam executados antes do commit, e em seguida, commit o código.

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

• Localmente:
  • Constantemente ou em resposta a alterações relevantes no código;
  • Ao salvar (para linguagens interpretadas ou JIT compiladas);
  • Ao compilar (quando a compilação é necessária);
  • Ao fazer um commit;
  • Ao publicar em um repositório compartilhado.

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

Em geral, quanto mais rápido um conjunto de testes é executado, mais frequentemente você pode se permitir executá-lo. Uma distribuição típica dos estágios pode parecer assim.

• Testes de módulo rápidos - na construção, no pipeline CI
• Testes de módulo lentos, testes de componente rápidos e testes de integração - no commit, no pipeline CI
• Testes de componente lentos e testes de integração - no pipeline CI
• Testes de segurança, de carga e outros testes prolongados ou caros - nos pipelines CI / CD, mas apenas em modos / estágios / pipelines de construção específicos, como na preparação de um release candidate ou quando executados manualmente.

️ Tarefa

Eu sugiro que primeiro você execute os testes manualmente, usando o comando npm test. Depois disso, vamos adicionar um hook do git para executar nossos testes ao realizar um commit. Há uma pegadinha: hooks do Git não são considerados parte do repositório e, portanto, não podem ser clonados do GitHub junto com o restante do material do curso. Para instalar o hook, você precisa executar install_hook.sh ou copiar o arquivo repo/hooks/pre-commit para o diretório local .git/hooks/.
Ao realizar um commit, você verá que os testes estão sendo executados e eles verificam se certas palavras-chave estão presentes na lista.

1. Execute os testes manualmente, executando o comando npm test no diretório do repositório do seu curso. Certifique-se de que os testes foram executados.
2. Instale o hook no commit (pre-commit hook), executando install_hook.sh.
3. Faça o commit das alterações no repositório local.
4. Certifique-se de que os testes estão sendo executados antes do commit.

Seu repositório deve parecer assim após realizar essas ações.

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"

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

Publique o código no repositório remoto ou ramo remoto

Depois de trabalhar localmente, os desenvolvedores geralmente tornam seu código público para que possa ser, em última análise, integrado ao geral. Com o GitHub, isso geralmente é alcançado publicando o trabalho em uma cópia pessoal do repositório (fork pessoal) ou em um ramo pessoal.

• Ao usar forks, o desenvolvedor clona um repositório remoto compartilhado, criando sua própria cópia remota, 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 estão disponíveis para outros e podem ser integrados no repositório compartilhado. Essa abordagem é geralmente utilizada em projetos de código aberto no GitHub. Também é utilizada em meu curso avançado [Team Work and CI with Git]http://devops.redpill.solutions/).
• Outra abordagem é usar apenas um repositório remoto e considerar apenas o ramo master do repositório compartilhado como "protegido". Nesse cenário, os desenvolvedores individuais publicam seu código em ramos do repositório remoto, para que outros possam revisá-lo, se tudo estiver certo, mesclar com master o repositório compartilhado.

Neste curso específico, usaremos um fluxo de trabalho que utiliza ramos.

Vamos publicar nosso código.

️ Tarefa

• Publique as alterações em um ramo remoto com o mesmo nome que o seu ramo de trabalho

Equipes

git push --set-upstream origin feature

Crie um pull request

Crie um pull request com o título Revisão de etapas. Defina feature como "ramo head" e master como "ramo base".

Certifique-se de ter definido master em seu fork do repositório como "ramo base", não responderei a solicitações de alterações no repositório com materiais do curso.

No jargão do GitHub, "ramo base" é o ramo no qual você baseia seu trabalho, enquanto "ramo head" é o ramo contendo as alterações propostas.

Discuta as alterações, adicione novos commits à medida que a discussão avança

Pull request (PR)

Pull request (PR) é uma maneira de discutir e documentar o código, além de realizar a revisão do código. As pull requests são assim chamadas em homenagem à forma comum de integrar alterações individuais no código compartilhado. Normalmente, uma pessoa clona o repositório oficial remoto do projeto e trabalha no código localmente. Depois, ela coloca o código no seu repositório remoto pessoal e pede aos responsáveis pelo repositório oficial que puxempull) seu código para seus repositórios locais, onde eles revisam e, possivelmente, integrammesclar) isso. Esse conceito também é conhecido por outros nomes, como solicitação de mesclagem.

Na verdade, você não precisa usar a função de pull request do GitHub ou de plataformas semelhantes. As equipes de desenvolvedores podem usar outras formas de comunicação, incluindo conversas pessoais, chamadas de voz ou e-mails, mas ainda assim existem várias razões para usar pull requests no estilo de discussões em fórum. Aqui estão algumas delas:

• discussões organizadas relacionadas a mudanças específicas no código;
• como um local para revisar feedback de trabalhos não concluídos, tanto de testes automatizados quanto de colegas;
• formalização das revisões de código;
• para que seja possível entender posteriormente as razões e considerações por trás de um determinado fragmento de código.

Normalmente, você cria um pull request quando precisa discutir algo ou obter feedback. Por exemplo, se estiver trabalhando em uma funcionalidade que pode ser implementada de várias maneiras, você pode criar uma solicitação de mudança antes de escrever a primeira linha de código para compartilhar suas ideias e discutir seus planos com coautores. Se o trabalho for mais simples, o pull request é aberto quando algo já está feito, registrado e pode ser discutido. Em alguns cenários, você pode abrir um PR apenas por razões de controle de qualidade: para executar testes automáticos ou iniciar uma revisão de código. O que quer que você decida, não se esqueça de @mencionar pessoas cuja aprovação é necessária em seu pull request.

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

• Indica o que você propõe alterar e onde.
• Escreve uma descrição que explica o objetivo das mudanças. Você pode querer:
  • adicionar algo importante que não seja óbvio a partir do código, ou algo útil para entender o contexto, como bugs relevantes e números de commits;
  • @mencionar todos com quem gostaria de começar a trabalhar juntos, ou você pode @mencioná-los nos comentários depois;
  • pedir ajuda a colegas com algo ou revisar algo específico.

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

Por favor, aguarde enquanto os testes estão sendo concluídos. Você pode visualizar o status dos testes na parte inferior da discussão PR na interface do GitHub. Continue quando os testes forem finalizados.

️ Adicione uma nota sobre a arbitrariedade da lista de etapas do CI

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

️ Tarefa: criar um pull request para esta anotação

1. auth0 master.
2. Crie um branch com o nome bugfix.
3. Adicione o texto da nota ao final do arquivo ci.md.

   > **GitHub flow** é às vezes usado como um apelido para se referir a uma variante do desenvolvimento baseado em trunk 
   quando o código é implantado diretamente de branches de recurso. Esta lista é apenas uma interpretação 
   que eu uso em meus [cursos de DevOps](http://redpill.solutions). 
   O tutorial oficial está [aqui](https://guides.github.com/introduction/flow/).

4. Comite as alterações.
5. Publique o branch bugfix no repositório remoto.
6. Crie um pull request com o nome Adicionando uma observação com o branch principal bugfix e o branch basemaster.

Certifique-se de ter definido master em seu fork do repositório como "ramo base", não responderei a solicitações de alterações no repositório com materiais do curso.

Assim deve parecer 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 o pull request "Adicionando uma observação"

️ Tarefa

1. Crie um pull request.
2. Clique em "Merge pull request".
3. Clique em "Confirmar merge".
4. Clique em "Excluir branch", não precisamos mais dele.

Este é o gráfico de commits após a fusão.

️ Continue trabalhando e adicione testes

A colaboração em um pull request muitas vezes leva à necessidade de trabalho adicional. Normalmente, isso é resultado de uma revisão de código ou discussão, mas em nosso curso vamos simular isso, adicionando novos itens à nossa lista de etapas do CI.

Na integração contínua, geralmente se aplica alguma cobertura de teste. Os requisitos de cobertura de testes variam e geralmente estão em um documento com um título como "guias para contribuidores". Vamos fazer simples e adicionar um teste para cada linha em nossa lista de verificação.

Ao executar as tarefas, primeiro tente comitar os testes. Se você configurou corretamente o pre-commit hook anteriormente, o teste recém-adicionado será executado, não será aprovado e nada será comitado. Note que assim descobrimos que nossos testes realmente verificam algo. Curiosamente, se tivéssemos começado com o código antes dos testes, a passagem dos testes poderia significar que o código funciona como esperado ou que os testes realmente não verificam nada. Além disso, se não tivéssemos escrito testes em primeiro lugar, poderíamos esquecê-los completamente, já que nada nos lembraria disso.

Desenvolvimento guiado por testes (TDD)

TDD recomenda escrever testes antes do código. O processo típico usando TDD se parece com isto.

1. Adicione um teste.
2. Execute todos os testes e certifique-se de que o novo teste não passe com sucesso.
3. Escreva o código.
4. Execute os testes e verifique se todos passam com sucesso.
5. Refatore o código.
6. Repita.

Como os resultados dos testes que não passaram são geralmente exibidos em vermelho, enquanto os que passaram são exibidos em verde, o ciclo também é conhecido como "vermelho-verde-refatoração" (red-green-refactor).

️ Tarefa

Primeiro, tente fazer um commit dos testes e deixá-los falhar, depois adicione e comite o texto da lista de etapas CI. Você verá que os testes passam ("verdes").
Em seguida, publique o novo código no repositório remoto e veja como os testes são executados na interface do GitHub na parte inferior da discussão do pull request, e o status do PR é atualizado.

1. auth0 feature.

2. Adicione esses testes em ci.test.js após a última chamada it (...);.

   it('5. Mesclar/rebase commits do master. Faça os testes passarem no resultado da mesclagem.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Implantar do branch de recurso para produção.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. Se tudo estiver bem na produção por um período de tempo, mescle as alterações no master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Tente realizar um commit dos testes. Se pre-commit o hook estiver configurado, a tentativa de commit falhará.
4. Depois, adicione este texto em ci.md.

   5. Mesclar/rebase commits do master. Faça os testes passarem no resultado da mesclagem.  
   6. Implantar do branch de recurso com um bug oculto para produção.
   7. Se tudo estiver bem na produção por um período de tempo, mescle as alterações no master. 

5. Faça e comite as alterações localmente.
6. Publique as alterações no branch feature.

Agora você deve ter algo parecido com isto

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

Conflito de mesclagem

Vá para o pull request Revisão de etapas.

Embora não tenhamos feito nada de errado e os testes para nosso código tenham passado com sucesso, ainda não podemos realizar a mesclagem do branch feature e master. Isso acontece porque outro branch bugfix foi mesclado com master enquanto trabalhávamos neste PR.
Isso cria uma situação onde o branch remoto master tem uma versão mais nova do que aquela em que baseamos o branch feature. Por conta disso, não podemos simplesmente retroceder o HEAD master até o final do branch feature. Nessa situação, precisamos realizar um merge ou aplicar os commits feature sobre (rebase) master. O GitHub realmente pode realizar merges automáticos se não houver conflitos. Infelizmente, na nossa situação, ambas as branches têm alterações competindo no arquivo. ci.md. Essa situação é conhecida como conflito de merge, e precisamos resolvê-la manualmente.

Merge ou rebase

Merge

• Cria um commit de merge adicional e preserva o histórico de trabalho.
  • Preserva os commits originais das branches com os timestamps e autores originais.
  • Preserva os SHAs dos commits e referências a eles em discussões de pull requests.
• Exige a resolução de conflitos uma única vez.
• Torna o histórico não-linear.
  • A história pode ser difícil de ler devido ao número de branches (lembrando um cabo IDE).
  • Complica a depuração automática, por exemplo, torna git bisect menos útil — ele apenas encontrará o commit de merge.

Rebase

• Reproduz commits da branch atual sobre a base um por um.
  • Novos commits são criados com novos SHAs, resultando em commits no GitHub que estão relacionados aos pull requests originais, mas não aos comentários correspondentes.
  • Commits podem ser recombinados e alterados no processo ou até mesmo unidos em um só.
• Pode ser necessário resolver vários conflitos.
• Permite manter um histórico linear.
  • A história pode ser mais fácil de ler, a menos que seja excessivamente longa sem razões razoáveis.
  • Depuração automática e resolução de problemas são um pouco mais simples: torna possível git bisect, pode tornar rollbacks automáticos mais claros e previsíveis.
• Exige a publicação da branch com os commits transferidos com o flag --force quando usado com pull requests.

Normalmente, as equipes concordam em usar sempre a mesma estratégia ao precisar mesclar mudanças. Isso pode ser um merge "limpo" ou a aplicação "limpa" de commits sobrepostos, ou algo intermediário, como realizar a aplicação de commits em modo interativo (git rebase -i) localmente para branches não publicadas no repositório comum, mas um merge para branches "públicas".

Aqui, usaremos o merge.

️ Tarefa

1. Certifique-se de que o código na branch local master está atualizado a partir do repositório remoto.
2. auth0 feature.
3. Inicie o merge com a branch master. Um conflito de merge será reportado relacionado a mudanças competidoras em ci.md.
4. Permita o conflito de modo que o texto mantenha nossa lista de passos CI e a observação sobre ela.
5. Publique o commit de mesclagem na branch remota feature.
6. Verifique o status do pull request na interface 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, дождитесь пока слияние не будет разрешено.

Ótimo trabalho!

Você terminou de trabalhar na lista e agora precisa aprovar o pull request em master.

️ Tarefa: Aprove o pull request "Revisão dos passos"

1. Abra o pull request.
2. Clique em "Merge pull request".
3. Clique em "Confirmar merge".
4. Clique em "Deletar branch", pois não precisamos mais dela.

Este é o seu repositório no momento

Erro em produção

Dizem que "os testes podem ser usados para mostrar a presença de erros, mas nunca para mostrar a sua ausência". Apesar de termos testes e eles não terem mostrado nenhum erro, um erro traiçoeiro se infiltrou na produção.

Em um cenário como este, precisamos cuidar de:

• aquilo que está implantado em produção;
• o código na branch master com o erro, a partir do qual os desenvolvedores podem começar um novo trabalho.

Reverter ou corrigir na próxima versão?

"Reverter" (rolling back) é implantar deliberadamente uma versão anterior conhecida como estável no ambiente de produção e cancelar (revert) commits que contêm erros. "Corrigir na próxima versão" (fixing forward) é adicionar uma correção em master e implantar uma 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 no ambiente produtivo, na entrega contínua e com uma boa cobertura de testes, reverter é geralmente muito mais complicado e arriscado do que corrigir na próxima versão.

Como reverter não representa nenhum risco no nosso caso, vamos seguir por esse caminho, pois isso nos permite

• corrigir o erro em produção o mais rápido possível;
• tornar o código em master pronto para iniciar um novo trabalho imediatamente.

️ Tarefa

1. auth0 master localmente.
2. Atualize o repositório local a partir do repositório remoto.
3. Reverta o commit de mesclagem do PR Revisão de etapas em master.
4. Publique as alterações no repositório remoto.

Esta é a história do repositório com o 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

️ Autoavaliação

Verifique se ci.md não contém mais o texto "sneaky bug" após o cancelamento do commit de mesclagem.

Corrija a lista de passos CI e devolva-a ao master

Reverter totalmente o commit de mesclagem da 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 desapareceu. Portanto, idealmente, precisamos aplicar a correção aos commits de feature e retornar para master junto com a correção.

Podemos abordar a tarefa de diferentes maneiras:

• reverter o commit, que reverte a mesclagem feature com master;
• mover os commits da antiga feature.

Diferentes equipes de desenvolvedores usam diferentes abordagens nesse caso; nós moveremos os commits úteis para um branch separado e criaremos um pull request separado para esse novo branch.

️ Tarefa

1. Crie um branch chamado feature-fix e mude para ele.

2. Mova todos os commits do antigo branch feature para o novo branch. Resolva os conflitos de mesclagem que surgirem ao mover.

   

3. Adicione um teste de regressão em 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 sejam bem-sucedidos.
5. Remova o texto " with a sneaky bug" em ci.md.
6. Adicione as alterações dos testes e as alterações na lista de etapas ao índice e faça o commit delas.
7. Publique o branch no repositório remoto.

Você deve ter algo parecido com

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 um pull request.

Crie um pull request com o título Fixing the feature. Defina feature-fix como "head branch", e master como "ramo base".
Por favor, aguarde até que os testes sejam concluídos. Você pode ver o status dos testes na parte inferior da discussão do PR.

Certifique-se de ter definido master em seu fork do repositório como "ramo base", não responderei a solicitações de alterações no repositório com materiais do curso.

Aprova o pull request "Fixing the feature"

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

️ Tarefa

1. Clique em "Merge pull request".
2. Clique em "Confirmar merge".
3. Clique em "Deletar branch", pois não precisamos mais dela.

É isso que você deve ter neste momento

Parabéns!

Você executou todas as ações que as pessoas normalmente realizam no processo de integração contínua.

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

Fonte: habr.com