A expressão gestão das alterações (ou CM - Change Management) refere-se aos processos e ferramentas que são utilizados por uma organização ou por um projecto para planear, executar e acompanhar as alterações relacionadas com um sistema de software. A gestão unificada das alterações (ou UCM - Unified Change Management) é um processo de gestão das alterações específico desenvolvido pela Rational, em conjunto com os seus clientes.
A UCM apoia as equipas de projectos de software no seu trabalho de gestão da produção e das modificações de ficheiros, directorias, componentes e sistemas. Em termos académicos, os processos de gestão das alterações envolvem duas disciplinas: gestão de configurações de software (ou SCM - Software Configuration Management) e acompanhamento dos defeitos e das alterações (ou DCT - Defect and Change Tracking). O DCT também é conhecido por gestão dos pedidos de alterações (ou CRM - Change Request Management).
A SCM lida com processos de controlo de versões, de gestão do espaço de trabalho (workspace), de integração de software, de construções de software, de exploração de software e de versões. O DCT lida com os processos e procedimentos através dos quais são submetidos, avaliados, implementados verificados e concluídos/resolvidos os defeitos, pedidos de melhorias e novas funcionalidades.
Um nível mais elevado de abstracção com a UCM
Se olharmos para o desenvolvimento de linguagens de software, é óbvio que o nível de abstracção a partir do código máquina aumentou consideravelmente ao longo das ultimas décadas . No nível mais baixo, tudo se resume a uns e zeros e os primeiros programadores trabalhavam a este nível. Depressa surgiu a linguagem de assemblagem, que abstraía dos uns e dos zeros para fornecer instruções máquina rudimentares, nomeadamente carregamento do registo X com o valor Y.
O passo seguinte foi dado com linguagens como Pascal e C, que já forneciam construções de ordem mais elevada, nomeadamente declarações do tipo "if-then-else". Actualmente, está-se a perceber o potencial da "programação" visual. Através da modelação do comportamento dos sistemas de software, podemos fazer com que o código seja gerado. Com a introdução destas abstracções, os especialistas em desenvolvimento podem programar sistemas de software mais complexos, com maior facilidade e mais rapidamente.
Está a acontecer algo similar relativamente à evolução das ferramentas de CM. Inicialmente, estas ferramentas consistiam apenas num repositório para o armazenamento de versões. Isto quer dizer que os conteúdos de um ficheiro ou de uma directoria eram armazenados e identificados num dado ponto do tempo, podendo depois ser recuperados de acordo com as necessidades.
Depois dessa fase, surgiram ferramentas que permitiam aos utilizadores a gestão dos espaços de trabalho: um conjunto de versões específicas de ficheiros e de directorias escolhidas para uma tarefa ou actividade específica. À medida que as abstracções de mais baixo nível - como o repositório e o espaço de trabalho - se tornam comuns e amplamente aceites, podem ser acrescentadas funções de ordem mais elevada para simplificar o processo de gestão das alterações. É isso que faz a UCM.
Consideremos então as três abstracções chave cobertas pela UCM: projectos, baselines de componentes, e actividades.
Projectos
De uma forma geral, as equipas de desenvolvimento de software estão organizadas em projectos. Por sua vez, esses projectos têm subprojectos. Desta forma, um projecto pode ser muito grande ou muito pequeno. Do ponto de vista da gestão das alterações, a organização por projecto serve três propósitos:
Tudo isto pode parecer básico, mas a vantagem chave da UCM - tal como está implementada nas ferramentas ClearCase e ClearQuest da Rational - reside no facto do projecto ser um objecto físico no sistema de CM que remete para um projecto real. Isto permite um grau muito mais elevado de automação e de segurança do que aquele que seria possível se o projecto não seguisse os conceitos das ferramentas de CM.
Quando novos especialistas em desenvolvimento se juntam a um projecto UCM, por exemplo, é-lhes fornecido automaticamente um espaço de trabalho pré-configurado com as versões adequadas dos ficheiros e das directorias que necessitam.
Componentes e baselines de componentes
A segunda abstracção chave na UCM é a noção de componentes e de component baselines. A maior parte dos sistemas de controlo de versões incluem a noção de um repositório que armazena um conjunto de ficheiros e versões desses ficheiros. Algumas ferramentas - como o ClearCase - também organizam esses ficheiros em directorias e guardam as versões das directorias e dos directórios.
Quase todos os esforços de desenvolvimento significativos têm um grande número de ficheiros que contêm o código necessário para construir o sistema que está a ser desenvolvido. Os ficheiros estão organizados tipicamente em directorias e essa organização está frequentemente alinhada com a arquitectura de software do sistema.
Nos sistemas tradicionais de CM, as directorias chave não tratadas de forma diferente relativamente às outras directorias. No entanto, a UCM introduz o conceito de componente para distinguir e armazenar essas directorias. Um componente UCM é assim simplesmente uma árvore de directório constituída por ficheiros e directorias que têm um directório raiz de componente.
Mas porque razão a UCM faz isto? A principal vantagem dos componentes UCM - tal como no caso dos projectos - reside numa automação melhorada. A melhor forma de compreender isto é considerar a noção de baseline. Uma baseline identifica um conjunto relacionado de versões de ficheiro. Por outras palavras, a baseline selecciona uma versão de cada ficheiro do componente.
Praticamente todas as ferramentas de controlo de versões afirmam suportar o baselining, mas se olharmos mais de perto, em alguns casos chegaremos à conclusão que apenas suportam o conceito de labeling. O labeling é um processo através do qual seleccionamos um nome e depois o ligamos a uma ou mais versões de ficheiro. Ao ligarmos o mesmo nome a várias versões de ficheiro obtém-se uma pseudo-baseline.
O problema deste tipo de abordagem ao baselining tem a ver com facto de não existir semântica implícita no nome de label - excepto aquela que está implícita na forma como utilizamos a ferramenta. Podemos olhar para uma label e saber com certeza quais os ficheiros que lhe estão associados. Na realidade, durante o tempo que demoramos a identificar os ficheiros que têm essa label, a mesma pode ser ligada a novos ficheiros, movida para novas versões, ou retirada de um determinado ficheiro.
Evidentemente, podemos implementar controlos e tentar reforçar a nossa própria semântica de labeling. No entanto, as baselines UCM resolvem esse problema por nós. Estas baselines são objectos semanticamente ricos que identificam uma "versão" de um componente UCM. Graças à sua utilização, podemos ter a certeza de que todos os ficheiros de um componente estão associados à mesma versão.
Também podemos estar certos de que a baseline não se alterará. Uma vez criadas, as baselines UCM são imutáveis e podem ser utilizadas para a definição de configurações de mais alto nível. Por exemplo, pode-se assemblar todo um sistema a partir de um conjunto de baselines de componentes.
Actividades
Provavelmente, o aspecto mais distintivo da UCM tem a ver com o facto de ser um modelo de gestão das alterações baseado em actividades. Isto significa que as alterações a ficheiros são agrupadas de acordo com a razão das mesmas. Suponhamos que estamos a resolver um problema ou a implementar uma melhoria, por exemplo. Sempre que alterarmos um ficheiro, identificamos a razão porque estamos a efectuar essa alteração ao declararmos uma actividade na altura do checkout.
Uma actividade poderá assim ser um problema, um pedido de melhoria, ou simplesmente uma descrição de uma linha da alteração que efectuámos, dependendo do grau de rigor necessário para o nosso processo de acompanhamento de alterações e de defeitos. A UCM suporta todos estes tipos de actividades - e quaisquer outros que optemos por definir nós mesmos.
A principal vantagem da gestão das alterações baseada em actividades reside no facto de nenhum ficheiro poder ser alterado sem uma razão associada. Uma segunda vantagem reside no facto das alterações serem integradas (ou promovidas) como um todo único e consistente. Na maior parte dos casos, quando efectuamos uma alteração, precisamos de modificar múltiplos ficheiros. Por exemplo, se estivermos a resolver um problema, poderemos precisar de modificar um ficheiro C e um ficheiro header.
Com a UCM, só precisamos de seleccionar "actividade" para registar todas as novas versões criadas para todos os ficheiros. Tal como faz para os projectos e os componentes, a UCM introduz um objecto de actividade físico no sistema de CM que remete para um objecto real: a "unidade de trabalho" (ou unit-of-work). Isto tem benefícios imediatos e óbvios. Por exemplo, quando terminamos uma dada tarefa, podemos verificar todo o nosso trabalho de uma só vez, bastando olhar para a actividade.
Adicionalmente, existem benefícios de maior alcance em termos de automação e de informação. A UCM lida com as alterações do sistema ao nível da actividade. Isto quer dizer que quando estivermos prontos para integrar as nossas alterações, podemos "entregar" a actividade. Outras abordagens de CM seguem um caminho diferente, exigindo a integração de um conjunto de ficheiros, ou o envio manual de uma lista de materiais para alguém que depois irá listar as versões incluídas nas nossas alterações.
Um dos maiores benefícios da abordagem baseada em actividade tem a ver com a forma como as actividades e as baselines funcionam de forma combinada. Depois de um componente ter sido modificado por vários indivíduos, é criada uma nova baseline. Através da utilização de actividades e de baselines, é possível automatizar o processo de determinar aquilo que é diferente entre duas baselines. Esta comparação entre baselines, além de produzir uma lista de ficheiros que foram alterados de uma baseline para a seguinte, também produz uma lista de actividades.
Este facto tem grandes vantagens. Por exemplo, podemos gerar automaticamente notas de versão, bem como prestar assistência aos especialistas em testes para a determinação do conjunto de testes de regressão necessário depois das últimas alterações.
Baseado no artigo "The Power of Unified Change Management", de Brian White, director de Change Management Solutions na Rational Software.
Produzido em 2005