Controle de Versão

Conceitos Gerais Sobre Controle de Versão

Versões e Variantes

Durante o desenvolvimento do projeto, a mudança dos itens é feita até eles atingirem o que foi especificado. Isto ocorre quando os itens são revisados, aprovados, acrescentados a uma baseline e movidos para um ambiente controlado. Mas isso não termina aqui, pois ocorrem checkout no itens, mudanças são implementadas, são realizados testes, revisões, aprovações e novamente são acrescentados a uma baseline.

Uma versão é um release inicial ou um re-release da mudança de um conjunto de itens do projeto. É uma instância do sistema que difere de algum modo de outras instâncias. Novas versões do sistema devem conter novas funcionalidades ou funcionalidades já existentes, mas com mudanças. Por exemplo, novas versões devem conter caracteristicas diferentes de antigas versões ou por exemplo correções de bugs que foram identificados por desenvolvedores, testadores ou usuários.

É importante lembrar que algumas versões podem ser funcionalmente equivalentes, mas o design do projeto pode ter sofrido alterações. Nesse caso, podemos considerar isso variantes. Após o fechamento de uma versão, correções/evoluções que forem realizadas serão adicionadas nas parciais, até o fechamento de uma nova versão. A principio uma estratégia interessante é adotar o fechamento de uma versão sempre no término de uma iteração.

A existência de diferentes versões representa a estória de um item de software, ou seja, ela explica como um item foi transformado ou evoluído desde o ponto inicial até o seu estágio corrente. Iremos criar sempre uma nova versão realizando um checkout da cópia mais recente e acrescentando mudanças a esta.

Processo de build e Defeitos críticos

Defeitos críticos são encontrados e corrigidos no software. Dependendo de quão críticos, há uma necessidade de garantir que os mesmos não voltarão a se manifestar em uma nova versão. Para isso definir prioridades dos defeitos encontrados no software é importante. Muita comunicação é essencial entre o time de desenvolvimento, com o propósito de rastrear tais defeitos e propor soluções para os mesmos. A equipe fará o rastreamento dos bugs sob sua responsabilidade e notificará o cliente, para cada entrega, quais as correções e pendências. Além disso, fornecer soluções e prazos para os defeitos que se manifestam em uma nova versão do software.

Versões parciais para deploy

Para cada deploy que for executado no ambiente de homologação, para que sejam realizados os testes, será criada uma versão parcial no controlador de versão, e a mesma será automaticamente instalada no servidor de testes ( Plano de Integracao Continua). Com isso, é possível saber exatamente a situação do projeto em cada momento que ele passou por baterias de testes, onde cruzamos essas informações com uma ferramenta de track (Bugzilla) e temos uma visão precisa do conjunto de features/correções que faziam parte da versão/versão parcial que foi testada, e como estava a situação de cada feature/correção na data dos testes. Existe uma linha de codificação chamada de produção com o propósito de receber somente versões estáveis do software.

Desenvolvimento Paralelo - Branching

Para cada item de software que é realizado um checkout, mudanças são feitas e testadas, revisadas, aprovadas e então ocorre o cheked-in. Dessa forma, as versões seguem uma forma linear.

fig1.png

Porém precisamos lidar com situações onde teremos desenvolvimento que não seguirão uma forma linear (é o que acontece na viada real), nesses casos trabalharemos com branch. Branches são desvios do caminho principal das versões. É um mecanismo conveniente para permitir duas ou mais pessoas trabalharem em um mesmo item de software simult‰neamente - paralelamente, desenvolvimento concorrente - mesmo que para tarefas diferentes. Um cenário comum é termos pessoas trabalhando para adicionar novas features ao software, enquanto outras pessoas aplicão correções a versões anteriores.

fig2.png

