Padrões de Gerência de Configuração com Subversion 1.5 - Parte I: Conceitos

Padrões são uma constante em Engenharia de Software há pelo menos 14 anos. Não digo nenhuma novidade agora ao afirmar que o trabalho seminal sobre padrões foi o GoF. E que este foi inspirado no trabalho do arquiteto Christopher Alexander na década de 70. Já faz parte do evangelho.

Talvez o que escape ao "senso comum" seja a explosão de patterns através das disciplinas da Engenharia de Software. Alguns exemplos são Análise, Implementação, Modelagem de Dados, Desenvolvimento de Aplicações Corporativas, Integração de Aplicações Corporativas, Arquitetura de Software, Requisitos, Casos de Uso, Modelagem de Negócio, e Documentação.



Quando me vi às voltas da gerência de configuração pela primeira vez, decidi adotar uma abordagem mais pragmática. Ao invés de me inteirar e cair de cabeça na disciplina de gerência de configuracão como um li lateralmente (skimming) alguns livros de SCM. Depois resolvi me guiar por dois livros específicos, primeiramente o livro de Padrões de Configuração Software Configuration Patterns e depois para implantação do Subversion como servidor SCM me guiei pelo livro Pragmatic Configuration Management with Subversion, 2nd. ed. Hoje as soluções implementadas de acordo com estes dois guias estão rodando com sucesso.

Pretendo escrever um arco de 3 posts. Aqui vou explorar Padrões de Gerência de Configuração. No segundo, pretendo escolher determinados cenários e mostrar quais são os patterns adequados para resolução dos problemas. Por fim mostrarei como implementá-los em um sistema de controle de versão, mais especificamente o Subversion 1.5.

Software Configuration Management - Gerência de Configuração de Software em uma Casca de Noz

Gerência de Configuração diz respeito à configuração, identificação, controle de configuração, prestação de contas, revisão, gerenciamento de build, gerenciamento de processo e trabalho em grupo. Estas práticas definem como uma organização contrói e lança produtos bem como identifica e rastreia mudanças.

Em termos mais simples SCM é a função de rastrear e controlar mudanças em um software. Podemos exemplificar o objetivo da SCM com a seguinte pergunta: "Alguém fez alguma coisa, como posso reproduzi-la?".

A SCM atende esta pergunta através do estabelecimento de práticas como, por exemplo, controle de revisões e baselines.

Controle de revisão trata do gerenciamento de múltiplas revisões de um determinado artefato, como documento ou arquivo de fonte. A intenção é fazer com que as mudanças em um determinado arquivo sob controle de versão (chamado de item de configuração) sejam armazenadas a medida que o usuário for atualizando o arquivo possibilitando a reprodução gradativa das mudanças.

Uma baseline é uma marcação que identifica um certo estado significativo dentro de um conjunto de mudanças realizadas em um histórico de revisões. Um estado significativo em desenvolvimento de software é a aprovação de um conjunto de revisões de um determinado grupo de itens de configuração.

Alguns conceitos importantes para a SCM são workspaces e codelines.

Uma workspace (não confundir com a workspace do IDE como o Eclipse) é um local, como um diretório na estação de trabalho, onde o desenvolvedor mantém todos artefatos necessários para a conclusão de uma tarefa. A workspace é uma cópia associada a uma versão específica dos artefatos.

Uma codeline é a progressão de um conjunto de arquivos referente às mudanças atribuídas ao software no decorrer do tempo. Cada mudança cria uma nova revisão de um determinado artefato.

Em um determinado ponto do tempo, uma codeline pode conter um conjunto de várias revisões de cada componente gerenciado como item de configuração.

Quando determinadas tarefas divergem do propósito original de uma codeline, pode haver a necessidade de se bifurcar um codeline produzindo duas concorrentes. Isto permite a evolução indepente de um determinado item de configuração. Esta operação é chamada de branch (ou ramificação, não sei como os teóricos traduzem nestes dias...). Uma mudança de propósito pode ser a aproximação da release 2 do software, enquanto o trabalho para a release 3 não pode ser retardado por questões de cronograma.

Supondo que a release foi efetuada, ocorre a necessidade de incorporar as mudanças da release 2.1 e 2.2 na release 3. Isto pode ser feito através de uma operação de merge (ou mescla) das modificações do branch da release 2 de volta à codeline principal do produto.

SCM Patterns

Padrões de Gerência de Configuração foram organizados originalmente por Stephen P. Berczuk e Brad Appleton no livro Software Configuration Management Patterns: Effective Teamwork, Practical Integration (também são catalogados no site SCM Patterns for Agility).

