Mudanças entre as edições de "Política de Versionamento e estruturação de branches"
(→Estruturação dos branches no GitLab) |
|||
| Linha 16: | Linha 16: | ||
O desenvolvimento das funcionalidades previstas no projeto deverão ser realizados neste branch, ficando como opcional, a critério da célula, a utilização de estratégias como branch por feature, por exemplo. As alterações realizadas deverão ser encaminhadas, invariavelmente para o branch do projeto, por meio de commit seguindo os padrões definidos pela empresa (verificar a seção "Requisitos de commit de código" nesta página). | O desenvolvimento das funcionalidades previstas no projeto deverão ser realizados neste branch, ficando como opcional, a critério da célula, a utilização de estratégias como branch por feature, por exemplo. As alterações realizadas deverão ser encaminhadas, invariavelmente para o branch do projeto, por meio de commit seguindo os padrões definidos pela empresa (verificar a seção "Requisitos de commit de código" nesta página). | ||
| + | |||
| + | ===Baseline de Homologação=== | ||
| + | Após o término da construção dos requisitos contidos no escopo da entrega, uma baseline de homologação deverá ser criada no branch de desenvolvimento do projeto. Essa baseline deverá gerar uma "tag" (label), indicando que a versão está pronta para a homologação. Será este label que passará pela auditoria de construção e, posteriormente, gerará o pacote para envio à homologação pelo cliente. | ||
| + | |||
| + | Caso seja necessário realizar correções ou atualizações identificadas no ambiente de Homologação, um novo branch a partir do branch de desenvolvimento deve ser criado. Consideraremos este branch como um branch "Release". Todas as atualizações para homologação deverão ser atualizadas neste branch. | ||
| + | |||
| + | ===Baseline de Entrega=== | ||
| + | Uma vez que a Homologação for finalizada, as operações de Merge deverão ser realizadas. Neste caso, deve-se observar os seguintes cenários: | ||
| + | |||
| + | * Se houve a criação de um branch "Release", deve-se fazer o merge deste branch com o branch "Main", para que seja possível fazer a baseline de entrega. Em seguida, deve-se também fazer o "merge" do branch "Release" com o branch de desenvolvimento, para atualizar este último com as alterações identificadas em Homologação; | ||
| + | * Se não houve a criação de um branch "Release", deve-se apenas fazer o merge deste branch com o branch "Main". | ||
| + | |||
| + | Após a realização do merge, deve ser gera | ||
| + | |||
| + | ==Requisitos de commit de código== | ||
| + | |||
| + | <<PREENCHER>> | ||
Edição das 13h11min de 1 de setembro de 2016
Índice
Sobre essa página
Essa página contém informações referentes ao modelo de estruturação de branches dos repositórios existentes no GitLab que deve ser seguido para que sejam aderentes ao Processo de Desenvolvimento de Software da MSTECH.
Da mesma forma, descrevemos como os artefatos devem ser organizados na realização de uma operação de manipulação de arquivo versionado (commit).
Estruturação dos branches no GitLab
A imagem abaixo apresenta de forma resumida a forma de estrutura dos branches de um projeto:
Cada repositório contém por padrão um branch "Main". Este branch contém o histórico do código estável do produto, sendo este a matriz de onde os demais branches serão criados.
Quando uma nova evolução deste código fonte é necessária (sendo esta por uma evolução de produto ou um novo projeto de customização, por exemplo) será criado um novo branch para este desenvolvimento. Este branch deverá ter o nome do projeto/produto aberto como identificador. Este branch deverá ser criado a partir de uma "tag" (label) registrado na Main.
O desenvolvimento das funcionalidades previstas no projeto deverão ser realizados neste branch, ficando como opcional, a critério da célula, a utilização de estratégias como branch por feature, por exemplo. As alterações realizadas deverão ser encaminhadas, invariavelmente para o branch do projeto, por meio de commit seguindo os padrões definidos pela empresa (verificar a seção "Requisitos de commit de código" nesta página).
Baseline de Homologação
Após o término da construção dos requisitos contidos no escopo da entrega, uma baseline de homologação deverá ser criada no branch de desenvolvimento do projeto. Essa baseline deverá gerar uma "tag" (label), indicando que a versão está pronta para a homologação. Será este label que passará pela auditoria de construção e, posteriormente, gerará o pacote para envio à homologação pelo cliente.
Caso seja necessário realizar correções ou atualizações identificadas no ambiente de Homologação, um novo branch a partir do branch de desenvolvimento deve ser criado. Consideraremos este branch como um branch "Release". Todas as atualizações para homologação deverão ser atualizadas neste branch.
Baseline de Entrega
Uma vez que a Homologação for finalizada, as operações de Merge deverão ser realizadas. Neste caso, deve-se observar os seguintes cenários:
- Se houve a criação de um branch "Release", deve-se fazer o merge deste branch com o branch "Main", para que seja possível fazer a baseline de entrega. Em seguida, deve-se também fazer o "merge" do branch "Release" com o branch de desenvolvimento, para atualizar este último com as alterações identificadas em Homologação;
- Se não houve a criação de um branch "Release", deve-se apenas fazer o merge deste branch com o branch "Main".
Após a realização do merge, deve ser gera
Requisitos de commit de código
<<PREENCHER>>
