Processo de Desenvolvimento de Software (PDS)

O Processo de Desenvolvimento de Software (PDS) é a parte da gerência de projetos que define os procedimentos e etapas de desenvolvimento de software no TCE-GO. A qual inclui métodos e modelos de desenvolvimento, bem como a utlização de boas práticas que deve seguir para o desenvolvimento com qualidade dos protudos de software e seus artefatos.

Nesse tópico vamos falar do respositório dos projetos, o que são artefatos de trabalho, qual ferramenta de versionamento utilizar, qual modelo de versionamento deve ser utilizado, o padrão de descrição de commits, e o padrão de implantação/deploy dos projetos nos ambientes de desenvolvimento/homologação/produção.

Os artefatos de trabalho de um projeto é todo arquivo que tem relevância gerencial ou técnica para o projeto, desde uma rascunho de necessidades e anceios iniciais dos stakeholders, até o manual de uso do sistema.

Dentre os artefatos mais relevantes de um projeto, temos os requisitos do sistema, arquivos de código fonte, scripts de banco de dados, plano de implantação do projeto, manual de uso do sistema entre outros. Em nosso ambiente de desenvolvimento de sistemas separamos esses artefatos em dois grupos, o grupo de Artefatos Documentais, que englobam todos os artefatos de texto plano, isto é, texto que não são interpretados ou compilados por compiladores de sistemas, que são compreendidos pelos stakeholders. E o segundo grupo são os Artefatos de Código e Banco de Dados, que são os códigos fontes (backend e frontend) e os scripts de banco de dados.

O primeiro grupo deversão ser armazenados e gerenciados pelo sistema Wiki, está ferramenta que estamos utilizando para documentar o Processo de Desenvolvimento de Software (PDS). Já o segundo grupo, seus artefatos serão armazenados e gerenciados pelo sistema GitLab, ferramenta de versionamento baseada na ferramenta Git.

A ferramenta GitLab é uma ferramenta CASE utilizada para versionamento de artefatos de código de projeto, documentação técnica para execução do projeto (README.MD), ferramenta de Integração Contínua (CI) e ferramenta de Deploy Contínuo (CD).

Para cada projeto versionado nessa ferramenta será configurado scripts de CI/CD, para automatizar nosso processo de build, teste unitário e teste de caixa branca, análise de vulnerabilidades, duplicação e cobertura de código, e por fim de deploy no ambiente correto, conforme a branche alterada do projeto.

O modelo de versionamento que deverá ser utilizado pela equipe de desenvolvimento é o GitLab. Nesse modelo, representado pela imagem abaixo, temos a branch principal, a main/master , cuja as alterações nessa branch implica na atualização automatizada, se passado com sucesso pela esteira CI/CD, no ambiente de produção (no domínio *.tce.go.gov.br), para produtos com interação com o usuário ou com a geração e pulicação de nova versão da biblioteca na ferramenta Nexus. E temos também a branch de desenvolvimento, a develop , cuja as alteração nessa branch implica na atualização automatixada, se passado com sucesso pela esteira de CI/CD, no ambiente de desenvolvimento (ambente de GTI, no domínio *.tce.gti.br).

Por padrão a branch main/master fica protegida de commit direto, sendo possível receber atualização somente via Merge Request, o qual será aprovado pela equipe de revisão de código, que além de revisar irá verificar se os padrões de desenvolvimento estão sendo seguidos, como a estrutura de artefatos do projeto mantidos no GitLab, e se o padrão de commit está sendo respeitado (Semantic Release).

No repositório Git de cada projeto, apenas as branchs main/master e develop existirão durante todo o ciclo de vida do projeto. Mas além dessas branchs poderão existir de forma temporária de com ciclo de vida bem definidas como as:

