Durante o processo de construção da aplicação, é necessário marcar marcos no desenvolvimento
da mesma, entendendo como mar...
Começa o desenvolvimento seguindo uma linha principal de desenvolvimento (linha do meio – Trunk),
lugar onde são agregadas...
As development version são as linhas de desenvolvimento da aplicação, isto é o lugar onde
efetivamente criamos e modificam...
Uma Frozen Version permite armazenar de forma estática momentos especiais da KB. É o elemento
que utilizamos para marcar d...
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 t...
As Frozen Version servem para:
• Analisar (não modificar) objetos, propriedades, environments, etc.
• Como fonte de um Rep...
Na versão de “Produção” vão sendo produzidas variações devido aos consertos, mas não se agrega
funcionalidades novas. As m...
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ão
paralelas, as alterações numa nã...
GeneXus gera automaticamente os programas e as estruturas da BD, partindo da versão que esteja
ativa.
Se pode marcar como ...
17 kb versoes-curso-gxxbr
17 kb versoes-curso-gxxbr
17 kb versoes-curso-gxxbr
17 kb versoes-curso-gxxbr
17 kb versoes-curso-gxxbr
17 kb versoes-curso-gxxbr
17 kb versoes-curso-gxxbr
Próximos SlideShares
Carregando em…5
×

17 kb versoes-curso-gxxbr

216 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
216
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
7
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

17 kb versoes-curso-gxxbr

  1. 1. Durante o processo de construção da aplicação, é necessário marcar marcos no desenvolvimento da mesma, entendendo como marcos o “congelamento” do desenvolvimento num determinado momento especial no processo. Isto pode acontecer por exemplo para liberar uma versão na produção, congelar uma versão entregue a um cliente, a necessidade de congelar um determinado estado especial da aplicação, etc. Além disso também vamos querer ter diferentes linhas de desenvolvimento da aplicação, algo muito comum por exemplo quando se quer fazer variações do projeto para um cliente ou quando se requer que dois grupos de trabalho o façam em paralelo e necessitamos poder realizar uma administração de todos estes elementos. O que necessitamos basicamente é administrar o “ciclo de vida” da aplicação durante o desenvolvimento. Várias destas funcionalidades entram no que no mundo do software se conhece como SCM (Software Configuración Management)
  2. 2. 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 no processo, seja pela liberação de uma versão, a entrega de uma versão a um cliente, a necessidade de congelar um determinado estado de uma aplicação, etc. Então o que fazemos é congelar o produto nesse momento criando por exemplo a versão 1.0 que a entregamos a um cliente e continua o processo de desenvolvimento principal. Em determinado momento surge a necessidade de realizar correções sobre a versão entregue ao cliente (1.0) sendo necessário abrir uma nova linha de desenvolvimento para incluir estas correções sobre o que era a versão 1.0 sem afetar a linha de desenvolvimento principal que continuou crescendo 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 nova linha de desenvolvimento paralela a principal. Depois durante o transcurso do projeto voltam a aparecer requerimentos deste tipo, seja pela determinação de checkpoints como a necessidade de abrir novas linhas de desenvolvimento, então por exemplo criamos a versão 1.1, ou a 1.0.1 que vem a ser um congelamento da linha de desenvolvimento aberta a partir da versão 1.0 e assim sucessivamente até ter por exemplo a situação estabelecida 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ão independentes entre si, existe uma linha principal e várias paralelas, a principal vem a ser o que se conhece 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 criados em determinados momentos do processo sobre as DV para determinar certos checkpoints (liberação de versão, entrega ao cliente, congelar estado, etc.)
  3. 3. As development version são as linhas de desenvolvimento da aplicação, isto é o lugar onde efetivamente criamos e modificamos a aplicação. No ciclo de vida de uma aplicação participa uma linha de desenvolvimento principal, isto é, onde começa o processo de desenvolvimento da aplicação e na qual normalmente se vai estar fazendo as modificações requeridas no avanço do projeto. Em SCM esta linha de desenvolvimento é conhecida com 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 de desenvolvimento secundárias são conhecidas como Branches e são usadas em geral para realizar correções ou pequenas alterações sobre versões congeladas ou liberadas da aplicação, ou para liberar uma versão especial para um cliente. O desenvolvimento em cada uma destas development version é independente, tendo cada versão seus 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.
  4. 4. Uma Frozen Version permite armazenar de forma estática momentos especiais da KB. É o elemento que utilizamos para marcar distintos marcos no processo, como por exemplo “feche” uma versão para liberá-la aos clientes. Se obtêm a partir de uma versão em desenvolvimento (development version), “congelando-a” para obter uma “foto” num determinado momento. A versão obtida é Read Only, que objetos da mesma não poderão ser modificados, nem tampouco suas propriedades. Sendo possível realizar ações relacionadas com a geração da aplicação, como por 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 estado consistente e seria conveniente guardar dito estado. Por exemplo, congelamos uma version X para se 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, que sabemos 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 para realizar comparações com outras versões da aplicação.
  5. 5. 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 de desenvolvimento principal é onde se implementam as funcionalidades requeridas e onde se faz a prototipaçã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 do tempo.
  6. 6. 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
  7. 7. Na versão de “Produção” vão sendo produzidas variações devido aos consertos, mas não se agrega funcionalidades 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
  8. 8. Observe que as Frozen Version mais novas, são mostradas mais acima na árvore de versões.
  9. 9. O tempo que se demora em criar uma nova Development Version é proporcional ao tamanho da KB.
  10. 10. Como as linhas de desenvolvimento do Trunk (Desenvolvimento) e de Relase 1 (Produção) são paralelas, as alterações numa não afeta a outra. Ambas versões são totalmente independentes e podemos requerer congelá-las por diferentes motivos. Por exemplo, no caso do ramo de Produção, para fixar um estado depois de certos consertos que tivemos que fazer. De acordo com a metodologia adotada, no ciclo de desenvolvimento principal, é onde se agregam novas 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ão agregam funcionalidade. Neste caso, é menos frequente a necessidade de criar Frozen Versions, mas pode ser igualmente necessário.
  11. 11. GeneXus gera automaticamente os programas e as estruturas da BD, partindo da versão que esteja ativa. 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 a aplicação ou para realizar um impacto na base de dados, ou para comparar versões. Somente pode ter uma versão ativa por vez.

×