Patterns são boas soluções para problemas recorrentes dentro de um determinado contexto (no caso SCM). É uma espécie de reuso de idéias, a grosso modo, uma receita de bolo. Um pattern é o empacotamento de um conhecimento útil para a resolução de problemas num contexto.

Um pattern pode ser organizado dentro de um contexto mairo através de uma pattern language. Uma pattern language é a forma de disposição das soluções (isto é, os patterns individuais) em um contexto onde já há outras soluções implementadas.

Um pattern é especificado sob a forma de um template específico para o contexto de sua aplicação. Em SCM temos os seguintes componentes no template:

• Título
• Ilustração
• Contexto
• Problema
• Descrição detalhada do problema
• Solução
• Descrição detalhada da solução
• Questões em aberto

Classificação de SCM Patterns

Um SCM Pattern é classificado como um padrão de Codeline ou padrão de Workspace, indicando sua aplicabilidade mais adequada. No mapa da SCM Pattern Language podemos identificar o relacionamento dos Patterns em relação a outros para compor uma solução mais abrangente. Em destaque vermelho podemos ver os patterns referentes à codeline. Em verde, os patterns cabíveis ao contexto de workspace.

Segue uma breve descrição dos SCM Patterns e sua aplicabilidade por categoria.

Padrões de Codeline

• Mainline (Linha Principal): Minimizar merges e manter o número de linhas de código ativo gerenciável pelo desenvolvimento sobre uma Mainline.
  
• Active Development Line (Linha de Desenvolvimento Ativo): Manter uma codeline em rápida evolução suficientemente estável para ser usável pela criação de uma Active Development Line.
  
• Release Line (Linha de Release): Manter versões entregues sem que estas interfiram no desenvolvimento atual pelo estabelecimento de uma Release Line.
  
• Private Versions (Versões Privadas): Usar Private Versions para habilitar experimentos com mudanças complexas localmente, ao mesmo passo que seja possível usufruir das features de um sistema de controle de versão.
  
• Task Branch (Branch de Tarefa): Manter parte da quipe executando tarefas disruptivas sem forçar que o resto da equipe trabalhe em torno destas pelo uso de um Task Branch.
  
• Release Prep-Codeline (Codeline de Preparação de Release):
• Codeline Policy (Política de Codeline): Criar uma Codeline Policy para ajudar os desenvolvedores a decidir quando realizar o check-in de código para uma codeline e quais os procedimentos seguir antes de realizar o check-in em cada codeline.
  

Padrões de Workspace

• Private Workspace (Workspace Privada): Prevenir que problemas de integração afetem o seu desenvolvimento e que suas mudanças causem outros problemas através da Private Workspace.
  
• Integration Build (Build de Integração): Garantir que sua base de código senore seja construída de forma confiável pela execução periódica de um Integration Build.
  
• Repository (Repositório): Configurar uma nova workspace populando-a a partir de um Repository contendo tudo que você precisa.
  
• Private System Build (Build Privado do Sistema): Verificar se suas mudanças não irão quebrar o build pela execução de Private System Build antes de commitar mudanças para o repositório.
  
• Smoke Test (Teste de Fumaça): Assegurar que o sistema ainda funciona após uma mudança através da execução de um Smoke Test.
  
• Unit Test (Teste unitário): Verificar que o módulo ainda funciona após uma mudança pela execução de um Unit Test.
• Regression Test (Teste de Regressão): Assegurar que o código existente não se degrade a media que você faça novas melhorias pela execução de um Regression Test.
  
• Task Level Commit (Commit de Nível de Tarefa): Organize mudanças no código-fonte através unidades de trabalho orentadas a tarefas e submeta mudanças como um Task level Commit.
  
• Third Party Codeline (Codeline de Terceiros): Gerencia código de fornecedores pelo uso de uma Third Party Codeline.
  

Um cartão de referência dos SCM patterns pode ser encontrado (inclusive com o mapa da pattern language) aqui.

Conclusão

Aqui fiz uma breve revisão sobre alguns conceitos de SCM Patterns. Iniciei com alguns conceitos básicos sobre SCM e descorri sobre os padrões definidos pelo Appleton e pelo Berczuk. Estes padrões já apliquei com sucesso em dois grandes sistemas, um legado onde não havia política de gerência de configuração e outro grande conjunto de sistemas federados iniciado do zero. Em ambos os casos os padrões se demonstraram muito eficientes para atender tanto na manutenção de um sistema como no desenvolvimento de outro.