wiki:Projeto/Versionamento

Version 21 (modified by niltonneto, 13 years ago) (diff)

--

Novo Modelo de Versionamento - Versão 2010

Objetivo

O novo modelo para o processo de versionamento dos pacotes do Expresso Livre tem como objetivo, suprir a necessidade exigida pelas empresas de gerar pacotes de versões sem periodicidade definida, ou seja, flexibilizar o processo de versionamento do pacote Expresso Livre conforme o tempo e a demanda de cada empresa que compôe a equipe de desenvolvimento do projeto. Além disso, este modelo contempla o versionamento periódico necessário para disponibilizar pacotes de novas versões à comunidade Expresso Livre.

Outro ponto, intrinsecamente ligado ao sucesso desse novo modelo, será garantir estabilidade e qualidade na linha principal de desenvolvimento do projeto, através da modificação do processo atual de desenvolvimento.

Problemática do modelo atual

Atualmente, o modelo utilizado para versionar pacotes do Expresso Livre baseia-se apenas na criação de “Branches” para estabilizar e publicar versões a todos os utilizadores da ferramenta, mesmo àqueles que fazem parte do grupo oficial de desenvolvimento.

Dessa forma, a linha principal de desenvolvimento, conhecida por “Trunk”, tornou-se um grande problema para todos que queiram gerar versões a partir do mesmo, conforme sua demanda em um determinado momento, visto que o ramo Trunk do SVN não detém nenhuma estabilidade de funcionamento em seu código armazenado.

Essa instabilidade foi adquirida ao longo dos últimos tempos, em virtude da falta de planejamento e ausência de testes e de homologação, por parte de toda equipe envolvida no desenvolvimento principal do projeto, em todos os seus módulos. A falta de bom censo contribuiu para o crescimento deste problema, já que muitos desenvolvedores efetuavam o “commit” de suas inovações, diretamente no ramo Trunk, sem nenhum controle de testes e homologação do mesmo, e principalmente, sem dimensionar os riscos envolvidos nessa operação.

Como consequência, para que o projeto não fosse prejudicado em virtude dessa instabilidade no Trunk, decidiu-se por criar branches de versões, para que então se pudesse manter o suporte das versões já lançadas, e também, planejar uma nova versão estável para a comunidade. Infelizmente, essa decisão desencadeou uma série de “efeitos colaterais”, já que muitas empresas e membros da comunidade já tinham implementado novas funcionalidades e correções diretamente no Trunk. Sem alternativa, esses colaboradores acabaram desencorajando seus esforços para manter suas contribuições na versão principal, visto que a mesma já não era confiável. Como resultado, os “forkes” acabaram sendo criados.

Por conta disso, e com grande preocupação como o futuro do projeto, o comitê gestor do Expresso Livre reuniu-se , em carácter de urgência, e aprovou um plano de unificação dessas diferentes versões, com objetivo de eliminar os “forkes” gerados e principalmente, retomar o desenvolvimento colaborativo do Expresso Livre. O ponto principal dessa unificação foi a centralização de todo o trabalho em um único nó Branch do SVN, estável, já com planejamento, testes e homologação pré-definidos, e versão nomeada como Expresso 2.2. Neste momento, o trabalho de unificação está muito bem encaminhado. Todas as empresas e demais colaboradores envolvidos seguem o cronograma definido pelo CG, mas a problemática descrita ainda é uma realidade dentro do processo de desenvolvimento do Expresso, e se não for solucionado, de nada irá adiantar todo esse trabalho de unificação.

Portanto, visando resgatar a credibilidade e a estabilidade da linha principal de desenvolvimento, bem como garantir a flexibilidade no versionamento de pacotes estáveis do Expresso a partir do Trunk, será definido um novo modelo para o processo de versionamento do Expresso Livre.

Em que se baseia o novo modelo

Como já foi dito, a proposta do novo modelo baseia-se intrinsecamente na manutenção de uma linha principal de desenvolvimento com estabilidade e qualidade em sua codificação, de modo que, a qualquer momento, qualquer versão do pacote ExpressoLivre? poderá ser gerada sem nenhum problema.

