Processo de Desenvolvimento de Software para o Model for Ocean laNd and Atmosphere predictioN (MONAN)
Organizações que utilizam processos de desenvolvimento de software informais (sem caracterização de processos na realidade) ou processos muito rígidos (Rational Unified Process - RUP, Team Software Process - TSP, etc) costumam introduzir erros relativos ao próprio processo nos softwares. Esses erros só podem ser minimizados com a criação de processos gerenciados adequados que levem em conta a complexidade do software e a diversidade das equipes e pessoas envolvidas. No livro "Engenharia de Software: Projetos e Processos (ESPP)", lê-se:
A capacitação de uma organização também requer a aplicação de processos. Esses processos têm etapas, resultados intermediários e pontos de controle. A aplicação dos processos de capacitação é realizada por meio de projetos, que precisam ter custos, prazos e responsáveis bem-definidos.
Esse documento normatiza um processo de desenvolvimento de software a ser aplicado no desenvolvimento do modelo Model for Ocean-laNd-Atmosphere predictioN (MONAN). Na construção desse documento, pontos identificados como falhos no desenvolvimento de modelos numéricos são mitigados através do uso de metodologias baseadas em processos ágeis. Esse modelo pode e deve ser revisto à medida que o desenvolvimento avança e que estágios intermediários indiquem a necessidade de mudanças e aprimoramentos.
As mudanças, se e quando houverem, deverão ser registradas com a atualização desse documento.
O MONAN é um modelo comunitário, isto é, desenvolvido com apoio efetivo de diversas instituições externas ao INPE. Com isso a gerência do processo de desenvolvimento conforme exigida acima precisa ser mais cuidadosa visto que podem haver diversas tarefas simultâneas. Para isso faz-se especialmente necessária uma padronização adequada nos procedimentos relacionados com o desenvolvimento geral e a interação entre as equipes de desenvolvimento das diversas componentes do modelo.
As etapas identificadas no desenvolvimento de modelos numéricos até hoje observadas, costumam ser as seguintes:
- Levantamento dos requisitos;
- Desenvolvimento de uma solução ou busca por soluções existentes;
- Testes;
- Implementação operacional.
Os requisitos são originados por três fatores:
- Necessidade específica identificada por um pesquisador. Essa necessidade pode ser advinda de sua própria pesquisa ou identificação de um problema físico, resultados inadequados ou de alguma publicação ou apresentação onde melhorias ou problemas são verificados;
- Relatos de bugs ou mal funcionamento;
- Necessidade de aumento de desempenho dados os custos computacionais.
- Melhoria de funcionalidade: melhor precisão e acurácia nos resultados.
Em geral o desenvolvimento das soluções para os requisitos são adotados pelo próprio pesquisador que altera o código do modelo. Essa alteração pode ser feita de algumas maneiras:
- Editando o código e fazendo pequenos testes de forma a indentificar a causa do problema e solução;
- Terceirizando a solução para bolsistas, alunos e pesquisadores/desenvolvedores externos;
- Adotando um novo código que é identificado como mais moderno e confiável para o problema.
Observa-se aqui que em todos os casos há diferentes formas e níveis de controlar essas tarefas. Inclusive, pode não ser adotado controle nenhum acarretando na confusão das versões dos códigos e perda de controle dos mesmos. Ademais, ao usar código exótico (ie., escrito fora dos padrões recomendados pela linguagem) existe sempre a possibilidade de que o código não tenha utilizado boas práticas de codificação o que, por um lado pode resolver um problema, e por outro acrescentar outros ao código com problemas de manutebilidade, portabilidade, performance, confiabilidade entre outros.
Em geral os testes não são automáticos ou padronizados. O pesquisador ou desenvolvedor realiza um teste dentro de alguns pacotes que ele possui. Como modelos numéricos tem de atender a diversas condições físicas cujas condições iniciais são distintas, ou casos onde há diferentes topografias e outras condições, há sempre a possibilidade de que o código funcione em determinadas condições e passe a falhar em diversas outras. Além disso os testes sempre são focados no funcionamento. Em raros casos são realizados testes que garantam a qualidade do software e respondam outras questões como:
- O código funciona em outros compiladores?
- O código tem desempenho mínimo esperado para ser usado em situação operacional?
- O código tem bom comportamento e funciona em arquiteturas distintas?
- As modificações foram devidamente documentadas e versionadas?
- Os manuais de uso, caso necessário, foram atualizados?
- As modificações permitem manutenções futuras com facilidade?
Após a etapa de testes e sendo considerado funcional, o modelo é então levado a situação operacional. Recentemente, no INPE, um grupo foi criado para realizar testes de acurácia do modelo e gerar relatórios com os resultados. Contudo, nesta estrutura, não há um fluxo padronizado e as normas que determinem quando o modelo está aprovado para a situação operacional diária é ainda incipiente e de certa forma tratado de modo subjetivo.
Atualmente alguns modelos numéricos usam o Redmine hospedado no site do CPTEC, para fazer o gerenciamento dos projetos. Alguns grupos de desenvolvimento e pesquisa fazem uso da ferramenta, mas não há um padrão de acompanhamento contínuo e auditável e nem uma gerência centralizada. Além disso a ferramenta está desatualizada e sem pessoal disponível para fazer a manutenção e implementar as melhorias necessárias.
O Redmine é conectado a um sistema de controle de versões no padrão Subversion (SVN). Os códigos dos modelos versionados por esta ferramenta, tem desde um fraco controle (sem nenhuma regra de versionamento) até controles um pouco mais estruturados. Contudo, por excesso de códigos e falta de pessoal, há uma falta de convergência e de metodologia de uso para o controle de versões e dos processos de desenvolvimento.
Nesse contexto, não há um controle de requisitos efetivos que deve gerar as tarefas na maioria dos casos. Alguns grupos tentam manter o controle de registros de atividades e, em alguns casos, conseguem até manter um bom acompanhamento. Mas há diferentes níveis de uso da ferramenta e uma falta de cultura sobre a importância e a aplicação desses procedimentos.
O desenvolvimento de software para o MONAN, deverá seguir as regras estabelecidas nesse documento. A adoção do processo deverá obrigatoriamente ser adotada por todas as intituições partícipes, internas ao INPE, e ter a gerência de todas as tarefas, atividades e desenvolvimentos gerenciadas pelo INPE. Os membros externos da comunidade de desenvolvimento do MONAN podem adotar metododologia ou processos próprios ou adotar o provesso aqui desenvolvido.
O processo de desenvolvimento é mostrado na Figura 1, com seus tópicos descritos a seguir.
Existem três tipos de grupos a considerar:
- Grupo de Computação e
- Grupos de Pesquisa/Desenvolvimento.
- Grupo de testes funcionais e avaliação de modelos
O Grupo de Computação está dividido em 4 Subgrupos:
a) Subgrupo de Revisão de Código;
b) Subgrupo de Testes automáticos;
c) Subgrupo de Processamento de Alto Desempenho (PAD);
d) Subgrupo de Versionamento;
Além desses 4 subgrupos há uma Gerência que deve manter a coesão entre todos os subgrupos de computação.
Os grupos de Pesquisa e Desenvolvimento são diversos e se dividem de acordo com as áreas de pesquisa envolvidas no desenvolvimento de modelos. Entre elas estão o Grupo de Dinâmica, Grupo de Radiação, Grupo de Superfície e Camada Limite, Grupo de Oceano, Grupo de Criosfera, Grupo de IA, etc. Para efeito desse documento, todos esses grupos distintos serão tratados apenas como Grupos de Pesquisa e não são escopo direto do grupo que cuida das questões computacionais do modelo, denominado internamente como GCC - Grupo de Computação Científica cuja missão, atribuições, visão, valores e membros natos e transversais estão determinados em documento interno ao INPE.
Para uso do projeto MONAN, o controle de versionamento será baseado no padrão git. A razão para a adoção encontra-se no fato de que o git permite que sejam realizados commits de código locais separados dos tronco principal de desenvolvimento (trunk) e dos galhos criados para cada fim (branchs). Assim é possível que apenas um pequeno grupo possa controlar os pushes (os uploads de modificações ao trunk) e merges (as combinações dos códigos válidos entre os desenvolvimentos), garantindo a organização, coerência e a perpetuação dos códigos.
Para isso adotou-se como ferramenta integradora o GitHub que possui diversas funcionalidades altamente úteis para o controle do projeto, além de permitir que o código possa ser distribuído sem grandes problemas. O projeto está hospedado no endereço GitHub - monanadmin/monan: MONAN - Model for Ocean-laNd-Atmosphere predictioN.
A página principal do MONAN, também está hospedada no GitHub e está disponível em MONAN | monan.
Na Figura 1, estão diagramadas as etapas de desenvolvimento a serem adotadas para o MONAN. Cada etapa será descrita nas subseções a seguir.
Figura 1 - Fluxo de desenvolvimento para o MONAN.
Para iniciar uma etapa de desenvolvimento torna-se necessário ter um clone do projeto. Para isso utiliza-se o comando de clone do git. Para isso basta executar o comando:
git clone https://github.com/monanadmin/monan.gitAntes de começar um desenvolvimento, correção de bug, melhoria ou outra atividade com o modelo é necessário criar no repositório do MONAN - Model for Ocean-laNd-Atmosphere predictioN, na aba Issues, uma milestone (veja figura abaixo - lado direito). A milestone é uma série de atividades agrupadas que compõe a tarefa total, isto é, o desenvolvimento requerido.
Ao clicar em milestone é mostrado uma tela para preencher o nome do desenvolvimento, uma data de término e uma descrição. É importante ser bastante minucioso na descrição informando os detalhes do desenvolvimento, publicações de referência se houverem (link), equações, diagramas, etc. Tudo isso pode ser utilizado visto que a descrição deve usar a linguagem Markdown. Para verificar como usar o markdown consulte os links abaixo:
Após a criação da Milestone deve-se iniciar a criação das requisições de tarefas ou 'Issues'. Essa criação pode ser feita de forma incremental, à medida que o desenvolvimento está em andamento ou um pacote de requisições de tarefas pode ser criado logo após a criação da Milestone. Para criar a requisição clique na aba Issues e no botão New Issue. Preencha então o nome da requisição (nome curto e bem indentificável) e logo depois descreva na aba Write de forma completa, qual tarefa será realizada. No lado direito clique nas pessoas envolvidas (Assignees) e qual o rótulo adequado para a tarefa (Labels) e o projeto MONAN. É fundamental fazer a conexão da requisição a milestone criada. Para isso use a engrenagem em 'milestones' no menu à direita.
Uma parte fundamental é a descrição da tarefa. A descrição, assim como informado na milestone, permite o uso da linguagem de texto Markdown. Assim é possível usar figuras, links, marcar usuários, etc. Não econonize na descrição da tarefa pois ela irá orientar o trabalho.
Um exemplo de abertura de tarefa para uso com o git:
Adicione uma descrição do assunto que será abordado no pedido de abertura de tarefa no
git. Inclua informações pertinentes ao que será realizado.
Adicione uma descrição sobre a motivação para a realização da tarefa.
Descreva as dependências e potenciais impactos que a tarefa pode exercer sobre outras partes do código (incluindo interações com outras equipes e partes do código).
Descreva os impactos e potenciais impactos que as modificações e desenvolvimentos podem exercer sobre outras partes do dódigo, incluindo outras equipes).
Descreva o resultado a ser encontrado a partir da realização da tarefa.
Ao criar a requisição o gerente será notificado. O gerente irá entrar em contato com você para tratar do status do trabalho e determinar outras informações necessárias para a sua realização e acompanhamento.
Uma pequena reunião será agendada para determinar os detalhes e a tarefa pode passar de To Do para In Progress, adotando-se o sistema de controle de tarefas KANBAN (veja mais em https://www.totvs.com/blog/negocios/kanban/). Esse controle das tarefas (e sub-tarefas ora geradas da tarefa principal) será realizado no próprio github no setor de projetos: https://github.com/monanadmin/monan/projects/1 . Nessa área encontram-se as tarefas dispostas em tickets e distribuídas em boards para cada fase da mesma.
Cada issue aberta recebe um número sequencial mostrado como #n onde n é o número. Esse número é fundamental para o rastreio das tarefas e suas fases e para controle de versionamento do código.
Todo novo desenvolvimento deverá receber um branch próprio que deve ser feito à partir do trunk principal do modelo. Assim o desenvolvedor poderá trabalhar em área distinta derivada de um ponto atual do trunk de desenvolvimento. Após ter um clone ativo, para a geração de um branch usa-se o comando:
git branch monan_16
git checkout monan_16
Switched to branch 'monan_16'Como regra o branch deve estar associado a tarefa de forma direta, o que torna o processo mais facilmente rasterável. No exemplo acima o índice 16 indica que esse branch se deriva da issue #16 disponível e descrita no github.
A partir desse ponto o ambiente passa para o branch de desenvolvimento solicitado. O git commit é feito sempre da mesma maneira mas o push para o branch irá pedir algumas opções. Por exemplo, imagine que você queira criar um arquivo chamado file.txt, fazer o commit e o push. O processo fica então assim:
echo "Some text" > file.txt
git add file.txt
git commit -m 'Realizando um teste
>
>apenas um teste
>'
git push --set-upstream origin monan_16No exemplo acima, observe que o comando git push --set-upstream origin monan_16, entrega os arquivos adicionados ao branch monan_16 que foi criado anteriormente.
Para alterar ou criar novos códigos o pesquisador e/ou desenvolvedor, de agora em diante chamado apenas de desenvolvedor, deve estar atento ao DTN.01 - Padrão de codificação (Code patterns) adotado pelo MONAN. Conhecer o documento DTN.01 é fundamental para realizar tal tarefa.
O MONAN tem em suas partes códigos de terceiros. Esses códigos tem formatação a padrões próprios. Espera-se que com o tempo os códigos legados e de terceiros assumam uma mesma padronização. A técnica é ir gradativamente alterando os códigos à medida que os mesmos vão sendo manipulados refatorando continuamente com ou sem o uso de ferramentas para tal fim.
É importante que o desenvolvedor realize constantemente commits locais no código de forma a controlar o desenvolvimento e poder fazer o rollback (ie., voltar a edições anteriores do código) e manter a cópia segura fazendo backups constantes do código.
Antes de fazer um commit é preciso estar atento ao status do trabalho. Saber antecipadamente quais os arquivos foram alterados e destes escolher aqueles que devem ser adicionados no commit.
Para saber o status da sua cópia de trabalho local, basta fazer:
git statusUma lista com o status dos arquivos será mostrada. Para cada arquivo que se deseja que faça parte do commit deve-se usar o comando add:
git add arquivo1
git add arquivo2
...e depois pode-se fazer o commit passando a mensagem adequada com a opção -m:
git commit -m 'Cabeçalho do commit
>
> Mensagem adequada sobre esse commit
>'Observe que adota-se uma primeira linha com um cabeçalho do commit. Depois, pulando uma linha escreve-se a mensagem informando suscintamente o que está sendo 'comitado', a razão e informações relevantes.
git commit -m 'Nova interface de chamada da radiação
>
> a chamada da radiação foi alterada para passar os valores
> dos arrays de aerossóis apenas nos limites do processador
> sem as bordas da ghostzone.
>'O exemplo acima mostra uma forma prática e padronizada da descrição do commit.
Em caso de commit muito relevante para o status da tarefa recomenda-se que o ticket da tarefa no github seja atualizada com os detalhes. É possível usar diversos tipos de atualizações nesses tickets como figuras, fórmulas, tabelas, links, códigos, diagramas e outras informações.
Os pushs para o branch criado não devem ser feitos para quaisquer modificações. O desenvolvedor deve usar seus procedimentos pessoais de edição de código e de testes funcionais até que tenha algum código considerado com desenvolvimento robusto. Pushs intermediários podem ser realizados desde que entenda-se que houve avanço significativo. Ao fim de um processo de desenvolvimento o desenvolvedor deve fazer o push para o branch em edição. Esse seria um push de fim de tarefa por parte do desenvolvedor.
Um push é feito de forma simples: estando todos os commits realizados (ie. com todos os arquivos que foram alterados, considerados para a entrega) basta fazer:
git pushAo realizar o push uma mensagem é enviada ao gerente informando que um push no branch em desenvolvimento foi feito e um sinal é ativado. Esse sinal serve para abrir uma tarefa específica de revisão de código que será criada pelo gerente e atribuída ao subgrupo de revisão. O subgrupo de revisão será informado por e-mail sobre a nova tarefa disponibilizada.
Ao ser encerrada, a tarefa sai do status In Progress para o status To Review.
À medida em que os desenvolvimentos são realizados, o repositório principal main é atualizado. Para manter o seu branch atualizado com as últimas modificações do main, pode-se utilizar os comandos fetch para receber as os deltas do repositório e rebase para incorporar as atualizações ao seu branch de desenvolvimentos (o que pode incluir novos arquivos):
git fetch
git rebase origin/mainA depender da situação em que os desenvolvimentos ocorrem e da necessidade de atualização com o main, outras formas de merge podem ser aplicáveis. As instruções do documento https://git-scm.com/book/pt-br/v2/Branches-no-Git-Rebase podem ser utilizadas para a tomada de decisões correta.
Em caso de dúvidas ou problemas é possível se contactar o responsável pelo sistema de versionamento.
Ao receber a tarefa e começar a sua realização, o subgrupo de revisão deve informar ao gerente por e-mail para que a tarefa saia do status de To Review para o status de Review in Progress.
A revisão do código deve ser realizada conforme determinado no documento DTN.01 - Padrão de codificação (Code patterns)
O grupo de revisão pode usar ferramentas próprias para aplicar as regras do documento e determinar se os códigos estão em conformidade. Há também a possibilidade de efetuar pequenas correções em caso de resolver problemas simples. Ao terminar a revisão, o subgrupo determina se o código foi aprovado, aprovado com ressalvas (ie., quando há uma dependência a ser verificada) ou rejeitado (ie., quando não atende aos padrões estabelecidos pelo DNT.01).
Um documento contendo as informações no caso de rejeição deverá ser criado e nele devem constar informações completas sobre os problemas de código e de onde se encontram as não conformidades. Neste caso, é importante informar as porções do código onde os problemas se encontram (ie., nome(s) do(s) arquivo(s) e linha(s) em que ocorrem).
Esse documento deve ser adicionado ao github e seu link acrescentado na tarefa específica. Deverá ser enviado um email para a gerência geral dos processos para que ela dê encaminhamento, realize a reunião necessária e mude adequadamente o status das tarefas. Em caso de rejeição a tarefa sai do status de Review in Progress para To do e recebe o acréscimo do documento de não conformidade.
Em caso de aprovação, essa sai do status de Review in Progress para To Test.
Nesse ponto o gerente envia uma mensagem ao grupo de testes para que o processo dê andamento.
O grupo de testes deve informar ao gerente quando a tarefa é colocada em testes. Nesse ponto a gerência coloca o status em In Test.
Os testes a serem realizados serão de responsabilidade do subgrupo de testes. A definição dos testes está descrita no documento DNT.02 - Documento Padrão de Testes (Test Patterns).
São realizados testes de compilação e de funcionalidades simples conforme descritos no documento.
Estando completa a tarefa de testagem, o subgrupo de testes deverá gerar um documento com os resultados do teste de compilação e funcionalidade. Esse documento deve subir ao github e ter um link na tarefa. Deve-se enviar um email ao gerente informando o fim do teste e o documento. Em caso de falha de compilação ou de não atendimento dos requisitos de testes, a tarefa volta ao desenvolvimento como relatório de testes e vai novamente ao status de To do.
Em caso de aprovação nos testes a tarefa passa ao status de To performance Analisys e o subgrupo de PAD é informado para realizar a avaliação de desempenho.
O grupo de PAD avisa ao gerente quando iniciar a análise de desempenho do código. Nesse ponto a tarefa passa ao status de PAD analisys.
O subgrupo avalia se o código consegue atender aos requisitos mínimos de desempenho determinado em documento de DNT.05 - Requisitos, Análise e Otimização de Código. A maneira como o grupo atua na análise e otimização do código é determinada no mesmo documento.
O subgrupo de PAD pode realizar retrabalhos no código em prol da melhoria de performance. Se o retrabalho apresentar sucesso e o código for modificado é preciso reenviá-lo para Code Review e testes novamente.
O grupo interage com os desenvolvedores e pode dar um parecer positivo para a finalização da tarefa de desenvolvimento ou enviá-lo para retrabalho. Em todos os casos um documento de resultados é gerado e levado ao github. A tarefa recebe então o link desse documento. Em caso de parecer positivo, a tarefa entra no status To Full Tests e o gerente é informado.
Os testes funcionais completos serão executados pelo grupo de avaliação de modelos. Esse grupo tem regras próprias para a realização dos testes e não estão dentro do Grupo De COmputação Científica, GCC.
O gerente informa ao responsável dos testes funcionais completos que uma versão do código, branch monan_xx está disponível para testes completos. O Grupo de Avaliação de modelos realiza os testes e, em caso de aprovação, faz um relatório de resultados e comunica a gerência do GCC. Com isso um pull request é solicitado para subir o código para o sistema de versão como um candidato a operação.
Em caso de falha nos testes o Grupo de Avaliação comunica aos desenvolvedores e para a gerência do GCC.
O gerente do grupo de avaliação de modelos informa ao subgrupo de versionamento do GCC que uma versão foi testada eé é estável e funcional. Uma reunião é marcada entre os líderes de cada subgrupo e o(s) desenvolvedor(es). Nessa etapa decide-se se será realizada apenas um merge do branch para o trunk ou se será efetuado um release da versão (tag).
Esse novo release será um candidato a se tornar operacional, um Release Candidate (RC). Para isso a uma tag com será criada com o sufixo .RCn onde n é o número inteiro sequencial de candidatos a se tornarem operacionais. Esse número é equivalente a issue original que gerou a tarefa principal. Por exemplo: monan-RC16 para o caso exempleficado nesse documento (issue #16)
Um RC deve conter, além dos códigos e bibliotecas, um documento de entrega para a operação. Esse documento deverá conter todas as informações sobre a compilação do código, sua configuração, namelists operacionais e uma tabela com os arquivos necessários para sua operação. Esse documento deverá ser elaborado em conjunto pelos desenvolvedores e equipe de computação.
Após a liberação de um RC cabe à operação realizar os testes contínuos diários para validar a nova versão. Esses testes devem ser feitos por um período predeterminado dias que será avaliado pelos especialistas na área. Para cada rodada diária um grupo ligado à operação fará a avaliação dos resultados de forma a comparar com a versão corrente em operação e a RC. Isso pode ser feito usnado ferramentas automáticas e avaliações subjetivas, a critério da operação. Os resultados devem mostrar a comparação dos erros entre os dados observados para os dois modelos, de forma a se determinar se houve ganho ou perdas no acurácia da RC. Em caso de bugs ou erros funcionais, deve ser comunicado imediatamente aos desenvolvedores e analistas de computação.
Outro ponto a ser medido é a performance computacional do modelo, isto é, o tempo gasto para as rodadas do modelo corrente e do RC.
Ao fim do período de testes deverá ser gerado um relatório com os dados obtidos, com o aceite ou não da RC e em qualquer caso observações e recomendações. Em caso de rejeição por piora de resultados, tempos de rodadas muito longos ou combinações das duas informações o grupo de desenvolvimento e/ou o grupo de testes e computação serão informados de maneira a promoverem os ajustes na RC e dar continuidade no desenvolvimento/testes.
Em caso de aceite a RC será liberada para a operação como uma versão estável e deverá receber seu versionamento com a mudança do número da versão no primeiro dígito. Por exemplo: monan-5, monan-6, etc
O repositório main (trunk) é então atualizado (merge) com a nova versão estável.
Cabe a operação avaliar a confiabilidade do código, isto é, número de vezes em que o código não rodou, rodou após intervenções não previstas ou apresentou falha catastrófica. Esses dados devem ser comunicados ao grupo GCC para que sejam avaliado se é um bug corrigível ou se necessita de reenvio ao desenvolvimento.
Cabe ainda para a operação pontuar a acessibilidade do código (facilidade de uso). Todos os reseultados devem ser registrados e associados a RC específica.
O código, após ser levado a status operacional, deve receber manutenções contínuas. Essas manutenções podem ter caráter de ajustes na funcionalidade ou causados por bugs e mudanças no seu ambiente externo.
Testes operacionais positivos, isto é, modelo validado irá gerar uma solicitação de merge (ou push) para o GCC. Este então irá gerar uma versão estável que fará parte do sistema de distribuição do código. Essa versão receberá uma denominação numérica em sua tag. A numeração será sequencial e se a tarefa que a originou tiver uma grande modificação se altera a tag mudando o primeiro dígito, monan-6 irá virar monan-7. SE é uma pequena modificação ela receberá um dígito a mais, por exemplo, monan-6 irá virar monan-6.1.
Em casos de manutenção deverá ser aberto, ou pelo grupo de desenvolvimento, ou pelo grupo computacional, uma issue e um branch de manutenção. O trabalho deve ser realizado e a correção, ainda como um branch, passar pelos testes internos e posteriormente pelos testes operacionais para validação. Os mesmos caminhos de uma versão de desenvolvimento normal.
Após os testes serem aprovados, tags de correção serão lançadas acrescentando um ponto a mais na versão. Esse número após o ponto deve ser idêntico a issue que originou. Por exemplo, para a versão 6.1 que recebeu uma correção de bug pela issue 16 teremos: monan-6.1.16.
O main (trunk) é então atualizado (merge) com a nova versão estável e corrigida.
- Padrões de Codificação;
- ESPP - Engenharia de Software Projetos e Processos - V2. Paula Filho, W.P. - 4a Edição - UFMG - LTC Editora - 2019.