Antes de qualquer definição, vale parar nessa cena e listar o que deu errado. Não é uma coisa só — são quatro ou cinco problemas diferentes acontecendo juntos, e cada um tem nome técnico.

A disciplina inteira cabe nessa história. No último encontro do semestre, vale voltar a ela: a essa altura, você vai conseguir nomear cada peça e dizer o que teria evitado.

A reação comum é achar que gerência de configuração é coisa de empresa com centenas de desenvolvedores. Dois cenários mostram que não.

O primeiro caso é o mais importante dos dois, porque contraria a intuição. Você não precisa de outra pessoa para perder o controle do que fez. Basta o tempo passar.

Ao desenvolver software, mudanças são inevitáveis — e é por isso que a disciplina existe. A gestão de configuração de software (SCM, de Software Configuration Management) é o conjunto de atividades destinadas a gerenciar essas mudanças.

Ela envolve cinco coisas:

Como saber que está sendo feito direito

Três critérios objetivos:

1. Cada artefato pode ser identificado, rastreado e controlado.
2. Toda alteração pode ser rastreada e analisada.
3. Todos os que precisam saber de uma mudança foram informados.

Qualquer elemento associado a um projeto de software que tenha sido colocado sob controle de configuração é um item de configuração — SCI, de software configuration item. Frequentemente há várias versões do mesmo item, cada uma com identificação própria.

A parte difícil é decidir

Saber a lista é fácil. O que rende discussão é o que entra e o que fica de fora num projeto concreto — e errar para mais é tão ruim quanto errar para menos. Colocar coisa demais sob controle produz burocracia que ninguém segue.

Um critério que costuma resolver:

A pasta de dependências baixadas não entra — ela se reconstrói a partir do arquivo que lista as dependências, e esse, sim, entra. A senha do servidor não entra; o arquivo de exemplo que documenta quais variáveis de ambiente existem, entra.

Uma baseline é uma configuração aprovada e congelada num ponto do tempo, que passa a servir de referência. Antes dela, o artefato muda livremente. Depois, muda por processo formal.

A analogia que ajuda: a baseline é a foto oficial. Você só consegue discutir o que mudou porque existe a foto. Sem ela, “o sistema mudou” é uma frase sem conteúdo — mudou em relação a quê?

Este é o conceito que menos gente entende de primeira e o que mais aparece em prova. Vale voltar a ele quando falarmos de tags, no Encontro 3.

Sommerville organiza a gerência de configuração em quatro atividades relacionadas. As quatro são apresentadas hoje, e cada uma volta mais adiante com nome de ferramenta: o que aqui é conceito, no laboratório é comando.

A mesma coisa, dita de outro jeito

Pressman descreve a gerência de configuração em quatro passos, e à primeira vista parece outra teoria:

1. Identificar a alteração
2. Controlar a alteração
3. Assegurar que ela esteja sendo implementada corretamente
4. Relatar as alterações aos demais interessados

Não é. As duas descrevem o mesmo processo com recortes diferentes: as atividades de Sommerville dizem o que a equipe faz — são operacionais, distribuídas ao longo do projeto. Os passos de Pressman descrevem o ciclo de uma alteração, do pedido ao aviso. Uma é o mapa; a outra é o percurso.

Toda mudança em um sistema em produção percorre um caminho. Quando esse caminho não está definido, ele acontece assim mesmo, só que de forma improvisada: alguém pede no corredor, outro alguém implementa no fim da tarde, e ninguém registra por quê.

O material da disciplina descreve o percurso em seis etapas.

Quem forma o CCB numa equipe de cinco pessoas?

O CCB, ou Change Control Board, é a instância que aprova a mudança. Em uma fábrica de software com trezentas pessoas, é um comitê que se reúne. Na sua equipe de estágio, é o desenvolvedor mais experiente decidindo em cinco minutos se vale a pena mexer naquilo antes da entrega.

Reconhecer que o papel existe mesmo sem comitê formal é metade do aprendizado desta atividade. A outra metade é perceber que, quando ninguém ocupa o papel, quem decide o que entra no sistema é quem tem mais pressa.

Esta é a atividade que a turma já conhece de vista, porque é a que tem ferramenta popular. O risco é justamente esse: aprender os comandos e pular o critério.

Versionamento semântico

