Changes between Version 10 and Version 11 of Projeto/Versionamento

Timestamp:

11/26/10 10:52:16 (13 years ago)

Author:

niltonneto

Comment:

Atualização do modelo de versionamento

Projeto/Versionamento

@@ -22 +22 @@
 
 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.
+
+Inserir aqui a figura 1
+
+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.
+
+Inserir aqui a figura 2
+
+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.
+
+Inserir aqui a figura 3
+
+== 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.
+
+Inserir aqui a figura 4
+
+
+'''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:
+
+Inserir aqui a figura 5
+
+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 ==
+
+A proposta apresentada, que define um 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.