A gestão de configurações (ou SCM - Software Configuration Management) é o herói invisível do desenvolvimento de software. Isso acontece porque quando se está a trabalhar com grande eficiência, as soluções de SCM dificilmente são percebidas. Na realidade, devem ser transparentes para os utilizadores, libertando os especialistas em desenvolvimento para programarem sem processos complicados. Por outro lado, raramente se dá pela SCM, a não ser que seja intrusiva ou apresente problemas de funcionamento.
Quanto melhor funcionar a gestão de configurações, menos ouvimos falar dela ou lhe damos o real valor. No entanto, a razão porque a SCM é o herói deve-se ao facto de uma boa gestão de configurações de software dar origem a um retorno do investimento (ROI) positivo. Este retorno é conseguido através do aumento da produtividade das equipas e da protecção dos activos dos projectos.
Mas como é que a SCM se traduz em valor de negócio? Essencialmente de três formas:
Dada a complexidade actual do desenvolvimento de software, existem várias formas de melhorar os esforços de desenvolvimento através do recurso à SCM. Neste artigo apresentamos sete atributos que um bom sistema de gestão de configurações de software deve disponibilizar:
Segurança. O principal propósito de um sistema de SCM é garantir a segurança dos activos de um projecto (por exemplo, modelos de desenho, código fonte, casos de teste, documentação, etc.), de modo a evitar a sua corrupção, estragos acidentais, acessos não autorizados, ou mesmo situações de desastre.
Para isto são necessárias duas coisas. Por um lado, o acesso às fontes. Ou seja, a visualização ou alteração dos activos dos projectos só poderão ser efectuadas pelas pessoas explicitamente autorizadas para esse efeito. Por outro lado, a fiabilidade da recuperação do trabalho nos casos em que um utilizador autorizado comete algum erro (por exemplo, eliminação acidental).
Muitas vezes subestima-se o valor de negócio das funcionalidades de segurança da SCM. No entanto, as funcionalidades de segurança são a base para áreas chave da mitigação do risco a nível do processo de desenvolvimento de software. Se o trabalho não estiver seguro contra perdas deliberadas ou acidentais, estará sempre presente um nível de risco inaceitável relativamente aos activos de um projecto. A perda de trabalho poderá, no mínimo, atrasar um projecto e, no máximo, inviabilizar definitivamente o projecto.
Estabilidade. É indispensável um ambiente de desenvolvimento estável, tanto para a equipa, como para os especialistas em desenvolvimento individualmente. Uma verdadeira estabilidade tem dois elementos essenciais. Um deles é a garantia de áreas de trabalho estáveis. Alguns sistemas de SCM podem destabilizar as áreas de trabalho individuais quando outros procedem ao check in de novo código. Os especialistas em desenvolvimento precisam de saber que os dados nos seus desktops não foram alterados sem o seu consentimento durante a sua ausência.
O segundo elemento essencial é o controlo individual sobre o quando e o quê sempre que é introduzido novo código numa área de trabalho. Por exemplo, um especialista em desenvolvimento que trabalhou sozinho durante algum tempo, deverá ter controlo suficiente sobre o seu ambiente para decidir quando está pronto para introduzir novo código (e potencial instabilidade) no seu ambiente e no ambiente da equipa.
Por outro lado, os especialistas em desenvolvimento deverão poder actualizar o seu ambiente gradualmente, de modo a poderem avaliar os níveis de estabilidade. O nível de controlo que permite escolher o quando e o que é introduzido nos espaços de trabalho individuais reduz significativamente o risco dos projectos.
Controlo. Um dos principais papéis de qualquer sistema de SCM consiste em ajudar a gerir as alterações ao longo do ciclo de vida do desenvolvimento. O sistema terá assim que procurar uma situação de equilíbrio. Por um lado, garantir os controlos apropriados ao longo de todo o fluxo de trabalho de um projecto. Por outro, não impor limitações inconvenientes aos membros das equipas.
Actualmente, é comum os especialistas em desenvolvimento trabalharem em diferentes escritórios, países, ou mesmo fusos horários. Consequentemente, para integrar as contribuições de várias equipas de desenvolvimento é necessário um sistema que possa controlar quem está a trabalhar num pedido de alteração, a forma como as alterações passam do desenvolvimento para a integração, ou quem pode trabalhar num determinado fluxo de desenvolvimento.
Uma solução de SCM precisa de ser suficientemente flexível para permitir que toda uma equipa trabalhe numa ramificação comum de código, ou que os membros individuais de uma equipa trabalhem em ramificações "privadas". Actualmente, a reutilização de software é importante para a redução de custos. Como tal, é necessário poder dispor de uma abordagem de tipo "cadeia alimentar" relativamente ao desenvolvimento. Em termos práticos esta abordagem consiste numa equipa a produzir entregáveis (deliverables) destinados a serem "consumidos" por outra equipa do projecto. Esses componentes devem ser modificáveis apenas pela equipa que os produz.
Auditabilidade. O desenvolvimento de software é um processo iterativo e complexo que requer um grande esforço para compreender tudo aquilo que está a acontecer. A auditabilidade (auditability) refere-se à capacidade de responder às questões de tipo quem, o quê, quando e onde relativamente a uma versão ou configuração específica de software em qualquer altura. Também é necessário ser-se capaz de destacar as diferenças entre releases.
É necessário poder responder em qualquer altura a questões como: o componente x foi modificado de acordo com os requisitos mais recentes? Quem efectuou a alteração da linha 10249 da versão 3.2.4? Foram resolvidos todos os bugs prioritários para a versão patch e quem verificou essa resolução? A resposta a estas questões é crítica para resolver da melhor forma ocorrências familiares, como erros. Contudo, se for necessário encontrar a informação manualmente, haverá um grande consumo desnecessário de tempo.
Reprodutibilidade. Entre as várias alterações efectuadas ao longo de um projecto, nem todas correm da melhor forma. Por vezes, as versões anteriores são melhores do que as mais recentes. Como tal, é necessário ser-se capaz de reproduzir rapidamente a configuração anterior para voltar a colocar o projecto nos carris. A reprodutibilidade (reproducibility) é como uma fotografia aérea - representa uma visão do projecto que é global, detalhada e relativa a um determinado momento particular.
No contexto do desenvolvimento de software, a reprodutibilidade requer dois tipos de capacidade. Por um lado, a capacidade para reproduzir a configuração de todo o ambiente de desenvolvimento, incluindo ferramentas, testes e documentação em qualquer ponto do ciclo de vida do projecto. Por outro lado, a capacidade de recriar automaticamente, não só os ficheiros utilizados num build, mas também a estrutura de directório e todo o espaço de nomes.
É frequente acontecer a reorganização da estrutura do directório de uma release anterior - mudam os nomes dos ficheiros ou das subdirectorias, as grandes directorias são subdivididas noutras mais pequenas e os ficheiros são mudados de um lado para outro. A capacidade de recriar a estrutura de directório de uma release anterior é designada por "name space versioning" e os sistemas de SCM precisam de disponibilizar mecanismos que possibilitem esta prática.
Traceabilidade. Uma definição cabal de traceability envolve dois tipos de capacidades. Por um lado, a capacidade de identificar a versão de um produto implementado (nas instalações de um cliente), de modo a permitir que o sistema de SCM recrie facilmente o ambiente de desenvolvimento (código, documentação, casos de uso, etc.) necessário para reconstruir, testar e/ou correr essa mesma versão.
Por outro lado, a capacidade de voltar atrás numa versão de software específica relativamente aos pedidos de alterações e/ou requisitos que foram implementados, a fim de compreender essa versão. As funcionalidades de traceability permitem que os engenheiros de suporte disponham de toda a informação que precisam para recriar a configuração exacta de qualquer sistema e para responderem a questões do tipo: porque razão o software funciona desta forma?
Escalabilidade. Uma vez que representa a base de toda a plataforma de desenvolvimento, o sistema de SCM tem que suportar projectos de qualquer abrangência. Ou seja, tem que ser suficientemente escalável para suportar grandes equipas desde o início ao fim do projecto. Ao mesmo tempo, também não pode representar um fardo para as pequenas equipas. Um sistema de SCM escalável deverá responder a três tipos de requisitos.
Em primeiro lugar, ser configurável e funcional quando são necessários poucos controlos. Caso contrário, os membros das equipas terão que gastar tempo desnecessário com um processo de SCM globalmente complexo e sem tirarem qualquer benefício desse esforço. Além disso, os pequenos projectos não têm capacidade para suportar uma administração complexa.
Em segundo lugar, um sistema de SCM escalável deverá ser versátil para gerir o crescimento. Esta versatilidade é importante quando os pequenos projectos são bem sucedidos, uma vez que costumam dar origem a projectos de maior dimensão que já requerem funcionalidades mais avançadas (como o desenvolvimento paralelo, por exemplo).
Em terceiro lugar, um sistema de SCM escalável deverá ser capaz de suportar equipas geograficamente dispersas, telecommuters e/ou membros a trabalharem em outsourcing. A presença de pessoas que não trabalham nas mesmas instalações impõe grandes exigências ao ambiente de SCM, devido à necessidade de coordenar e gerir a colaboração distribuída (de forma central ou através de replicação).
A escalabilidade também implica a necessidade de se atingirem níveis razoáveis de desempenho. O aumento de solicitação de um sistema de SCM não poderá comprometer a fiabilidade do mesmo ou impedir o seu funcionamento básico.
Baseado no artigo "Better Software Configuration Management Means Better Business: The Seven Keys to Improving Business Value", de Tom Milligan - IBM Rational.
Produzido em 2005