A pergunta prática de toda equipe é qual número escrever na próxima versão. O padrão que o mercado adota responde isso com três campos:

Repare que o número não mede esforço. Uma correção de uma linha que quebra a compatibilidade sobe o MAJOR; três meses de trabalho compatível sobem o MINOR. O que o número comunica é o risco de atualizar, e é por isso que quem consome a sua biblioteca lê essa informação antes de instalar.

Construir um sistema não é apenas compilar. É reunir componentes, bibliotecas, dados e configuração e produzir algo que executa, de forma que outra pessoa consiga repetir o processo e obter exatamente o mesmo resultado.

Os três ambientes

Duas consequências práticas. A primeira: o build parte da baseline, do que está registrado e aprovado, nunca do diretório de trabalho de um desenvolvedor. A segunda: se construir exige uma sequência de passos manuais que só uma pessoa conhece, a atividade não está sob controle. Automatizar é um comando, recompilação mínima e testes junto.

Como saber se um componente mudou

Duas assinaturas são usadas para isso. O timestamp registra quando o arquivo foi gravado; o checksum resume o conteúdo em um valor calculado a partir dele.

O segundo é mais confiável, e o caso que mostra a diferença é banal: abrir o arquivo, salvar sem alterar nada. O timestamp muda, o checksum não. Quem confia no relógio reconstrói o que não precisava.

Uma frase resolve a confusão mais comum desta parte da disciplina: nem toda versão construída é liberada. Uma equipe ativa constrói o sistema várias vezes por dia. Libera talvez uma vez por mês.

Release é a versão que atravessa a fronteira da equipe e chega a quem usa. Por isso ela carrega compromissos que a construção não tem.

• O pacote em si, construído a partir de uma baseline identificada.
• A documentação atualizada para a versão que está saindo, e não para a anterior.
• A comunicação da mudança: o que entrou, o que saiu e o que exige atenção de quem atualiza.
• O registro de qual versão foi entregue a qual cliente, que é o que permite suporte.

Changelog

O changelog é a comunicação da mudança em forma de arquivo. Ele não é o histórico de commits despejado num texto: aquele registro é para a equipe, escrito na linguagem de quem alterou o código. O changelog é para quem usa o sistema, e responde a uma pergunta diferente: o que mudou para mim, e preciso fazer alguma coisa por causa disso?

As quatro atividades produzem registros. Auditar é conferir se esses registros correspondem à realidade.

Modelos de melhoria de processo como o CMMI e o MPS.BR tratam gerência de configuração como área de processo obrigatória. Não é formalidade: em domínios certificados, como dispositivo médico e aviônica, é preciso demonstrar que cada requisito foi rastreado até a versão que o implementa e o teste que o verifica. Sem gerência de configuração, essa demonstração é impossível.

Um cenário concreto, para fechar: um produto de cerca de 15 mil linhas, seis engenheiros de software, várias tarefas com prazo. Quatro papéis envolvidos — e cada um enxerga a gerência de configuração de um jeito diferente.

A conclusão que importa: um sistema de gerência de configuração precisa atender aos quatro ao mesmo tempo. É por isso que a melhor ferramenta não é a que tem mais recursos — é a que serve a papéis diferentes sem atrapalhar nenhum deles.

São oito encontros, quinzenais, mais a prova final. Esta aula de hoje é a única expositiva do semestre: toda a teoria está aqui. Da próxima em diante, o encontro acontece no laboratório, com você digitando comando e entregando resultado antes de sair da sala.

O semestre inteiro

O repositório criado em 25/08 é o mesmo até dezembro. A cada encontro ele ganha uma camada: histórico, ramificações, colaboração, automação, container, stack completa. No fim do semestre você tem uma coisa só, inteira, que dá para mostrar em entrevista.

Avaliação

As quinze perguntas abaixo são o roteiro de estudo deste encontro. Elas não valem nota e não têm entrega: servem para você conferir sozinho se o vocabulário ficou, e são a melhor preparação para a P1, que cobra exatamente isto.

Responda por escrito, para você mesmo, em até cinco linhas cada. As perguntas 2, 5 e 9 pedem posicionamento e não têm resposta única — nelas o que importa é a consistência do argumento.

O conteúdo desta página é paráfrase das obras indicadas. A seção sobre baseline é síntese a partir da terminologia de Sommerville (cap. 25) — ao estudar, confira a redação da edição adotada.