• Features: branchs de evoluções (em projetos), cujo prefixo de nomenclatura será feat/{#ID da história/tarefa do redmine}-{nome sem espaço da funcionalidade} (exemplo feat/#40441-Servico-de-consulta-de-analistas-responsaveis);

• Hotfix: branches de correções emergenciais de erros de produto do projeto que estão implantados em produção, cujo prefixo de nomenclatura será hotfix/{#ID da história/tarefa do redmine}-{nome sem espaço do erro} (exemplo hotfix/#40061-Correção-BUG-sincronização-Addins-trâmite);

• Deveolp concorrente: caso de projetos com mais de um projeto de evolução sendo executado ao mesmo tempo, para que a branche de desenvolvimento fique limpa (devolop ), e caso cada não dependa um do outro, a equipe de cada projeto deverá criar uma branch de desenvolvimento a partir da devolop , seguindo a seguinte prefixo de nomenclatura será devolop/{#ID da história/tarefa do redmine}-{nome sem espaço do erro} (exemplo devolop/#40441-Servico-de-consulta-de-analistas-responsaveis). Dessa forma, a autalização para testes funcionais de cada projeto deverá ser realizado via branch release, como descrito a seguir;

• Release: branchs de candidata a release de alterações que irá entrar em produção, seja de correções vindas de uma hotfix, ou de evoluções de projetos que estavam sendo desenvolvidos na branch devolop . Nessa branch, em particular, sempre que as alterações dela forem sendo concluídas, após o Merge Request dela para para a main/master for concluído com sucesso, deve ser atualizado de imediato na branch develop com o resultado do merge da main/master. Dessa forma, projetos que antes estavam trabalhando na develop só vão para produção via branch release. A nomenclatura das branch de release terão o prefixo release, e seguirão o seguinte padrão release/{#ID da história/tarefa do redmine}-{nome sem espaço da funcionalidade/erro} (exemplo release/#40441-Servico-de-consulta-de-analistas-responsaveis ou release/#40061-Correção-BUG-sincronização-Addins-trâmite).

Para executar qualquer comando de manipulação da estrutura do repositório do projeto, verifique se o Git está instalado na máquina, executando o seguinte comando no prompt do windows para verificar qual a versão instalada na máquina:

git -v

Caso não esteja instalada a ferramenta Git instale na máquina.

Após verificar a instalação da ferramenta Git, verifique se o projeto que deseja criar a branch Hotfix se está apontando para a branch main/master executando o seguinte comando:

git branch -a

Através desse comando serão listadas as branchs locais e remotas, com destaque da branch que está sendo apontada pelo projeto na pasta local na cor verde com um asterisco (*) na frente, como na imagem abaixo na listagem da pasta do projeto TCE.Docs.

Para criar uma branch de Hotfix a partir da main/master e fazer o checkout para iniciar as alterações na nova branch, basta executar o seguinte commando, como exemplo para realizar a correção da tarefa #40132 do Redmine, que se refere a correção de editar o documento pela primeira vez via serviço do TCE.Docs usando o editor de documento do Word Office 365 online:

git switch -c hotfix/#40132-Correção-BUG-editar-primeira-vez

Após executar o comando na listagem dos branchs para verificar qual branch está sendo apontado, veremos que o git está apontando para a nova branch, como apresentado na imagem abaixo:

Para criar uma branch de Feature a partir da develop e fazer o checkout para iniciar as alterações na nova branch, basta executar o seguinte commando, como exemplo para realizar a implementação da feature de editar novo documento utilizando o editor de documento do Word Office 365 online, da tarefa #40132 do Redmine:

git switch -c feat/#40132-Implementação-Editar-Word-Online

Após executar o comando na listagem dos branchs para verificar qual branch está sendo apontado, veremos que o git está apontando para a nova branch, como apresentado na imagem abaixo:

Antes de criar uma branch de candidata a release do sistema, tanto para branch de Hotfix quando para branch de Feature, a branch de origem da release deve estar sempre atualizada com as ultimas alterações da branch de origem daquela, se Hotfix com as ultimas alterações da main/master se ouver, e se feature das ultimas atualizações da develop se exitir. Esse cuidado é de extrema importância para garantir que o código que será disponibilizado para o ambiente de homologação e testes finais esteja sempre atualizados com as correções e evoluções que antecederam a essa nova candidata a release. Esse procedimento de garantir que esteja atualizado é obrigatório.

Utilizando como exemplo que a hotfix da tarefa #40132-Correção BUG editar primeira vez tenha finalizado, vamos criar uma candidata a release a partir da brach hotfix/#40132-Correção-BUG-editar-primeira-vez, através do seguinte comando:

git switch -c release/#40132-Correção-BUG-editar-primeira-vez

Após a criação da candidata a release, caso tenha correções e ajustes identificados durante a homologação e testes finais, os quais vão ser comitados nessa branch, não há necessidade de criar nova branch para implementar correções. Essas operações deverão ser realizados nessa branch candidata, e quando concluir a partir dela será realizado o Merge Request para a main/master para ser implantada no ambiente de produção.

Após executar o comando na listagem dos branchs para verificar qual branch está sendo apontado, veremos que o git está apontando para a nova branch de candidata a release, como apresentado na imagem abaixo, deve ser removida a brach de hotfix de origem. Atenção - candidata a release de origem da branch develop nunca poderão ser removidas, apenas as branchs da develop de implementação concorrentes com prefixo como nesse exemplo devolop/#40441-Servico-de-consulta-de-analistas-responsaveis podem ser removidas após Merge Request com a branch develop:

Em todos os projetos Git a branch padrão main/master sempre estarão protegitas para commits e merge, sendo possível atualizar nela apenas via Merge Request. Seguindo o modelo GitFlow, as alterações nessa branch serão via correções advindas de branch de release que por sua vez vem de uma branch hotfix, ou via projetos de evolução/melhorias de branch release que veio da develop.

Toda atualização na branch main/master irá gerar uma nova versão estável do sistema, uma nova Tag, que seguira o padrão do Semantic Version, que irá incrementar a versão nas posições Major.Minor.Path conforme os commits que compõem a versão.

Para criar um Merg Request podemos fazê-lo via GitLab, através do seguinte menu demonstrado na imagem abaixo:

Na tela seguinte escolhemos a branch de origem que queremos levar as alterações para a branch de destino no campo 1 (Source branch), e no campo 2 escolhemos a branch de destino (Target branch). Abaixo de cada campo é apresentada a ultima alteração realizada nas branches.

Selecionado corretamente a branch de origem e a branch de destino, basta clicar no botão em 3 (Compare branches and continue) para ir para a próxima etapa de documentação do Merge Request.

Nessa próxima tela deve se documentar o Merge Request, informando o título (campo 1), a descrição das alterações da branch de origem (campo 2), selecione em Assignee o responável pela aprovação (campo 3), no campo Reviewer selecione o responável pela revisão das alterações realizadas na branch (campo 4). Marque a opção para deletar a branch de origem após a aceitação do Merge Request (campo 5), quando a origem for de uma branch de release, hotfix e feat, ou em caso de branch de develop concorrente. Após verificado o preenchimento correto clique no botão para criar o merg request (campo 6).

O padrão de descrição de commits que iremos adotar se basea no Conventional Commits, no qual define o tipo de alteração que está sendo realizada no commit, com sendo fix (correção de erro), feat (implementação de nova feature), build (alteração no sistema de build como Dockerfile ou dependências de projeto), docs (alteração de artefatos de documentação como README.md) e dentre outros tipos.

Além de utilizarmos o padrão do Conventional Commits, iremos utilizar a marcação de identificação de relacionamento das alterações dos commits no reposítorio com a tarefa do Redmine, utilizando ref ou refs (o primeiro para uma tarefa e o segundo para duas ou mais) como prefixo da descrição após o uso do tipo de commit, seguido de #{ID da tarefa no Redmine}.

Dessa forma o padrão de descrição de commits seguirá o seguinte padrão:

<tipo>(<escopo opcional>): [ref #<task redmine> (exemplo: ref #40061 ou refs #40061, #40062)] <descrição>

Esse padrão está documentado em detalhes no seguinte artigo DevOps Nomenclatura dos Commits.

Todo repositório Git de projetos terão configuração de esteira de CI/CD, sendo a etapa de CI com os estágios de build, teste e sonar (inspeça e cobertura de código), e a etapa de CD para deploy tanto para ambiente do cluster kubernets quando para projetos implantados em servidores Windows.

A etapa de Deploy só ocorrerá para as alterações realizadas nas branches main, develop e suas ramificações quando em muiltiplos projetos concomitantes, e para branches de release. As demais branches temporárias como hotfix e feats não terão deploy. Porém, todo commit, independente de qual branche executará a etapa de CI, seguindo obrigatoriamente as três principais etapas de build, teste e sonar (inspeça e cobertura de código).

O sistema Sonar responsável pela análise de cobertura de código, duplicação de código, estilo de código, inspeção e vulnerabilidades será configurado para cada projeto, conforme suas dependências e presença de código de terceiros, a fim de verificar apenas os códigos alterados e mantidos pela equipe.