4. Fase de DevOps e integração contínua

Finalizado o processo de desenvolvimento da funcionalidade, é necessário mesclar a branch criada a partir da development (a que possui o código da funcionalidade ou incremento) com a própria development (a origem).
- Essa mesclagem é feita por meio de um Pull Request (PR). Nesta etapa, o desenvolvedor que está com as últimas alterações implementadas na branch de recurso, solicitará o PR, e será iniciado o Code review (CR) onde algum desenvolvedor mais experiente revisará o código implementado, apontará ajustes caso seja preciso e, quando concluir que o código final está okay, aceitará o PR e concluirá o processo de mesclagem entre as branches, onde o código passa a ser implantado e liberado na development, e a branch de recurso é deletada.

Sobre todo esse processo, cabem alguns apontamentos:

É importante que todo código solicitado para mesclagem na development tenha sido testado e analisado pelos desenvolvedores que o fizeram, reduzindo as chances de bugs e melhorando a qualidade do mesmo.
Geralmente o próprio ambiente onde o código de produção está versionado (no nosso caso, o Azure DevOps da Microsoft) possui ferramentas que facilitam a vida do desenvolvedor durante este fluxo quando for subir suas alterações, gerar o PR das mesmas, resolver conflitos de merge e realizar a implantação e liberação de seu código, tanto para a branch development como para a branch master.

O processo de implantação é conhecido como deploy e consiste nas seguintes etapas: receber o código-fonte criado pelos desenvolvedores (isso acontece ao solicitar um PR); baixar todos os artefatos e dependências necessário para seu funcionamento; utilizar suas configurações do arquivo de propriedades e de integração contínua; gerar seu arquivo executável (build); e enfim subir o arquivo final para a mesclagem na branch especificada.
liberação é conhecida como release e consiste na etapa de liberar esse código implantado para uso na branch em questão, ou seja, após essa etapa é possível baixar na development as novas alterações, e posteriormente subir estas para a branch de produção (a master).
Vale ressaltar que todo esse processo de implantação e liberação é acompanhado por um pipeline, onde cada etapa é fragmentada e registrada em um log (como um histórico), onde os desenvolvedores (e/ou administradores) podem acompanhar todo esse processo, linha por linha do que é instalado, configurado e concluído, até que o próprio processo seja finalizado.

Durante esse processo (de deploy e release) podem ocorrer conflitos de diversos tipos, dentre os mais comuns o conflito de merge. Geralmente este ocorre quando se cria branches simultâneas a partir de uma mesma branch, porém altera-se alguma configuração de uma branch e a mescla na sua origem a partir desse processo, de forma que a outra branch fica dessincronizada e entre em conflito pela falta dessa configuração ao solicitar o PR.
- Caso este ocorra deve ser resolvido de forma semelhante a utilizada quando se enfrenta um merge no repositório local. A diferença é que as alterações feitas devem ser "commitadas" e empurradas para o repositório remoto, a fim de que se possa realizar uma nova tentativa de deploy e release para o PR em questão.

Caso nenhum conflito tenha sido identificado durante o processo o pipeline será concluído e as alterações estarão no ambiente de “homologação” (HMG), onde poderão ser acessadas online pelo protocolo de internet (endereço IP) desse ambiente, pelos usuários com permissão e conectados a rede virtual privada (VPN) da TOTVS. A partir deste acesso, realiza-se novos testes para validar se as alterações não impactaram em outras funcionalidades pré-existentes.
Após tudo isso, caso seja necessário alterar algo no que foi desenvolvido, repete-se o ciclo desde o começo, onde cria-se uma nova branch para corrigir o que foi apontado e depois realiza as etapas até que o novo código esteja no ambiente de Homologação.