O nœmero de versões de branches podem se tornar um pouco confuso, para garantir que não tenhamos problemas caso seja necessário criar mais de um branch para um caminho principal, é interessante adotar a seguinte denominação: Por exemplo, para um branch criado a partir da versão 1.3, será assumido o nœmero iniciando em 1.3.1.0. Caso seja necessário criar um segundo branch a partir do caminho principal 1.3, será assumido o nœmero 1.3.2.0. Veja o exemplo a seguir:

fig3.png

Objetivo de usar os branches é permitir um desenvolvimento paralelo e concorrente em um simples arquivo. Em algum momento as alterações ocorridas em um item de software pertencente a um branch, devem ser incorporados ao caminho principal para o item alterado. Quando isso ocorre, estaremos realizando um merge entre as alterações realizadas por pessoas diferentes. Se as alterações foram realizadas em partes diferentes do item de software, o merge sera realizado de forma automatica e fácil, mas caso as alterações ocorreram na mesma parte do item de software, o merge será um trabalho cuidadoso, de forma a decidir o que manter. O cliente CVS do Eclipse automatiza e facilita o merge, onde a ferramenta compara as porções de mudanças ocorridas entre dois arquivos (o original e o do branch) e o responsável pode escolher quais mudanças aceitar. Tente manter como principio sempre utilizar o merge manual, pois a analise humana é melhor que a analise da ferramenta.

Label para os builds

Todos os itens de software terão nomes, e esses nomes poderão ser formados por:

  • Tipo de Build
    • Tipo de build pode ser para testes internos (QA) ou release (REL)
  • Versão
    • Numero da versão. Ex.: 1_3_0
  • Numero do build
    • Um numero unico que identifica cada build.
  • Data
    • Seguindo o formato ano, mês e dia do build, dessa forma os builds podem ser ordenados por esse campo.
  • Situação especial
    • Pode adicionar alguma situação especial, ou informação no final do label. Ex.: BETA, ALPHA

Exemplo de nomenclatura QA#1_3_0#129#20051029.

Esse label deve ser descritivo. Por exemplo, um projeto grande com vários módulo e subsistemas, um simples nome para a configuração de um item não é uma boa ideia. Para esses casos, o nome deve ter elementos do projeto, subsistema, módulo e outro detalhes que tornem fácil identificar o projeto ou subsistema. A parte do nome referente ao nœmero deve ser designada de modo a determinar a posição relativa na hierarquia da versão. Por exemplo, definimos a primeira versão como 1_0, e revisões subsequentes como 1_1, 1_2, 2_0, 2_1 e assim por diante. A versão do branch 1.1 será identificada como 1.1.1.0 e as versões subsequentes 1_1_1_1 e assim por diante. A segunda versão do branch será identificada como 1_1_2_0 e assim por diante.

Processo de Building das aplicações

O processo de build é a combinação dos arquivos fonte em componentes do sistemas, os quais são executados para uma configuração específica. O sistema ou partes dele, são recompilados após qualquer mudança ocorrida no código fonte.

O build automático do sistema pode ser feito usando um comando específico do Maven, ou através de um agendamento gerenciado pelo Cruise Control - utilizado para automação de integração contínua -( Plano de Integracao Continua). Com a combinação dessas ferramentas realizamos builds controlados, de versões específicas, locais específicos e em tempos determinados pela equipe, seja a de desenvolvimento ou teste. Com o uso dessas ferramentas facilmente podemos reproduzir uma configuração específica do sistema, sem perder o track do desenvolvimento.

