Processo de Entrega de Soluções

h1. 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#Princípios e práticas importantes para a 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#Regras para 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.

h2. %{color:#7d228d}Iniciando uma release%

p(. 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.

h2. %{color:#7d228d}Manutenções corretivas (inclui correção de _bugs_)%

h3. Desenvolvimento

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

p((.  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.

p((.  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. 

h3. Produção

p((.  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.

p((.  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.

h2. %{color:#7d228d}Solicitação de _Merge_ numa _branch_%

p((.  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.

p((.  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.

p((.  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_*. 

p((.  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*.

h2. %{color:#7d228d}Promoção entre ambientes%

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