Processo de Auditoria e Controle do GGAS

De Wiki Colaborativa do SISP
Ir para: navegação, pesquisa

O sistema GGAS é o Sistema de Gestão Comercial de Gás Natural que visa atender, de forma abrangente, as necessidades inerentes à Área comercial de uma empresa distribuidora de gás natural e possibilita a gestão dos cadastros, da medição, dos contratos, do faturamento (incluindo emissão das NF-e's), da cobrança, da arrecadação além de disponibilizar dados para a integração com sistemas da área contábil, financeira, operacional e gerencial.

Aqui descrevemos, de forma técnica, mas resumida, o funcionamento do Processo de Auditoria e Controle de versões que funcionará a partir de 01/03/2015 para todas as empresas prestadoras de serviço do sistema GGAS contratadas pelas Companhias Distribuidoras Locais (CDL) de gás natural que possuam contratos de desenvolvimento, implantação e manutenção (preventiva e corretiva).

Processo de Auditoria e Controle do GGAS - Introdução[editar]

Analisando resumidamente o cenário em 2014, tem-se o formato no qual inúmeras distribuidoras firmaram contratos com um fornecedor para a prestação de serviços de implantação, manutenção evolutiva e manutenção corretiva do sistema GGAS. Após essas implementações, é feita a unificação dos códigos-fonte em uma única versão para posterior publicação dessa versão no Portal do Software Público Brasileiro para que as outras distribuidoras possam baixar as novas versões e utilizar o sistema, conforme ilustrado a título de exemplo na Figura 2.

Figura 2 - Cenário atual de desenvolvimento do sistema GGAS (imagem meramente ilustrativa).

Em função do cenário onde empresas utilizadoras do sistema GGAS (CDLs), estando essas em diferentes estágios de maturidade no processo de implantação e manutenção deste sistema, e ainda diante da possibilidade de outros players do segmento de desenvolvimento de sistemas (fornecedores) serem indicados, a partir dos processos de contratação que avizinham, como sendo vencedores destes, tem-se um ambiente extremamente propício para que a unidade de código-fonte, padronização de processos e manutenção da base de dados deste sistema mantidos até então seja perdido.

Dentro do contexto apresentado na análise do cenário atual, pode-se levantar os seguintes questionamentos:

  1. Quem audita a qualidade do código produzido pelos fornecedores?
  2. Quem controla a evolução de um único produto desenvolvido por vários fornecedores simultaneamente?
  3. Qual é a periodicidade para disponibilização de versões no Portal do Software Público?
  4. Qual o processo necessário para submeter códigos do GGAS para a versão única do produto?
  5. Como as LDCs podem contribuir no desenvolvimento de alguma Funcionalidade e/ou Bug?

Motivado pelos questionamentos acima, as distribuidoras, através da implementação de um ambiente centralizado de desenvolvimento distribuído, denominado de "Ambiente de Controle de Qualidade e Processo de Auditoria" (File:Processo_de_Auditoria_e_Controle_do_GGAS.pdf), visa alcançar, de forma mais efetiva do que o vem sido praticado atualmente, o controle de versionamento, a auditoria e a inspeção de código-fonte do sistema de faturamento denominado GGAS, hospedado no Portal do Software Público, visando assim, aumentar o desempenho/performance no processamento das rotinas do sistema, a atualização tecnológica dos componentes utilizados por este software, bem como contribuir para o processo e disseminação do conhecimento das tecnologias utilizadas no seu desenvolvimento e de outras relacionadas no processo de desenvolvimento distribuído de sistemas/versões.

Figura 3 – Inclusão da empresa mantenedora do processo de desenvolvimento do GGAS.

A partir dessa implementação pode-se verificar que o projeto de desenvolvimento do GGAS será mantido em um ambiente gerenciado e centralizado de desenvolvimento distribuído de sistemas, podendo, a partir desse, efetuar todos os controles já mencionados anteriormente. Visando a melhoria contínua dos serviços e eficiência atualmente implementados no GGAS, será estabelecido um processo completo e bem definido para dar suporte a evolução funcional do sistema.

O processo de Testes e Auditoria[editar]

Através do processo de controle de versão implementado nesse ambiente, as CDLs continuarão firmando contratos de implantação, manutenção evolutiva e corretiva com os diferentes fornecedores, porém, ao invés dos fornecedores trabalharem isoladamente e cada um evoluindo uma versão especifica do sistema, o que acabaria por ter-se posteriormente diferentes versões disponíveis no Portal do Software Público e, consequentemente, gerando custos duplicados para as CDLs uma vez que as mesmas poderão estar custeando o desenvolvimento de uma funcionalidade já desenvolvida por outra CDL com outro fornecedor em uma outra versão.

Assim sendo, o desenvolvimento de todos os fornecedores deverá, quando concluído, ser submetido na infraestrutura do Git central do GGAS, mantido no endereço [1], e cada submissão passará por um processo de controle de qualidade e auditoria. Caso todas as etapas do processo sejam concluídas com êxito, as implementações feitas por esses fornecedores serão promovidas para a versão única do sistema e esta versão será disponibilizada no Portal do Software Público para acesso das demais CDLs, conforme pode ser visualizado na Figura 4.

Figura 4 – Processo de Controle e Auditoria Proposto para o Sistema GGAS.

Sendo assim, o processo de testes e auditoria estabelecido para a evolução funcional do sistema GGAS seguira o estabelecido na Figura 5.

Figura 5 – Workflow do processo de Controle e Auditoria do sistema GGAS.

De acordo com a figura 5, as ferramentas utilizadas no processo são:

Sistemas de Controle de Versão:

  • Git (v. 7.5.1);
  • Integração Contínua
  • Jenkins (v. 1.596);
  • Sonar (v. 5.0.0);

Para o processo de testes:

  • Junit (v. 4.11);
  • Selenium (v. 2.8.0);
  • Testes Exploratórios;
  • Testes de Performance;

Para o processo de auditoria de código:

  • EclEmma (v. 2.3.2);
  • Sonar Way (v. 5.0.0);
  • FindBugs (v. 3.0.0);
  • Técnica de Revisão Formal (TRF);

Os arquivos (incluindo código fonte) do sistema GGAS serão armazenados num sistema de controle de versão remoto Git, disponível em: [2]. O processo será executado a cada submissão de código ao servidor do Git e passará pelas seguintes etapas:

  1. Jenkins: Compila o código fonte;
  2. Jenkins: Constrói o pacote de trabalho;
  3. Jenkins: Executa os testes unitários disponíveis na versão;
  4. Jenkins: Implanta em um servidor de homologação;
  5. Jenkins: Aciona o sonar para a auditoria automática de código;
  6. Sonar: Executa a ferramenta de inspeção automática com o profile Sonar Way e o FindBugs;
  7. Sonar: Executa a ferramenta EclEmma para aferir os testes automáticos;
  8. Sonar: Notifica a finalização dos testes automatizados e notifica a equipe de análise de conformidade de código fonte para início do processo de inspeção manual de código;
  9. Equipe de Conformidade: Executa os testes do Selenium;
  10. Equipe de Conformidade: Executa os testes funcionais;
  11. Equipe de Conformidade: Executa os testes de performance;
  12. Equipe de Conformidade: Executa o processo de auditoria manual do código;

Caso alguma das etapas descritas até o passo 7 indicadas acima falhem, a submissão será rejeitada e o fornecedor que está enviado as implementações será notificado para que ele promova as correções.

Caso todas as etapas descritas acima executem com sucesso, a submissão será promovida a versão principal do sistema e disponibilizada na próxima versão do GGAS. Vale salientar que as etapas 9, 10, 11 e 12 do processo descrito acima podem não ser executas em uma determinada submissão, ou seja, essas etapas são opcionais dentro do processo estabelecido.

Gerenciamento e Acompanhamento do Processo[editar]

Para gerenciamento do fluxo estabelecido pelo processo de evolução funcional do sistema GGAS, será utilizada a ferramenta Redmine, um software livre e de código aberto, licenciado sob os termos da GNU General Public License v2 (GPL). Foi desenvolvido na linguagem Ruby utilizando o framework Ruby on Rails. É uma ferramenta multiplataforma que suporta vários bancos de dados, extensões de plugins e sistema de controle de versão. Abaixo segue a relação das fortes características dessa ferramenta:

  • Vários projetos de apoio;
  • Controle de acesso baseado em papel flexível (Controle de acesso);
  • Flexibilidade no sistema de monitoramento;
  • Gráfico e calendários;
  • Gerenciamento de notícias, arquivos e documentos;
  • Fórum, wiki do projeto;
  • Gerenciamento de tempo (projetos e usuário);
  • Integração a sistemas de controle de versões (SVN/Git);
  • Suporte a autenticação LDAP;
  • Suporte a multilinguagem;
  • Vários bancos de dados.

Para mais informações sobre o Redmine, recomenda-se o estudo do Guia Oficial. Para acessar a ferramenta Redmine utilizada para controlar o projeto GGAS, deve-se acessar o endereço: [3]; realizar o cadastro da empresa no link Cadastre-se, e aguardar a ativação do seu usuário pela Equipe de Conformidade. As requisições serão cadastradas no menu Nova Tarefa do Redmine, e seguirão os seguintes estados dentro do processo de controle e auditoria do código, conforme apresentado na Figura 6.

Figura 6 – Estados das requisições no processo de Controle e Auditoria do sistema GGAS.

De acordo com a Figura 6, os usuários da ferramenta poderão pertencer a três categorias de perfis de usuário:

Perfis de Usuário do Sistema GGAS[editar]

  1. CDL: Esse perfil de acesso será dado aos usuários pertencentes as Companhias Distribuidoras Locais (CDLs – Bahiagás, PBGás, Algǵas, e etc.). São estes usuários que iniciarão o processo ao criar uma tarefa na ferramenta. Essa tarefa pode representar qualquer necessidade de implementação no sistema GGAS e pode variar desde a solicitação de implementação de um simples botão, à implementação de um novo módulo. A granularidade de cada tarefa, será definido pela própria CDL e conjunto com o fornecedor. Salienta-se que, toda e qualquer entrega de código por parte dos fornecedores, deverão estar vinculadas a pelo menos uma tarefa no sistema Redmine. Além de criar tarefas, esse perfil de acesso é o único que poderá modificar a tarefa para os seguintes status: Nova, Em Negociação, Cancelada e Atribuída. Este último status, é quando uma CDL conclui o processo de negociação (custo, tempo, escopo e etc) com o fornecedor e atribui a atividade ao mesmo, a partir disso, apenas usuários com o perfil de acesso Fornecedor, poderão modificar a tarefa.
  2. Fornecedor: Esse perfil de acesso será dado aos usuários pertencentes aos fornecedores que tiverem contratos de implantação e/ou manutenção evolutiva e corretiva do sistema GGAS, para com as CDLs. Estes usuários receberão as tarefas atribuídas pelas CDLs e poderão modificar o status para Aguardando Criação de Branch, na qual o fornecedor indicará para o mantenedor que está aguardando a criação de um novo branch de trabalho; Em Andamento, nesse momento cada fornecedor trabalhará dentro do seu processo específico de desenvolvimento e poderá modificar o status da tarefa para Concluída ou Cancelada. Para o caso das tarefas Concluídas, os fornecedores poderão colocá-las no status Disponível para Merge em Master e isso indicará que eles mesclaram o código produzido na Branch Master do fornecedor e este código está disponível para avaliação da qualidade no processo de testes e auditoria realizado pelos usuários com perfil Mantenedor.
  3. Mantenedor: Esse perfil de acesso será dado aos usuários pertencentes à Equipe de Conformidade, que serão responsáveis por iniciar, após receberem as submissões de código enviada pelos fornecedores, o processo de testes e auditoria de código. O processo de testes e auditoria seguira o descrito na Figura 5 e, caso todas as etapas sejam concluídas com sucesso, os status das tarefas poderão ser modificados para: Integrado ao Develop; Aguardando Integração na Mainline; Integrada na MainLine; Aguardando Liberação de Versão e Disponível em Versão.

As tarefas cadastradas no Redmine, poderão estar, em um dado momento, nos status descritos abaixo:

Status disponíveis no Redmine do GGAS[editar]

  • Nova: Indica que a tarefa foi criada pelo usuário de perfil CDL e que ainda não iniciou o processo de negociação com o fornecedor. Desta forma, todo o backlog do sistema que ainda não tenha iniciado o desenvolvimento, estará com esse status.
  • Em Negociação: Indica que deu-se inicio ao processo de negociação para desenvolvimento da demanda especificada na tarefa. Essa negociação, em alguns fornecedores, envolve atividades como reuniões para definição e detalhamento do escopo, estimativas de prazos e custos, entre outras.
  • Cancelada: Indica que a demanda especificada pela tarefa não será mais atendida, ou seja, ela está cancelada. A tarefa poderá ir para esse status em dois momentos, ou após a conclusão do status Em Negociação, quando uma CDL não aprova o orçamento estabelecido pela negociação da tarefa, ou após o início do desenvolvimento da tarefa pelo Fornecedor (status Em Andamento), em virtude de algum problema técnico e devidamente alinhado com a CDL proprietária da tarefa.
  • Atribuída: Indica que a negociação para desenvolvimento da tarefa foi concluída e o fornecedor poderá iniciar o desenvolvimento da mesma.
  • Aguardando Criação de Branch: Indica que o Fornecedor está aguardando que o Mantenedor crie uma Branch para o Fornecedor começar o desenvolvimento do escopo indicado na Requisição;
  • Branch Criado.
  • Aguardando Início do Desenvolvimento: Indica que o Mantenedor já criou a Branch de trabalho e que o fornecedor pode iniciar o desenvolvimento da Requisição.
  • Em Andamento: Indica que o fornecedor iniciou o desenvolvimento da tarefa.
  • Concluída: Indica que o fornecedor concluiu o desenvolvimento da tarefa, porém, ainda não disponibilizou a mesma para o processo de auditoria e controle de qualidade. Nesse status a tarefa ainda está sob responsabilidade do fornecedor e a mesma está aguardando algum processo interno para disponibilização ao mantenedor.
  • Disponível para Merge: Indica que o fornecedor concluiu a tarefa e submeteu para o servidor Git remoto para ser avaliada no processo de controle de qualidade e auditoria do código desenvolvido.
  • Em Processo de Testes e Auditoria: Indica que a tarefa está passando por todas as etapas do processo de controle de qualidade e auditoria do código, demonstradas na Figura 5.
  • Rejeitada: Indica que tarefa não passou por alguma etapa do controle de qualidade e auditoria e está sendo devolvida ao fornecedor para as devidas correções.
  • Integrado ao Develop: Indica que o processo de testes e auditoria do código foi executado com sucesso no Branch Master do Fornecedor e que o código foi mesclado ao Branch Develop para dar início aos testes de integração.
  • Aguardando Integração na Mainline: Indica que a tarefa foi aprovada em todas as etapas do processo de controle de qualidade e auditoria do código e está aguardando a Equipe de Conformidade realizar o merge a versão principal do sistema.
  • Aguardando Liberação de Versão: Indica que a tarefa foi integrada a versão principal do sistema e está aguardando a próxima liberação de versão por parte da Equipe de Conformidade.
  • Disponível em Versão: Indica que a tarefa está disponível na versão para distribuição através do Portal do Software Público Brasileiro.


Vale ressaltar que o Redmine não substituirá a ferramenta de bug tracking dos fornecedores, ou seja, os bugs encontrados pelas CDLs continuarão sendo cadastrados nas ferramentas de cada fornecedor para controle dos seus respectivos SLAs estabelecidos em cada contrato. O que deverá ocorrer é que, como todas as requisições para serem incorporadas a versão principal do sistema, devem estar necessariamente vinculadas a uma tarefa no Redmine, consequente esta tarefa deverá ser criada no Redmine para passar pelo processo de auditoria e controle de qualidade como qualquer requisição normal.

Regra para Aceitação das Submissões[editar]

Para que o código produzido pelo Fornecedor/CDL seja aceito, e consequentemente mesclado para o Branch Develop pelo mantenedor, ele deverá antes passar por todas as etapas descritas na Figura 5. Desta forma, os critérios para aceitação do código seguirá a regra abaixo:

  1. O Jenkins deve conseguir compilar o código fonte com sucesso;
  2. O Jenkins deve conseguir construir o pacote de trabalho com sucesso;
  3. O Jenkins deve executar os testes unitários disponíveis na versão e TODOS os testes devem retornar sucesso em sua execução;
  4. O Sonar deve executar a ferramenta de inspeção automática do código com o profile Sonar Way e FindBugs e TODOS os níveis de não conformidades NÃO poderão, em hipótese alguma, subir as quantidades anteriormente indicadas no Sonar. Os níveis de não conformidade configurados são: 1.Blocker, 2.Critical, 3.Major, 4.Minor, 5.Info . Por exemplo, se a quantidade de não conformidades do tipo Critical for 445, em um dado momento do projeto, e após a submissão do fornecedor ela aumentar para 446 (ou qualquer número superior) o código será classificado com rejeitado, ou seja, ele não atendeu ao critério 4 deste conjunto de regras e o fornecedor deverá corrigi-lo até que ele seja menor ou igual a 445.
  5. O Sonar deve executar a ferramenta EclEmma para aferir a cobertura dos testes automáticos e, se o percentual de cobertura do código for igual ou inferior ao percentual anteriormente indicado no Sonar, o código será classificado como rejeitado, ou seja, ele não atendeu ao critério 5 deste conjunto de regras e o fornecedor deverá corrigi-lo até que ele seja obrigatoriamente superior ao percentual de testes automáticos anteriormente indicado na ferramenta.
  6. A Equipe de Conformidade do Mantenedor, deve executar uma bateria de testes realizando testes automatizados no Selenium, testes funcionais exploratórios e

testes de performance. Caso algum Bug crítico seja encontrado e a Equipe de Conformidade considerar este suficientemente relevante, esta Equipe deverá registrar uma nota técnica na própria tarefa de requisição da ferramenta Redmine, e a CDL proprietária da tarefa, será convidada a decidir pela rejeição ou não da submissão. Caso a CDL opte pela não aprovação do código, o mesmo será classificado como rejeitado, ou seja, ele não atendeu ao critério 6 deste conjunto de regras e o fornecedor deverá corrigi-lo para que o código possa ser mesclado ao Branch Develop.

  1. A Equipe de Conformidade do Mantenedor deve realizar o processo de inspeção manual do código e NÃO deve encontrar não conformidades no código submetido pelo Fornecedor/CDL. Caso a não conformidade seja encontrada, e a Equipe de Conformidade considerar esta suficientemente relevante, esta Equipe deverá registrar uma nota técnica na própria tarefa de requisição da ferramenta Redmine, e a CDL proprietária da tarefa, será convidada a decidir pela rejeição ou não da submissão. Caso a CDL opte pela não aprovação do código, o mesmo será classificado como rejeitado, ou seja, ele não atendeu ao critério 7 deste conjunto de regras e o fornecedor deverá corrigi-lo para que o código possa ser mesclado ao Branch Develop.

Caso todas as 7 regras descritas anteriormente passem com sucesso, o código será classificado como apto para ser mesclado ao Branch Develop pelo Mantenedor.


Resultados Esperados[editar]

Com a implementação do processo proposto, espera-se obter os seguintes resultados:

  • Melhorar a qualidade e, consequentemente, a confiabilidade das versões disponibilizadas pelos fornecedores contratados pelas CDLs;
  • Proporcionar um repositório centralizado com o código fonte do projeto para que diferentes fornecedores e CDLs, posam ter acesso e contribuir para a evolução

do sistema;

  • Evitar que, quando da existência de mais de um fornecedor, sejam criadas várias versões do sistema GGAS. A existência de diferentes versões do GGAS, poderia trazer os seguintes problemas:
    • Perca da padronização de processos e boas práticas entre as CDLs, uma vez que as mesmas começariam a trabalhar de forma isolada com seus respectivos fornecedores;
    • Perca da uniformização da base de dados, o que tornaria mais complicado um processo futuro de extração de informações estratégicas por parte dos acionistas;
    • Não aproveitar a oportunidade de interação e troca de conhecimentos entre as CDLs;
    • Possibilidade de uma CDL pagar por uma funcionalidade na versão x, sendo que esta já está desenvolvida na versão y, ocasionando custos duplicados para companhias do mesmo grupo.
  • Contribuir e orientar os fornecedores com boas práticas de engenharia de software, de forma a maximizar a produtividade e qualidade do código fonte produzido no sistema GGAS.

Fluxo de Desenvolvimento do Projeto[editar]

Fluxo de Trabalho no Git[editar]

Conforme dito em sessões anteriores, o processo de trabalho proposto utilizará o sistema de controle de versão Git. Mas antes de apresentar o fluxo, faz-se necessário um bom entendimento do conceito de Branch.

Quase todos os Sistemas de Controle de Versão têm alguma forma de suporte a ramificação (branching). Criar um branch significa que você vai clonar a última versão da linha principal de desenvolvimento e continuar a trabalhar em possíveis bugs e novas funcionalidades sem bagunçar a linha principal de produção que provavelmente está no ar e não pode receber falhas. Desta forma, pode-se dizer que um branch é uma cópia do projeto. Cada branch pode ser editado e evoluído independentemente em linhas paralelas a linha principal do projeto.

Dentro do processo proposto, haverá um fluxo de trabalho baseado no desenvolvimento com várias linhas de desenvolvimento (branches) podendo o branch ser o Master principal (caixa verde da Figura 8), Develop (caixa vermelha), Master do Fornecedor/CDL (caixas em azul-claro), de Features do Fornecedor/CDL (círculos azul-escuro) ou de Bugfixes (círculos rosas), conforme pode ser visualizado na Figura 8.

Figura 8 – Exemplo do Fluxo de Trabalho do GGAS no Git.

Neste fluxo, os branches Master e Develop são considerados históricos – isso porque eles guardarão a história do projeto. As tags de marcação de release são feitas no Master e o Develop serve como branch de integração para branches de features de fornecedores e/ou CDLs. A versão disponibilizada na linha principal do projeto (Master) receberá o número de versão 1.0.0 e será evoluída conforme descrito na sessão 6.4 deste documento.

A Figura 8 mostra um exemplo hipotético de um determinado momento do ciclo de desenvolvimento do GGAS, na ilustração, é clonado o projeto na versão 1.0.0 do branch Master para o Branch Develop e depois para Branch do Fornecedor B. Isso significa que o Fornecedor B iniciará o desenvolvimento de alguma Requisição de trabalho de uma CDL. Desta forma, será disponibilizada o Branch para o Fornecedor B que poderá cloná-la para um repositório local nas estações de trabalho da sua própria empresa, o Fornecedor B trabalhará por algum tempo naquela Requisição e, durante esse tempo, ele poderá dar vários commits no seu repositório local.

Quando a requisição estiver totalmente pronta, o fornecedor dará um Push (envia as modificações para o servidor) para o Branch do servidor remoto (representadas nas bolas azul escuras) e o fornecedor fará o merge para a sua Branch principal (representada na bola azul clara), assim que o Branch principal do fornecedor for atualizado, será dado automaticamente o start para o processo de auditoria automática do código e logo em seguida para todas as etapas previstas no processo de Controle e Auditoria do sistema GGAS.

Caso o código avaliado no branch principal do Fornecedor B passe pelos critérios de qualidade estabelecidos no processo e seja aprovado, o Mantenedor será notificado e ele será mesclado no Branch Develop pelo Mantenedor.

O branch Develop será o Branch que conterá os merges de todos os fornecedores/CDLs antes de irem para a versão oficial do sistema, desta forma, quando chegar um código no Branch Develop proveniente do merge dos Branches dos fornecedores/CDLs, esse código também será auditado no processo de Controle e Auditoria do sistema. Caso todas as etapas do processo de controle de qualidade passem com sucesso, o Mantenedor fará um merge para o Master e será gerada uma versão para a disponibilização no Portal de Software Público.

Em virtude do exposto, tem-se que o processo de Controle e Auditoria do sistema será executado em dois momentos dentro do ciclo de vida de uma requisição de trabalho. O primeiro momento será quando do merge do fornecedor para o seu respectivo Branch principal e o segundo momento será quando do merge do código do Branch do fornecedor para o Branch Develop que terá o código concluído de todos os fornecedores. Passados por esses dois momentos de auditoria, a requisição do fornecedor será incluída na versão disponibilizada no Master.

Outro ponto importante a ser explicado na figura, é o funcionamento do Branch Hotfix (representados pelas bolas rosa claro). Cada fornecedor terá nenhum ou vários Branches de Hotfix que serão criados pelo Mantenedor no momento que for aberta uma requisição de correção no Redmine. Ao concluir a correção, o fornecedor dará o push no código e, assim que o servidor receber as modificações, o processo de Controle e Auditoria do sistema será executado, ou seja, todos os Branches de Hotfix criados pelo Mantenedor para os fornecedores, também serão monitorados pelo processo de auditoria automática do código.

Caso todas as etapas passem com sucesso, o fornecedor será notificado e ele poderá gerar uma versão emergencial e disponibilizá-la para seu respectivo cliente (CDL). Após entregar a versão emergencial para a CDL, o fornecedor deverá obrigatoriamente fazer um merge para o seu Branch principal. Quando o código chegar na linha principal, será rodado o processo de auditoria e o Mantenedor será notificado quando da conclusão com sucesso, este fará o merge para a Branch Develp e posteriormente para o Master, onde o código de correção realizado pelo fornecedor poderá ser disponibilizado na versão principal do sistema.

Etapas do processo de correção de bugs[editar]

Em síntese, o processo de correção de bugs seguirá as seguintes etapas:

  1. É aberto uma requisição de trabalho no Redmine para correção do(s) problema(s);
  2. O mantenedor cria um Branch de Hotfix para o fornecedor com a última versão do código disponível no Portal de Software Público;
  3. O Fornecedor atua e conclui as correções especificadas na requisição aberta;
  4. O Fornecedor dá um Push no código do Branch de Hotfix;
  5. O servidor reconhece a atualização do código do Branch de Hotfix e roda o processo de auditoria automática do código;
  6. Após o sucesso do processo de auditoria, o Fornecedor é notificado e o mesmo gera uma versão emergencial a partir do Branch de Hotfix e disponibiliza a CDL;
  7. O Fornecedor faz o merge do código do Branch de Hotfix para a seu Branch principal;
  8. O servidor reconhece a atualização do código do Branch principal do fornecedor e roda o processo de auditoria automática do código;
  9. Após o sucesso do processo de auditoria, o mantenedor será notificado e este fará o merge para o Branch Develop e posteriormente para o Master.

Vale salientar a importância do passo 7 no processo descrito acima, essa atividade é obrigatória por parte do fornecedor e caso o mesmo não faça o merge para o seu Branch principal, a correção ficará armazenada apenas no Branch de Hotfix, isso resultará na perca do código de correção quando o fornecedor atualizar a versão do sistema a partir do Portal de Software Público.

O objetivo deste fluxo de trabalho é possibilitar o desenvolvimento em paralelo de vários fornecedores simultaneamente através da utilização boas práticas de controle de versionamento de sistemas e de técnicas e ferramentas eficientes e consolidados na indústria de engenharia de software.

Regra de Nomenclatura dos branches[editar]

O projeto possuirá Branches fixos e Branches criados sobre demanda. Os Branches fixos são:

  • GGAS
    • MASTER – utilizado pelo mantenedor.
    • DEVELOP – utilizado pelo mantenedor.
  • MANTENEDOR
    • MASTER – linha principal do mantenedor.
  • FORNECEDOR A
    • MASTER – linha principal do fornecedor A.
  • FORNECEDOR B
    • MASTER – linha principal do fornecedor B.
  • CDL A
    • MASTER – linha principal da CDL A.

Desta forma, cada ator terá no mínimo uma linha principal de desenvolvimento.

Os Branches sob demanda serão criados para atendimento de requisições de trabalho do Redmine (Tarefas cadastradas pelas CDLs), para atendimento de novas funcionalidades e/ou correção de Bugs. Esses Branches sob demanda seguirão o seguinte padrão de nomenclatura:

<nome fornecedor> _ <tipo do branch> _ <número da tarefa do redmine>.

O Branch poderá ser de dois tipos:

  • DEV: para indicar branches de novas funcionalidades;
  • HOTFIX: para indicar branches de correções;

Desta forma, a estrutura de Branches existentes no projeto poderá ser representada pelo exemplo abaixo:

  • GGAS
    • MASTER – utilizado pelo mantenedor.
    • DEVELOP – utilizado pelo mantenedor.
  • MANTENEDOR
    • MASTER – linha principal do mantenedor.
    • MANTENEDOR_DEV_7764
    • MANTENEDOR_DEV_8810
    • MANTENEDOR_HOTFIX_0909
  • FORNECEDOR A
    • MASTER – linha principal do fornecedor A.
    • FORNECEDOR A_DEV_1122
    • FORNECEDOR A_DEV_1414
    • FORNECEDOR A_DEV_9851
  • FORNECEDOR B
    • MASTER – linha principal do fornecedor B.
    • FORNECEDOR A_DEV_8712
    • FORNECEDOR A_HOTFIX_0010
    • FORNECEDOR A_HOTFIX_0011
    • FORNECEDOR A_HOTFIX_0801
  • CDL A
    • MASTER – linha principal da CDL A.
    • CDL A_HOTFIX_7410

Regra da Numeração do Versionamento[editar]

A versão disponibilizada na linha principal do projeto (Master) receberá o número de versão 1.0.0 e evoluirá de acordo com a seguinte regra:

  • O primeiro número, antes do primeiro ponto (3.8.2), representará a versão principal do sistema e será incrementado apenas no caso de alterações significativas. Por exemplo, quando da mudança da arquitetura interna do sistema, quando da mudança da interface gráfica, quando da inclusão de um novo módulo com representação significativa dentro do sistema e etc. Desta forma, se a versão do GGAS for, por exemplo, 3.8.2, pode se dizer que os sistema está na sua 3a. Versão.
  • O segundo número, após o primeiro ponto (3.8.2), representará a disponibilização de novas funcionalidades significativas ou não dentro da versão atual do sistema. Por exemplo, quando da inclusão de novas informações em alguma tela, ou a inclusão de alguma nova regra de negócio de algum processo interno. Desta forma, se a versão do GGAS for, por exemplo, 3.8.2, pode se dizer que já foram disponibilizadas 8 versões com novas funcionalidades para a 3a. versão do sistema.
  • O terceiro número, após o segundo ponto (3.8.2), representará a disponibilização de versões de correção para a versão atual do sistema. Por exemplo, quando da necessidade de se corrigir algum bug em uma tela, ou alguma regra de negócio implementada incorretamente. Desta forma, se a versão do GGAS for, por exemplo, 3.8.2, pode se dizer que já foram disponibilizadas 2 versões de correção para a versão 3.8 do sistema.

Mais Informações[editar]

Para mais informações, acesse Processo de Auditoria e Controle do GGAS.pdf.