Aula 07 - Rastreabilidade e Governança

Exercício

Neste exercício vamos praticar conceitos de proteção de branches, regras de aprovação e validações obrigatórias de pull requests

0. Faça o fork deste repositório para a sua conta pessoal

Edite a linha 2 do arquivo Dockerfile para que a URL do label aponte para o seu repositório pessoal

1. Introduzindo uma mudança na aplicação

Crie um novo branch chamado novo-background
Na pasta public adicione este arquivo coffe.jpg (via upload ou commit)
Na pasta public, edite o arquivo style.css, na linha 154.

background: url("coffee.jpg") left bottom;

Volte para a tela inicial do seu repositório, clique em Compare & pull request e crie o PR

❓ Mas como podemos garantir que as modificações propostas só vão estar no branch `main` com as validações e aprovações necessárias?

2. Configurando status obrigatórios no workflow ("status checks")

Do jeito que nosso workflow está, caso o build falhasse, seria possível fazer o merge de código quebrado no branch principal.

Vamos configurar qual(is) os status vindos do nosso pipeline deve obrigatoriamente passar antes de ser possível fazer o merge. Fazemos isso via proteção de branches ("branch protection")

💡 Dica: Imagine que as regras de proteção de branches vão impedir que certas operações de Git (merge, por exemplo) sejam executadas até que determinadas condições mínimas sejam atendidas.

❓ O que mudou no seu PR?

3. Configurando revisões de código

Como vimos em outras aulas, revisões de código são uma parte fundamental de um processo de desenvolvimento de software bem estruturado. Eles adicionam qualidade, uma vez que trazem diferentes perspectivas e experiências para o código sendo desenvolvido. Mas também servem como uma ferramenta de governança importante, uma vez que definem as regras de negócio a respeito das alçadas de aprovações.

Ainda na parte de regra de proteção de branch, clique em Require pull request reviews before merging
Configure Required approving reviews para 2
Marque Dismiss stale pull request approvals when new commits are pushed
Marque Require review from Code Owners
Clique Save changes

❓ O que mudou no seu PR (2)?

💡 Agora nosso PR não pode ser mergeado ao main (opção possível apenas usando privilégios de admin). Se clicarmos em Reviewers vamos ver que também não conseguimos adicionar nenhum revisor. Por quê?

Vamos adicionar nossos colegas de turma?

4. Configurando CODEOWNERS

O que é esse tal de Code Owners? São literalmente pessoas ou equipes responsáveis por determinada parte do código. Definindo Code Owners podemos definir regras de negócio para a revisão de código. Essas regras são definidas em um arquivo chamado CODEOWNERS que deve ficar na raíz do projeto, na pasta docs/ ou na pasta .github/.

Um template de arquivo CODEOWNERS pode ser encontrado aqui.

Vá para o branch main
Crie um arquivo chamado CODEOWNERS na pasta .github
Copie e cole o conteúdo deste aquivo

❓ Como você alteraria esse arquivo para que alguns de seus colegas fossem requisitados a revisar código do PR?

Mude novamente para o branch novo-background
Navegue para o arquivo views/index.pug
Edite as linhas 8 e 9 para que elas tenham o seguinte conteúdo

        h3 Making the Worst
        h1 Coffee For Devs

❓ Como poderíamos alterar nosso arquivo CODEOWNERS para definir responsáveis para revisar alterações desse tipo?

5. E o que mais?

Obrigatório commits assinados
Obrigatório histórico linear
Incluir administradores sob as regras
Permitir force pushes
Permitir deleções

paahparadela/aula-07-governanca