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.

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:

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.