O que é e qual é a importância?
O software precisa sempre estar em constante mudança, como é defendido pela lei de Lehman da Mudança Contínua. Considerando uma segunda lei de Lehman, a Lei da Complexidade Crescente, existe uma tendência de toda essa mudança acrescentar complexidade ao software ao ponto de gerar um decaimento da qualidade, observada na Lei da Qualidade em Declínio também de Lehman.
Roger Pressman diz que essas mudanças se tornam ainda mais intensas à medida que o tempo de desenvolvimento do software passa e todas as partes envolvidas, consequentemente, começam a saber mais sobre o que precisam, qual será a melhor abordagem e outros aspectos. Para o autor, conforme o conhecimento vai aumentando, os clientes passam a querer modificar requisitos, desenvolvedores buscam modificar a abordagem técnica e os gerentes querem modificar a abordagem do projeto.
Essas inevitáveis mudanças precisam de acompanhamento, pois podem gerar declínio não só na qualidade do código fonte, mas também na qualidade do trabalho da equipe de desenvolvimento. Roger Pressman defende que as mudanças precisam ter análise e registro antes de serem implementadas. O autor entende que o controle dessas mudanças serve para melhorar a qualidade e reduzir os erros do processo de desenvolvimento e do software em si.
Nenhum tipo de controle deve ter como objetivo impedir a mudança para que o software não se torne obsoleto ou inútil, como é previsto pela Lei da Mudança Contínua de Lehman. O objetivo deve ser minimizar a confusão que pode ser gerada pelas mudanças frequentes, controlar a complexidade crescente com identificação, organização e registro das mudanças. A atividade com esse objetivo é dado o nome de Gerenciamento de Configurações.
Gerenciamento de Configurações, ou Software Configuration Management (SCM), é também chamado de Gestão de Alterações segundo alguns autores e é parte da Gestão da Qualidade, atuando tanto no software em si quanto no processo de desenvolvimento. Essa atividade é de tamanha importância que Roger Pressman diz que “se você não controlar as alterações, elas controlarão você”, pois o caos é o destino daqueles que não realizam o Gerenciamento de Configurações.
Talvez o termo configurações cause uma certa confusão para compreender de imediato o que é de fato gerenciado. Entende-se que as configurações gerenciadas são elementos em formato eletrônico que compõem o software. Dentre esses itens, podemos citar de imediato os arquivos do código fonte. Porém, um software não é composto somente de código fonte, mas também de documentos eletrônicos diversos que especificam o software, definem o plano de projeto do software, protótipos de telas, manuais operacionais, descrição do banco de dados, padrões e procedimento de processo, além de bibliotecas e componentes de terceiros utilizados.
Roger Pressman organiza os tipos de configurações em três categorias. A primeira categoria são os códigos fontes e executáveis do software. A segunda categoria de configurações apresentada pelo autor são os produtos que descrevem os programas de computador. Por fim, a terceira categoria de configurações são os dados e conteúdos contidos no software. Essas três categorias são capazes de resumir todos os artefatos que compõem o software, incluindo possíveis artefatos futuros a serem inventados para novos tipos de modelo de processo de desenvolvimento de software.
Ian Sommerville afirma que o Gerenciamento de Configurações é útil até mesmo em projetos individuais, devido a facilidade dos desenvolvedores, mesmo os que trabalham sozinhos, esquecerem quais mudanças foram feitas. Talvez, em tempos onde os controles de versão são amplamente utilizados em empresas, essa dificuldade possa não ser compreendida. Mas deve-se destacar que os controles de versão aplicam o gerenciamento de configurações e é justamente por existirem que essa dificuldade de controle de mudanças parece não ser mais vivenciada.
Descansando nos Controles de Versão
Faça um esforço de imaginar um mundo sem controles de versão como o git para entender a importância do Gerenciamento de Configurações. Depois de um ano desenvolvendo um software para uso pessoal, como você lembraria de todas as modificações feitas? Talvez você se lembre de quais funcionalidades foram criadas observando o todo, mas seria capaz de indicar quando cada uma foi implementada e quais modificações no código fonte foram necessárias para que funcionassem? Seria possível gerar um instalador de uma versão antiga?
Por isso, os controles de versão são ferramentas vitais nas atividades de Gerenciamento de Configurações! Seja você um desenvolvedor amador ou profissional, provavelmente já ouviu falar de controle de versão e deve saber outros nomes desses sistemas além do git. Se essas perguntas são difíceis de serem respondidas em um projeto individual, imagine para projetos de grande porte com equipes distribuídas em diferentes locais do mundo, com versões sendo lançadas quinzenalmente, podendo até mesmo clientes estarem usando versões diferentes uns dos outros.
Mas os controles de versão sozinhos são suficientes para atender todos os pontos abordados pelo Gerenciamento de Configurações? É muito comum empresas que entendem que um controle de versão é totalmente capaz de aplicar toda a compreensão de Gerenciamento de Configurações pelo fato de ser suficiente para gerenciar as mudanças, históricos, versões e outros aspectos do código fonte. Porém, o git é apenas uma ferramenta e o código fonte não é a única configuração que existe!
Git não é uma cultura ou processo, por isso, muitas dessas empresas trazem uma cultura caótica para dentro de uma ferramenta de controle acreditando estarem aplicando o Gerenciamento de Configurações. Essas empresas não mudam por passarem a aplicar o git, mas continuam sendo as mesmas, trabalhando do mesmo modo sem Gerenciamento de Configurações, mas usando o git. Ou seja, trocam o garçom, mas continuam pedindo as mesmas coisas.
Ian Sommerville afirma que existem quatro atividades relacionadas ao Gerenciamento de Configurações. As atividades complementam entre si para compor todo o objetivo defendido pelo Gerenciamento de Configurações. A primeira atividade apresentada pelo autor é o Gerenciamento de Mudanças, que é o acompanhamento de solicitações dos clientes e desenvolvedores por mudanças no software. Esse acompanhamento envolve definir os custos, identificar o impacto e até mesmo concluir se a mudança deve ser feita e, caso seja feita, quando acontecerá.
A segunda atividade é a de Gerenciamento de Versões, que é o acompanhamento de várias versões de componentes, além de assegurar que as mudanças realizadas por um desenvolvedor não interfira nas mudanças aplicadas por outro desenvolvedor. Quando se pensar nesses componentes como tijolos de uma casa que vem a ser o software, é preciso lembrar do momento em que esses componentes são organizados e ligados para gerar um software executável. Essa atividade de montagem dos componentes, dados e bibliotecas é a terceira atividade chamada de Construção do Sistema. É nessa atividade que é controlado quais componentes, cada um em uma versão específica, são ligados para gerar uma nova versão do software.
Por fim, a quarta atividade é a conclusão das demais e se chama Gerenciamento de Releases. Se as solicitações foram controladas e durante a implementação foram identificadas e registradas tanto as versões dos componentes quanto a versão do software como um todo, resta gerenciar a release da versão. Esse gerenciamento envolve tanto o preparo do software para ter sua versão disponibilizada quanto o acompanhamento e registro das versões que já liberadas para o uso do cliente.
São vários tópicos a serem observados no processo, várias culturas a serem incluídas e não se resume a uma ferramenta de controle de versão. Reflita quantas empresas utilizam o git e estão confortáveis com o fato de gerenciarem históricos e versões, mas não versionam cada configuração separadamente, não possuem processo de construção da versão do software a partir da versão de cada componente e nem mesmo possuem processo adequado para solicitação de mudanças. Existem muitas outras práticas, tradicionais e modernas, e culturas que são diariamente negligenciadas pelas empresas que se acomodam com o fato de terem o git.
Tássio Auad 