Durante o processo de construção da aplicação, é necessário marcar marcos no desenvolvimentoda mesma, entendendo como marcos o “congelamento” do desenvolvimento num determinadomomento especial no processo. Isto pode acontecer por exemplo para liberar uma versão naprodução, congelar uma versão entregue a um cliente, a necessidade de congelar um determinadoestado especial da aplicação, etc.

Além disso também vamos querer ter diferentes linhas de desenvolvimento da aplicação, algo muitocomum por exemplo quando se quer fazer variações do projeto para um cliente ou quando se requerque dois grupos de trabalho o façam em paralelo e necessitamos poder realizar uma administraçãode todos estes elementos.

O que necessitamos basicamente é administrar o “ciclo de vida” da aplicação durante odesenvolvimento. Várias destas funcionalidades entram no que no mundo do software se conhececomo SCM (Software Configuración Management)

Começa o desenvolvimento seguindo uma linha principal de desenvolvimento (linha do meio – Trunk),lugar onde são agregadas as funcionalidades requeridas e são utilizados protótipos para prová-las .

Em determinados momentos deste ciclo surge a necessidade de estabelecer um checkpoint noprocesso, seja pela liberação de uma versão, a entrega de uma versão a um cliente, a necessidadede congelar um determinado estado de uma aplicação, etc. Então o que fazemos é congelar oproduto nesse momento criando por exemplo a versão 1.0 que a entregamos a um cliente e continuao processo de desenvolvimento principal.

Em determinado momento surge a necessidade de realizar correções sobre a versão entregue aocliente (1.0) sendo necessário abrir uma nova linha de desenvolvimento para incluir estas correçõessobre o que era a versão 1.0 sem afetar a linha de desenvolvimento principal que continuoucrescendo desde o momento que foi congelada a versão 1.0.Então se cria o que se conhece como Developmen Version ou branch, que é simplesmente uma novalinha de desenvolvimento paralela a principal.

Depois durante o transcurso do projeto voltam a aparecer requerimentos deste tipo, seja peladeterminação de checkpoints como a necessidade de abrir novas linhas de desenvolvimento, entãopor exemplo criamos a versão 1.1, ou a 1.0.1 que vem a ser um congelamento da linha dedesenvolvimento aberta a partir da versão 1.0 e assim sucessivamente até ter por exemplo a situaçãoestabelecida no diagrama.

Estas situações formam parte da operação normal no desenvolvimento de uma aplicação e énecessário administrar este processo de forma fácil..Para isso se introduz o conceito de Gerência de Versões. As versões são classificadas em:

•Development Versions, representam as linhas de desenvolvimento da aplicação as quais sãoindependentes entre si, existe uma linha principal e várias paralelas, a principal vem a ser o que seconhece como Trunk e as demais seriam o que em SCM se conhece como Branches•Frozen Versions (também conhecidas como Labels em SCM), representam as congeladas criadosem determinados momentos do processo sobre as DV para determinar certos checkpoints (liberaçãode versão, entrega ao cliente, congelar estado, etc.)

As development version são as linhas de desenvolvimento da aplicação, isto é o lugar ondeefetivamente criamos e modificamos a aplicação.

No ciclo de vida de uma aplicação participa uma linha de desenvolvimento principal, isto é, ondecomeça o processo de desenvolvimento da aplicação e na qual normalmente se vai estar fazendo asmodificações requeridas no avanço do projeto. Em SCM esta linha de desenvolvimento é conhecidacom o nome de Trunk.

Além desta linha principal poderão existir uma ou várias linhas de desenvolvimento secundárias,totalmente independentes da linha principal e independentes entre si. Em SCM estas linhas dedesenvolvimento secundárias são conhecidas como Branches e são usadas em geral para realizarcorreções ou pequenas alterações sobre versões congeladas ou liberadas da aplicação, ou paraliberar uma versão especial para um cliente.

