Política: Gestão de configuração¶

Gerenciamento de configuração é o processo usado para manter sistemas computacionais, servidores e softwares em um estado desejado, consistentemente. É uma forma de se certificar de que o sistema funciona como o esperado ainda que alterações sejam são feitas com o passar do tempo.

Gerenciar configurações de sistemas de TI envolve a definição de um estado desejado, como a configuração de um sistema, e então a criação e manutenção desses sistemas. Intimamente relacionado a avaliações da configuração e análise de desvios, o gerenciamento de configuração utiliza essas técnicas para identificar quais sistemas serão atualizados, reconfigurados e quais receberão a aplicação de patches.

Por padrão, a Magna Sistemas utiliza o GitFlow como prática para gerenciar versões de software.

GitFlow (Fluxo de trabalho principal)¶

Cada novo recurso deve ser armazenado na própria branch de trabalho, que pode ser enviada por push para o repositório central para backup. No entanto, ao invés de serem ramificações a partir da branch main, as branches feature usam a branch develop como pai. Quando um recurso é concluído, ele passa por merge de volta para a branch develop. Os recursos não devem nunca interagir diretamente com a branch main.

Uma vez que a branch develop adquiriu recursos suficientes para uma nova versão (ou uma data de lançamento predeterminada está se aproximando), deve-se bifurcar (ou atualizar, promovendo seu codigo para) uma branch release a partir de develop. Criar esta branch dá início ao próximo ciclo de lançamento, portanto nenhum novo recurso pode ser adicionado a partir deste ponto. Quando estiver pronta para ser lançada, a branch release passa por merge para a branch main e é marcada com o número da versão. Ela também deve passar por merge de volta para a branch develop, que pode ter progredido desde que o lançamento foi iniciado.

As branches de manutenção ou de “hotfix” são usadas para corrigir com rapidez versões dos ambientes de Produção ou Homologação. As branches de hotfix se parecem muito com branches release e feature, com a diferença de serem baseadas na branch main (caso seja um bug encontrado no ambiente de Produção) ou release (caso o bug tenha sido encontrado no ambiente de Homologação) ao invés da branch develop. A hotfix é a única branch que deve ser bifurcada direto da main ou release. Assim que a correção é concluída, deve-se fazer o merge dela tanto na branch de origem do problema (main para bugs de Produção ou release para Homologação) e deve ser feito o rebase, passando por release, ate chegar na branch develop. A branch main deve receber um número de versão atualizado.

A ação de elevar o código da branch feature, passando por develop, release até main chama-se "promoção" (ou "promote"). O movimento inverso, trazendo recursos da main até develop ou feature é chamado de "rebase".

Main-Based Flow (Fluxo de trabalho alternativo)¶

Este fluxo possui uma complexidade um pouco mais elevada que o GitFlow para conotrole das atividades, pois cada branch acaba tendo um ciclo de vida autônomo. Neste caso, todas as branches de trabalho, sejam de features ou hotfixes, devem derivar da branch main, independente do momento do ciclo de vida em que se encontram.

Cada novo recurso deve ser armazenado na própria branch de trabalho, que pode ser enviada por push para o repositório central para backup. Quando um recurso é concluído, ele deve passar por merge para a branch develop e ser testada. Assim que testada, deve-se fazer o merge da própria branch de trabalho (feature ou hotfix, e não da branch develop), para a branch release, para que seja homologada.

Uma vez que a a versão de homologação foi testada e aprovada, a branch de trabalho (feature ou hotfix) deve ser incorporada à branch main para que se libere a versão para produção. Até que a branch de trabalho seja incorporada à branch main, ela não pode ser apagada.

Este modelo traz pontos positivos e negativos em relação ao fluxo GitFLow:

Pontos positivos¶

Maior flexibilidade: Possibilidade de promover o código de uma única feature para os ambientes superiores sem levar outro desenvolvimento consigo;
Mais segurança: Por derivar de uma branch mais estável, o risco de promover códigos que ainda não foram testados diminui;
Maior dinâmina na liberação das versões.

Pontos negativos¶

Deve-se ter maior controle do fluxo de implantação desta branch nas branches superiores. Ou seja, o risco para promover uma branch de um ambiente para outro, sem passar por um intermediário, é maior;
O risco de conflitos pode ser um problema, já que uma feature baseada na branch main pode possuir código mais antigo com relação às branches develop e release. As features, nesse caso, podem ser desenvolvidas com um código-fonte que já foi completamente alterado no ambiente de develop, por exemplo, o que pode acarretar em retrabalho para adequação do código da feature. Para resolver esse problema, um rebase para a feature é necessária, porém, neste caso, o código que será promovido para main conterá outras features que ainda estão em testes.