Além do Trabalho

Este assunto sempre dá “pano para manga”, principalmente por não haver nada que padronize e defina suas regras.

Por isto, minha idéia, aqui, foi a de compilar tudo que conheço sobre o assunto e de buscar alguns fundamentos e bases substanciais para endossar meu conhecimento.

E, o primeiro passo para realizarmos a tarefa de controlar a identificação de nossas releases é entender que as melhores práticas para definição de uma esquema para este fim não estão relacionadas apenas com o formato e a distribuição dos identificadores, mas também com algo mais abrangente denominado: Gerenciamento de Release.

Contudo, antes de definirmos este conceito, precisamos definir o significado do termo release de software, que segundo a Wikipedia é:

“release de software é uma distribuição, pública ou privada, de uma primeira ou uma nova versão atualizada de um determinado software“

Então, de forma bem pragmática, Gerenciamento de Release consiste em planejar e organizar as distribuições de seu software.

Por isto, é fundamental sabermos que uma distribuição (release) possui um ciclo de vida composto por diferentes etapas. Onde, cada qual é responsável por descrever a estabilidade do produto e também de denotar quanto desenvolvimento será necessário antes da entrega da versão final do produto.

As fases do ciclo de vida de uma release são:

Utilizar esta nomenclatura, como dito antes, auxilia no entendimento da estabilidade do produto bem como na identificação do quão distantes estamos de finalizar a implementação do produto, mas isto por si só, não determina uma identidade única para a release.

Então, para identificarmos unicamente uma distribuição utilizamos um esquema numérico(sequencial e incremental). Este esquema geralmente é composto por três números separados por pontos, por exemplo: 1.0.0.

Este esquema é o mesmo utilizado pela Apache Software Foundation para identificar as releases de seus produtos, veja:

• Esquema da Apache Foundation
  

Esquema	Nome	Características
X.x.x	Major Release	Novas funcionalidades significativas
x.X.x	Minor Release	Melhorias, refatoramentos e evoluções
x.x.X	Revision Release	Correções de bugs

Vamos agora a um exemplo prático da adoção do controle de fases e do esquema utilizado pela Apache:

Faremos o lançamento hipotético de um produto nos próximos 6 meses e definimos que este produto se chamará Sirius e que possuirá 5 funcionalidades.

A release inicial deste produto será identificada, por exemplo, como 0.0.0, o que quer dizer que é a minha primeira versão.

Durante o primeiro mês de trabalho foram implementadas duas funcionalidades e resolveu-se liberar uma versão alpha do produto para a área de homologação chamada: Sirius-0.0.0-alpha.

Durante os testes (que duraram duas semanas) foram encontrados bugs,  que foram corrigidos durante as duas semanas seguintes e liberados em uma nova versão alfa chamada: Sirius-0.0.1-alpha. Notem que a revisão da versão foi incrementada, pois somente o que foi liberado nesta release foram as correções.

Após os novos testes (duas semana depois) não foram encontrados bugs significativos e decidiu-se realizar a liberação da versão beta: Sirius-0.0.1-beta.

E, nesta mesma data, como os desenvolvedores finalizaram mais duas funcionalidades, também foi feita a liberação da versão alpha: Sirius-1.0.0-alpha.

Portanto, com  2 meses de projeto o cenário é o seguinte:

• 4 funcionalidades desenvolvidas;
• 2 funcionalidades testadas e corrigidas internamente (Sirius-0.0.1-alpha);
• 2 funcionalidades liberadas para comunidade (Sirius-0.0.1-beta gerada a partir da Sirius-0.0.1-alpha);
• 2 novas funcionalidades liberadas para testes internos (Sirius-1.0.0-alpha);

Durante o mês seguinte (3º mês), a comunidade pegou vários bugs, assim como os testes internos identificaram outros tantos. Todos estes bugs foram corrigidos e também a última funcionalidade foi desenvolvida. E, com isto, foram liberadas as seguintes versões:

• Sirius-2.0.0-alpha – correções dos bugs encontrados na release Sirius-1.0.0-alpha e liberação da última funcionalidade;
• Sirius-1.0.0-beta – 2 novas funcionalidades e correções dos bugs da release Sirius-1.0.0-alpha e correções dos bugs encontrados na release Sirius-0.0.1-beta;

E depois de mais um mês (4º mês) todos os bugs encontrados nas releases alpha e beta foram corrigidos e foi feita a liberação da versão Sirius-2.0.0-beta contendo todas as 5 funcionalidades e as correções dos bugs das releases  Sirius-2.0.0-alpha e Sirius-1.0.0-beta.

Durante o 5º mês a comunidade identificou outros bugs que foram corrigidos e originaram a release Sirius-2.0.1-alpha que foi liberada internamente e passou nos testes internos sem que houvesse a necessidade de realizar correções e por isto logo em seguida foi liberada a release Sirius-2.0.1-rc (release candidate).

Depois de vários outros testes e da utilização por parte dos usuários e da comunidade, não foram identificados bugs impeditivos e foi liberada a versão final do projeto, chamada de Sirius-2.0.1 (gold).