O desenvolvimento em cada uma destas development version é independente, tendo cada versãoseus próprios objetos, sua própria base de dados, ambientes para gerar a aplicação, etc.

Uma Development Version, é então, uma cópia da KB editável e independente.

Uma Frozen Version permite armazenar de forma estática momentos especiais da KB. É o elementoque utilizamos para marcar distintos marcos no processo, como por exemplo “feche” uma versãopara liberá-la aos clientes.

Se obtêm a partir de uma versão em desenvolvimento (development version), “congelando-a” paraobter uma “foto” num determinado momento.

A versão obtida é Read Only, que objetos da mesma não poderão ser modificados, nem tampoucosuas propriedades. Sendo possível realizar ações relacionadas com a geração da aplicação, comopor exemplo a criação da base de dados ou a geração novamente dos programas.

Quando congelamos uma versão é porque determinamos que a mesma está em um estadoconsistente e seria conveniente guardar dito estado. Por exemplo, congelamos uma version X parase dar aos clientes, em determinado momento, enquanto o processo de desenvolvimento continua,um novo cliente requer a aplicação, então o que fazermos é gerar a mesma na version X, quesabemos que tem um estado correto e a instalamos ao novo cliente.

Se os objetos não poder ser modificados, podem ser abertos para distintas consultas ou pararealizar comparações com outras versões da aplicação.

Partimos do nó raiz da árvore de versões, o qual se cria ao criar a KB.

A aplicação vai sofrendo alterações a medida que transcorre o ciclo de desenvolvimento. A linha dedesenvolvimento principal é onde se implementam as funcionalidades requeridas e onde se faz aprototipação.

Esta linha de desenvolvimento geralmente coincide com o Trunk, ou seja com a ramo principal daárvore de versões. É uma Development Version criada por default quando a KB é criada.

A medida que as modificações na aplicação são realizadas, a mesma vai se alterando ao longo dotempo.

As Frozen Version servem para:

• Analisar (não modificar) objetos, propriedades, environments, etc.

• Como fonte de um Reporte de Análise de Impacto da base de dados

• Para criar a base de dados

• Para regerar todos os programas

Na versão de “Produção” vão sendo produzidas variações devido aos consertos, mas não se agregafuncionalidades novas. As mesmas são agregadas na linha de desenvolvimento principal.

As Development Version servem para:

- Trabalhar numa linha de desenvolvimento paralela a principal

- Como fonte ou destino de uma operation de Revert a partir de uma Frozen Version de Backup

Observe que as Frozen Version mais novas, são mostradas mais acima na árvore de versões.

O tempo que se demora em criar uma nova Development Version é proporcional ao tamanho da KB.

Como as linhas de desenvolvimento do Trunk (Desenvolvimento) e de Relase 1 (Produção) sãoparalelas, as alterações numa não afeta a outra.

Ambas versões são totalmente independentes e podemos requerer congelá-las por diferentesmotivos. Por exemplo, no caso do ramo de Produção, para fixar um estado depois de certosconsertos que tivemos que fazer.

De acordo com a metodologia adotada, no ciclo de desenvolvimento principal, é onde se agregamnovas funcionalidades, consertos, alterações importantes na aplicação, prototipação e testing. Émais frequente que seja necessária “fotos” nessa etapa viva do desenvolvimento da aplicação.

No ramo do Release1, as alterações são menores, mais certos consertos circunstanciais que nãoagregam funcionalidade. Neste caso, é menos frequente a necessidade de criar Frozen Versions,mas pode ser igualmente necessário.

GeneXus gera automaticamente os programas e as estruturas da BD, partindo da versão que estejaativa.

Se pode marcar como ativa uma versão em desenvolvimento ou uma versão congelada. Nesteúltimo caso, não poderemos fazer nenhuma modificação a mesma, somente utilizá-la para gerar aaplicação ou para realizar um impacto na base de dados, ou para comparar versões.

Somente pode ter uma versão ativa por vez.