Um pouco mais sobre Gerência de Configuração

          Após uma introdução sobre o  O que é Gerência de Configuração, que foi feita em um post anterior, entendemos e aceitamos de uma melhor forma a importância que a utilização da GC tem dentro de empresas de TI. É através da GC que problemas comuns do dia-a-dia no desenvolvimento de software são minimizados. Só que entender somente o que é a GC não é suficiente. É necessário ter em mente termos, conceitos e definições ligados a GC e que serão utilizados durante a execução de ferramentas e práticas.

Uma dúvida que pode ter surgido é: O que é essa configuração que tem que ser gerenciada?

Todos os itens que são produzidos durante o desenvolvimento de software e que precisam ser controlados , como códigos fontes, bibliotecas de componentes e documentos diversos, representam a configuração que será gerenciada. Cada artefato, que representa uma entidade única e estará sujeito a mudanças, é um item dessa configuração.

Outros conceitos importantes:

•  Repositório - O repositório é o local (físico e lógico) onde os itens de configuração ou simplesmente uma configuração é guardada. É ele o responsável por armazenar a árvore de versões, controlar o acesso aos itens, etc.
  
• Tag - Nada mais é que uma marcação, um rótulo que é associado a um conjunto de itens de configuração no repositório. As Tags são utilizadas quando há a necessidade de se criar uma build, um branch, uma release ou um baseline por exemplo. (A Figura ao lado mostra exemplo de tags dentro do repositório. Na versão 2 foi criado uma marcação/tag chamada build - 1.0. Na versão 3 foram criadas duas marcações, build - 2.0 e baseline - 1.0).
• Build - Build representa uma versão do software em desenvolvimento que é liberada geralmente para se realizar testes. Na figura acima, foram criadas duas tags, build - 1.0 e build - 2.0, que podem ser utilizadas para testar a versão a qual representam.
• Baseline - É uma marcação que serve para informar que uma configuração está estável. Na imagem acima, a versão 3 foi marcada como build - 2.0 . Após o sucesso na realização dos testes, a versão foi marcada novamente como baseline - 1.0, ou seja, seria uma versão estável do software em desenvolvimento.
• Release - Uma release é a marcação que caracteriza uma entrega, uma liberação de uma versão do sistema ao cliente e/ou mercado. Um release é criado através de baselines, que são versões estáveis do sistema, pois foram testadados com a liberação de builds.
• Branch - É a criação de uma linha de desenvolvimento paralelo à principal. Suponhamos que foi liberada uma release para o cliente. O software continua a ser desenvolvido e ter suas versões incrementadas. Só que o cliente encontra um problema na versão que lhe foi liberado, ou seja, uma versão já desatualizada. Para a correção é criada uma linha paralela de desenvolvimento ou simplesmente um branch, que evita impactar no andamento do desenvolvimento das novas versões. Um outro exemplo de utilização seria para empresas que possuem produtos que são liberados para mais de um cliente e para cada cliente existe uma implementação específica. Neste caso, são criados vários branches que irão representar os clientes.  

 Mas, se o que foi corrigido em uma branch poder ser implementado na versão atual em desenvolvimento, o que pode ser feito para se evitar retrabalho? ...Merge!

Merge -  O merge é a unificação de diferentes versões. Caso implementações realizadas em uma branch de correção pudessem ser utilizadas na versão atual, o procedimento mais prático é a utilização de merge nos artefatos. Existem ferramentas que realizão esse procedimento automáticamente, porém algumas vezes será necessário a intervenção manual.