A ideia que será apresentada não é nova, e existe há algum tempo dentro do desenvolvimento de grandes projetos mantidos por empresas e comunidades no mundo do software livre. Um exemplo interessante a ser citado e seguido é o próprio Kernel do Linux.

O Kernel do Linux, a partir da versão 2.6.x, sofreu modificações no seu modelo de versionamento, tornando-se bem mais rigoroso, e tendo como base o fator tempo. Em um evento ocorrido em 2005, o grupo principal de desenvolvedores do kernel decidiu que suas versões futuras sairiam em intervalos de 2 a 3 meses, com cada lançamento sendo um “grande” lançamento, no qual seriam incluídos novos recursos e mudanças internas nas APIs.

O ciclo rápido de lançamentos foi escolhido como uma forma de trazer novos recursos aos usuários de uma forma estável com o mínimo de atraso possível. Como resultado, o novo código – recursos, drivers de dispositivos etc. – ficaria disponível em um kernel estável com poucos meses de sua conclusão, minimizando ou eliminando a necessidade das distribuições Linux criarem patches para as suas versões estáveis. Assim sendo, os kernels lançados pelas diversas “distLinux” contêm muito poucas modificações específicas da distribuição, rendendo alta estabilidade e poucas diferenças entre distribuições.

Modelo do Kernel Linux

Portanto, cada versão 2.6.x é uma versão estável, a qual é liberada quando a lista de grandes bugs se torna tão pequena quanto possível. Se houver problemas logo após um lançamento de kernel, as respectivas correções são rapidamente disponibilizadas para comunidade, através do repositório que contém sua linha principal de desenvolvimento.

Outro exemplo interessante é o modelo de versionamento do Ubuntu, que lança a cada dois anos uma versão LTS (Long Term Support), e as demais, são lançadas ao longo do tempo, conforme correções e melhorias são concluídas. A diferença entre uma versão normal e uma LTS está no suporte a longo prazo, já que esse último possui três anos – para desktop - e cinco anos – para servidor.

Modelo do Ubuntu

Ambos os modelos citados fazem o uso de uma linha principal de desenvolvimento, e de ciclos curtos para lançamento de versões. Além disso, trabalham com branches para suporte posterior das versões lançadas, onde são publicadas as correções de bugs e vulnerabilidadas de segurança. É importante salientar que os exemplos descritos foram utilizados somente para auxiliar na definição do novo modelo, ou seja, não foram levados em consideração seus ciclos de versionamento ou nomenclatura das suas versões. Mas a ideia será bem parecida.

O Processo de Desenvolvimento

Para que o novo processo de versionamento funcione a contento, será necessário retomar o Trunk do SVN, como sendo a linha principal de desenvolvimento das versões futuras do Expresso Livre.

Essa redefinição deverá acontecer a partir do lançamento da versão 2.2 - primeira versão publicada para a comunidade Expresso Livre - e onde a mesma será copiada integralmente para o Trunk.

No entanto, o processo de desenvolvimento no Trunk deverá ser modificado, para que se garanta estabilidade e qualidade no código mantido nesse ramo SVN, uma vez que todas as versões subsequentes serão geradas a partir dele.

Este processo será formado por ciclos curtos e longos gerados a partir do ramo Trunk, onde os curtos poderão ser demandados por clientes, ao tempo de cada empresa, para a entrega de novas funcionalidades e correções. Já os ciclos longos, serão iterações com prazos mais longos de entrega, com publicações oficiais de versões para a comunidade, e que irão se beneficiar com a conclusão dos ciclos curtos finalizados anteriormente.

Outra diferença está na criação de um branch permanente para cada versão gerada dentro de um ciclo longo, já que as publicadas para a comunidade deverão ter suporte a correções de bugs e vulnerabilidades de segurança, por um período maior de tempo. Melhorias e novas funcionalidades não serão replicadas nesses branches.

Modelo TimeLine Expresso

O Processo de Testes

O processo de Testes irá garantir qualidade na entrega de toda nova versão gerada, tanto por ciclos curtos quanto por longos e deverá ser executado por todos os envolvidos. Mas é importante frizar que, a responsabilidade da execução do processo de testes no ciclo curto será de quem gerou a demanda. O processo de testes deverá contemplar os seguintes passos:

1.Criação de um branch a partir do ramo Trunk para garantir o “congelamento” da versão a ser testada;

2.Criação de uma tag inicial no ramo Tags, para sinalizar a primeira iteração do ciclo de testes;

3.Criação de tags incrementais dentro do ramo Tags, a cada iteração necessária;

4.Criação de uma tag final com mesmo nome do branch criado, para finalizar e aprovar o ciclo de testes.

Modelo Processo de Testes do Expresso

IMPORTANTE

Independente do ciclo ou do processo a ser trabalhado pelos desenvolvedores, é importante se lembrar de duas regras extremamente importantes para o correto funcionamento desse modelo:

Primeiro - O ramo Tags deve continuar sendo um repositório para sinalizar as versões e as iterações concluídas nos processos de teste e desenvolvimento. NUNCA deverá receber commits de código.

Segundo - Todo commit de correção efetuado nos branches deve ser replicado no ramo Trunk, e nos demais branches de suporte, desde que seja aplicável.

A numeração das versões

Atualmente, a numeração das versões dos pacotes Expresso Livre, incluindo API e seus módulos, baseia-se na seguinte definição:

Modelo numeração do versionamento atual

Este padrão de numeração é bastante simples, mas não atende às empresas que participam do desenvolvimento do Expresso. Muitas delas, trabalham na manutenção e no suporte de versões customizadas ao longo do tempo, para seus clientes, e precisam de mais informações sobre qual versão exata está implantada em um determinado cliente.

Como o novo modelo propôe um único ramo principal de desenvolvimento para todos (ramo Trunk do SVN), suas versões subsequentes deverão respeitar um padrão único de identificação, e sinalizar com o mínimo de informação possível, a origem do seu empacotamento. Para que isso seja possível, algumas regras deverão ser adotadas para a implantação do novo modelo:

  • As versões geradas por ciclos longos deverão ter final par;
  • As versões geradas por ciclos curtos deverão ter final ímpar;
  • As numerações da API e dos módulos, bem como rotinas de atualização de banco (setup), deverão ser incrementadas apenas a cada ciclo longo, ou seja, versões publicadas para a comunidade. Nos ciclos curtos essa alteração deverá ser desconsiderada;
  • A numeração do branch ou tag final deverá ser a mesma que o pacote gerado pelo script;
  • O padrão atual da numeração para versões publicadas para a comunidade será mantido, a cada ciclo longo completado, reduzindo apenas a quantidade de dígitos do último grupo: 2.2.004 => 2.2.4
  • Para os ciclos curtos, deverá ser adicionado ao lado da numeração atual, o número da revisão do SVN utilizada para gerar a versão. A adição dessa numeração será feita pelo mesmo script de empacotamento já implementado pela equipe do SERPRO, para ajudar na coleta de informações sobre a revisão utilizada na versão gerada. Deverá ser exibida no rodapé das telas de login e de setup do Expresso. Terá o seguinte formato, conforme esse exemplo: 2.2.3 - R3448

Conclusão

O novo modelo para o processo de versionamento dos pacotes do Expresso Livre, deve estar de pleno acordo com as necessidades demandadas pelas empresas que participam do comitê gestor. A dificuldade atual no desenvolvimento mútuo entre as empresas, com tempos e demandas diferentes, fizeram com que todo este processo fosse remodelado.

Outro fator, extremamente importante para garantir o sucesso na implantação desse processo, se deve à estabilização do código existente no ramo Trunk, que deverá ser retomado após a finalização da primeira versão do Expresso 2.2. A utilização de ciclos curtos e longos no desenvolvimento do projeto irá garantir a estabilidade no código do Trunk.

Por outro lado, o processo de testes será utilizado com maior frequência, e por conta disso, irá garantir estabilidade nas versões geradas a qualquer tempo, por qualquer empresa. As versões geradas para a comunidade sairão com maior estabilidade e terão menos versões de correções, já que serão frutos das versões geradas pelas empresas.

Mais informações

  • Este modelo foi

aprovado

em 24 de novembro de 2010, pelo Comitê Técnico do Projeto Expresso Livre.

  • Baixe aqui o documento apresentado como proposta para o novo modelo de versionamento.

Attachments