Utilizar o processo automatizado de build diário, como forma de eliminar erros de builds, executar bateria de testes unitários e gerar relatórios para acompanhamento do projeto. Ter o plano de integração contínua vinculado ao processo de versionamento. Esse processo reproduz vários builds, incluindo testes que rodam várias vezes durante o dia. Isso permite a cada desenvolvedor integrar diariamente, reduzindo os problemas de integração. Sendo assim, no término de cada ciclo tem-se uma versão definitiva do produto que é disponibilizada na linha de produção para a equipe de teste. Existem alguns pontos para o funcionamento de um build diário:

  • Manter todo o código fonte em um unico local onde qualquer um da equipe possa obte-los(inclusive versões anteriores dos códigos). Isso poderá ser feito em um CVS instaldo localmente na empresa.
  • Automatizar o processo de build para que qualquer um da equipe possa através de um simples comando executar o build da aplicação a partir dos fontes.
  • Automatizar os testes ao ponto que possam rodar as suítes de testes sobre a aplicação a qualquer momento, e a partir de um simples comando.
  • Ter certeza que qualquer um consiga obter uma versão executavel, a qual confiamos ser o melhor executável no momento.

Releases

Uma release consiste mais do que apenas código executável, inclui arquivos de configuração, dados, documentação, entre outros. A release de um sistema é um conjunto de itens que são entregues ao usuário. Cada release de sistema inclui novas funcionalidades, features, correções de bugs ou melhorias identificadas pelos usuários, desenvolvedores ou testadores. Geralmente existirão em nosso projeto mais revisões(versões parciais) do que releases.

Utilizar também o Bugzilla como um mec‰nismo para gerenciar os detalhes de cada release, ou seja, todas as features, correções de bugs, novas funcionalidades entre outros, é interessante.

Cada release gerada deve conter identificadores indicando a versão e deve também incluir notas contendo informações como as seguintes:

  • Requisitos de instalação.
  • Lista de limitações e bugs existentes nessa release em particular, tão como a lista de bugs corrijidos para a release corrente.
  • Novas features introduzidas na release

O foco de cada entregas é estar bem estruturada, tal como proposto em cada conjunto de features concluídas. Cada entrega demanda uma verificação mínima de consistência. As versões são enviadas para outros times remotamente localizados a fim de executar testes de diversos tipos.

A equipe é responsável pelo ciclo de vida de sua respectiva linha de codificação (atualizações, commits, rotulação e entregas oficiais).

Designação: Nomenclatura de configuração dos itens de software

Uma das definições que mais gosto, é a definição do IEEE, onde os métodos de identificação podem incluir na nomenclatura nœmeros da versão e letras. Utilizando a identificação do sistema ou conveção por nomes deve facilitar o armazenamento, busca, tracking, reprodução e distribuição das versões. Um bom nome utiliza numeros e letras para representar a posição das versões na hierarquia. Por exemplo, o label 1.4 é definitivamente criado após um item com o label 1.2 e antes do label 1.6. A outra parte do nome, a qual define o item, é derivada do projeto ou sistema. Procure sempre utilizar um nome simples, como por exemplo 'CS4J' indicando o projeto. A decisão da complexidade e detalhes do nome virão de acordo com o tamanho e complexidade do projeto. Um ponto importante que precisamos saber, é não produzir nomes duplicados, pois isso pode gerar confusão no desenvolvimento do projeto.

Deltas

Durante o desenvolvimento dos projetos é comum trabalharmos com a geração de muitas versões, versões parciais e variantes. O nosso foco é armazenar todas as mudanças ocorridas nos itens de softwares, para as versões e derivações geradas. Isto porque nem sempre teremos usuários usando a ultima versão do sistema, dessa forma podemos ter a versão 6.0 do sistema e um usuário usando a versão 4.0. Com isso precisamos saber detalhes de cada versão e produzir de forma fácil e simples todos os componentes de cada versão e suas derivações ja existentes. Cópias de todas as versões devem estar armazenadas no repositório. O nosso foco é trabalhar com delta. Quando uma nova versão for criada, a diferença entre essa nova versão e a anterior é chamada de delta. Dessa forma, ao invés de armazenarmos cópias completas de todas as versões, somente os deltas serão armazenados.

fig4.png

Deltas são menores do que uma versão, em termos de código fonte, com isso será necessário um espaço em disco menor para armazenar as versões do projeto.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License