2.5.1.1 - Regras gerais para uso do repositório¶

1. Além das regras desta seção, o uso do repositório deve seguir os Princípios e práticas importantes para a Integração Contínua descritos em 2.5 - Integração Contínua.

2. Os commits, pushes e a criação de branches devem ser realizados de acordo com as regras estabelecidas em 2.5.1.2 - Commits, pushes, tags e branches temporárias.

3. Ao criar uma nova branch, fazê-lo a partir de uma tag específica de um ambiente do repositório (desenvolvimento ou master, por exemplo) informada pelo Líder do Projeto, e nomeá-la de acordo com o padrão descrito em Regras para branches temporárias em 2.5.1.2 - Commits, pushes, tags e branches temporárias;.

4. A branch de desenvolvimento da fábrica no repositório do MP será espelhada com o seu próprio repositório, devendo a fábrica ficar responsável pela atualização do código quando houverem mudanças ou correções em códigos de produção. A fábrica deve se organizar para não mesclar códigos de produção com códigos não preparados e não testados da esteira de desenvolvimento.

Iniciando uma release¶

Uma release pode ter como escopo o desenvolvimento de novas funcionalidades ou a manutenção de existentes. Em ambos os casos, a Fábrica deverá criar uma branch a partir de uma tag ou branch específica, contendo o código de produção (branch master a partir do fork com repositório central), informada pelo Líder de Projeto. Essa indicação deve ser formalizada de alguma forma à Fábrica. Sugestões: Email ao Gerente Técnico da Ordem de Serviço, Item de Backlog da Sprint de Iniciação etc.

Manutenções corretivas (inclui correção de bugs)¶

Desenvolvimento¶

Caso a Fábrica seja acionada para corrigir erro, defeito ou falha identificada na versão do ambiente de desenvolvimento, há duas possibilidades:

a) a versão ainda está sendo produzida por uma OS em andamento: a correção entra na linha de produção da release, ou seja, é realizada como trabalho da equipe.

b) não há mais OS em andamento para aquela versão: deverá criar uma branch de fix a partir da branch de desenvolvimento do repositório do Projeto no GitLab do MP.

Produção¶

a) Caso a Fábrica seja acionada para corrigir erro, defeito ou falha identificada na versão do ambiente de produção, deverá criar uma branch, chamada hotfix a partir de uma tag específica de produção do repositório de produção (Produto) no GitLab do MP.

b) O código de correção deverá ser incorporado ao código de desenvolvimento, tendo cuidado para separar o código de produção com a correção do código em desenvolvimento incrementado com a correção.

Solicitação de Merge numa branch¶

a) O líder de projeto será o encarregado de validar o merge request de códigos prontos para entrada em produção para uma branch temporária de execução de testes de qualidade de código, chamada de release candidate e criada pelo líder de projeto durante o ínicio do projeto. O time de desenvolvimento, com a aprovação do líder de projeto e validação da área de negócios, deverá solicitar o merge request para a branch temporária supracitada.

b) Após a validação da qualidade do código, o líder do projeto deverá executar um merge request para incorporação do código candidato ao código da branch master(candidato a produção). A equipe de sustentação será responsável por avaliar, em seguida, o pedido de pull request para o repositório de produção e aceitar a fusão dos códigos dos repositórios.

c) Para correções de código em produção, a equipe de sustentação deverá acionar a fábrica responsável para executar correção. A equipe de sustentação também tem por responsabilidade a criação da branch temporária de correção, chamada de hotfix.

d) A fábrica responsável pelas correções em código de produção deverá, após corrigido o código e aprovado por testes de qualidade, solicitar o merge request para a branch master.

Promoção entre ambientes¶

Ver definições em 2.5.1.3 - Promoção do código entre ambientes.