1. Software Configuration Management
Problemas e Soluções
Ryan Leite Albuquerque

2. ROTEIRO
1. O Que é Gerência de Configuração (GC);
2. Problemas Clássicos;
3. Soluções Clássicas;
4. Problemas não tão Clássicos;
5. Processos;
6. Ferramentas;
SCM
slide 2 de 39

3. O que é GC ?
• ES não é uma ciência exata;
• Não se sabe a priori:
– Quanto vai custar o software;
– Quando o desenvolvimento vai terminar;
– Qual o tamanho final do sistema;
• Problemas:
– Tecnologias demais;
– Gente demais (equipes grandes e/ou distribuídas);
– Domínios demais;
SCM
slide 3 de 39

4. O que é GC ?
On any team project, a certain degree of confusion is inevitable. The goal is
to minimize this confusion so that more work can get done. The art of
coordinating software development to minimize this particular type of
confusion is called configuration management.
Configuration management is the art of identifying, organizing, and
controlling modifications to the software being built by a programming
team. The goal is to maximize productivity by minimizing mistakes.
--
Wayne Babich
Software Configuration Management: Coordination for Team Productivity
Addison-Wesley, 1986.
SCM
slide 4 de 39

5. Problemas Clássicos
• Você já ouviu algo parecido?
– O erro q eu corrigi ontem apareceu de novo hj!
– O cliente recebeu a versão errada do sistema!
– Isso q vc está fazendo já foi feito por Fulano...
– Não estou vendo sua correção!
– O que foi introduzido desde a última entrega?
– Quem corrigiu o problema relatado pelo cliente na semana
passada?
– (Cliente) Mas não foi isso q pedi pra implementar!
SCM
slide 5 de 39

6. Problemas Clássicos
• Falha na Comunicação
– Qto mais gente, mas canais de comunicação e mais problemas:
• De interpretação;
• De expressão;
– Causas:
• Culturas diferentes (idiomas e costumes);
• Vocabulários incompatíveis (termos não adequados);
• Distância física (conversa via telefone é cruel);
• Conhecimento (background técnico);
• Personalidade (e.g. timidez, verborreia);
SCM
slide 6 de 39

7. Problemas Clássicos
• Dados Compartilhados
– Qdo parte do sistema é compartilhado e alterado
inadvertidamente
• Imagine desenvolver em equipe usando um drive de rede;
• Surgimento de efeitos colaterais;
– Solução é manter cópias locais para evitar conflitos
• Surgimento de várias versões do mesmo componente que
deveria ser único;
SCM
slide 7 de 39

8. Problemas Clássicos
• Manutenção Múltipla
– Para resolver o problema dos dados compartilhados, cria-se
uma biblioteca central de componentes;
• Uma cópia do componente é copiada localmente;
• As versões são copiadas de volta para a base central qdo
alteradas;
– Problema:
• Sobreposição de alterações;
• Duplicação de trabalho;
SCM
slide 8 de 39

9. Soluções Clássicas
• Falha na Comunicação
– Criação de padrões para uniformizar a linguagem;
• Streamed Lines;
– Software Configuration Management Patterns: Effective
Teamwork, Practical Integration by Steve Berczuk with Brad
Appleton.
– Mainline, Release line, Line policies, Branch per Task, ...
• Vocabulário específico: versão, branches, tags, merge, CR,
CCB, baseline, release, ...;
SCM
slide 9 de 39

10. Soluções Clássicas
• Dados Compartilhados
– Utilização de sistemas de controle de versão
• Ex. CVS, Subversion, Clearcase, Starteam, ...;
– Repositório central para o trabalho concorrente;
– Tagging
• Cada desenvolvedor trabalha num ponto em comum e
estável;
– Branching
• Trabalho pode ser realizado isoladamente e
concorrentemente;
SCM
slide 10 de 39

11. Soluções Clássicas
• Manutenção Múltipla
– Utilização de um sistema para controle de mudanças
• Ex. Bugzilla, Mantis, GNats, Jira, ...
• O gerenciamento das mudanças vai minimizar os problemas
de trabalho repetido e/ou perdido;
• Aumento da visibilidade das mudanças;
– Utilização de processos
• Definição dos padrões e procedimentos adequados aos
projetos;
SCM
slide 11 de 39

12. Problemas não tão Clássicos
• Lidar com o pre conceito (mitos)
-
– GC é uma atividade só do engenheiro de configuração;
– GC é uma atividade só de desenvolvedores;
– GC só serve para obter certificações (e.g. CMMI);
– As ferramentas de GC fazem todo o trabalho sujo;
– O desenvolvimento sempre sobrevive sem GC;
– Eu faço GC só com o CVS!
– Só preciso de GC para o código!
– Solução:
• Treinamentos!
SCM
slide 12 de 39

13. Problemas não tão Clássicos
• Linhas instáveis
– Tá! Eu tenho um CVS. E daí?
• Utilizar CVS só como software de backup não resolve os
problemas;
– Se nenhuma política de branches é definida, temos o risco de
ter linhas sempre instáveis
• Todo mundo commita no HEAD/Trunk;
• O desenvolvimento pode tornar-se frustrante em alguns
casos;
SCM
slide 13 de 39

14. Problemas não tão Clássicos
• Linhas instáveis (cont.)
– Soluções:
• Definir política de branches e seus acessos:
– Mainline;
– Branch per Developer;
– Branch per Task;
– Branch per Component;
– ...
• Se uma política de branches não for possível, usar
integração contínua...
SCM
slide 14 de 39

15. Problemas não tão Clássicos
• Integração Contínua
– Combinação de técnicas oriundas de XP para agilizar os
releases com a diminuição dos tempos de integração
• Código (latest) é recuperado, compilado e testado em
tempos regulares sem a intervenção humana;
• Dependendo do resultado da compilação, há uma
notificação para o time;
• Pode ocorrer o deploy no final do processo;
• ...e a linha torna-se estável mais rapidamente;
SCM
slide 15 de 39

16. Problemas não tão Clássicos
• Integração Contínua
– Premissas:
• Ter código em um repositório de versões;
• Ter o processo de build 100% automatizado e razoavelmente
rápido;
• Ter um processo de teste (pelo menos unitário)
automatizado;
• Commits diários e compiláveis;
SCM
slide 16 de 39

17. Problemas não tão Clássicos
• Branches e Merges
– O desenvolvimento com branches parece ser mais complicado
no entanto é o mais seguro;
• As mudanças ficam isoladas proporcionando o trabalho
concorrente e uma boa rastreabilidade;
– Quem controla um mainline pode não conhecer do código
• Caso do CESAR. Temos um engenheiro de configuração que
controla as mainlines;
• O merge de branches as vezes não é trivial;
• Como se precaver?
SCM
slide 17 de 39

18. Problemas não tão Clássicos
• Branches e Merges
As alterações não podem ser
incluídas ao mesmo tempo.
SCM
slide 18 de 39

19. Problemas não tão Clássicos
• Branches e Merges
As alterações precisam ser
incluídas ao mesmo tempo.
SCM
slide 19 de 39

20. Problemas não tão Clássicos
• Manutenção em Produção
– É muito comum ter que fazer
manutenção em sistemas que já foram
entregues enquanto uma nova versão
está sendo preparada;
– Fato: a correção não pode ser
realizada no mainline;
• Mas ela tem q voltar para o
mainline algum dia;
– Solução: usar branch por release;
SCM
slide 20 de 39

21. Problemas não tão Clássicos
• Rastreabilidade
– Manter rastreabilidade não é trivial;
– Não é pequena a quantidade de projetos q têm problemas com
rastreabilidade entre requisitos, código, testes e mudanças;
– Solução: utilizar suites de desenvolvimento com
funcionalidades integradas;
• No C.E.S.A.R estamos desenvolvendo a nossa;
– Sistema de controle de requisitos e use cases;
– Sistema de controle de revisões;
– Sistema de controle de casos de testes e execuções;
– Sistema de controle de mudanças;
SCM
slide 21 de 39

22. Problemas não tão Clássicos
• Rastreabilidade (cont.)
– Quais casos de testes cobrem cada requisito?
– Quais casos de testes vão ser impactados com minha mudança?
– Quais os use cases impactados com minha mudança?
Requisitos Casos de Teste
Casos de Uso
Código
Revisões
Mudanças
SCM
slide 22 de 39

23. Problemas não tão Clássicos
• Rastreabilidade entre Mudanças e Código
– Qdo um esquema simples de branches é escolhido, não se tem
muita noção do mapeamento entre as solicitações de mudança
e o código alterado
• Que solicitação de mudança ocasionou esse commit?
• Quais os artefatos alterados em virtude dessa solicitação de
mudança?
SCM
slide 23 de 39

24. Problemas não tão Clássicos
• Rastreabilidade entre Mudanças e Commits
(cont.)
– Solução: triggers no sistema de controle de versão;
• Antes de cada commit, o trigger solicita um comentário
informando o identificador da mudança;
• O commit é aceito ou não de acordo com a política
estabelecida (estado da CR, nomes dos arquivos, permissões
de usuários, ...);
• Se aceito, as informações do commit são postadas na
solicitação de mudança (geralmente uma aplicação web);
SCM
slide 24 de 39

25. Problemas não tão Clássicos
• Rastreabilidade entre Mudanças e Commits
(cont.)
– Ferramentas:
• SCMBug (CVS/Subversion Mantis/Bugzilla);
• Garfio (Subversion Mantis);
• CVSZilla (CVS Bugzilla);
• C.E.S.A.R CVSGuardian (CVS Mantis);
SCM
slide 25 de 39

26. Problemas não tão Clássicos
• Banco de Dados
– O controle de versões de uma base de dados não é tão trivial;
– Em algum ponto alguém terá que atualizar um banco em
produção sem destruir os dados;
– A idéia aqui é manter scripts de atualização da base, um para
cada versão do sistema. Os script deverão ser aplicados em
ordem para atualização do banco. Sugestões:
• Dbdeploy;
• DB Ghost;
SCM
slide 26 de 39

27. Processos
• Planejamento
– Identificação (ambientes, itens de configuração, baselines e
CCB);
– Padronização (nomes, ferramentas, estrutura de diretórios,
projetos e componentes);
• Controle
– Controle das mudanças (ação do CCB);
– Estabelecimento de marcos (baselines e releases);
– Versionamento;
SCM
slide 27 de 39

28. Processos
• Status Accounting
– Geração de relatórios (em geral automáticos);
• Logs de commits e meta-dados;
• Histórico de mudanças;
• Atuação do CCB (análise e decisões);
– Métricas (coleta e análise);
• Auditorias
– Verificações de integridade (física e funcional);
SCM
slide 28 de 39

29. Ferramentas
• Controle de Versão
– Sistema para gerenciar as versões de arquivos (e diretórios);
– Propicia:
• Controle do histórico;
– Metadados e conteúdo;
• Trabalho concorrente e isolado (branches);
– Ramificação e junção de trabalhos afins;
• Marcação e recuperação de versões (tags);
• Status accounting;
SCM
slide 29 de 39

30. Ferramentas
• Controle de Versão
Sem controle de versão
Controle SVN like
Controle CVS like
SCM
slide 30 de 39

31. Ferramentas
• Controle de Versão
SCM
slide 31 de 39

32. Ferramentas
• Controle de Versão (opções recomendadas)
– CVS x Subversion;
• Subversion corrige alguns problemas do CVS;
– Refactoring (renomeação de arquivos e diretórios);
– Meta-dados customizados (properties);
– Commits atômicos (revisão por repositório);
– Permissões de diretórios;
– Vários protocolos de authenticação:
» http(s) (webdav), file, svn, svn+ssh, ...
– Tag e branch com tempo constante (links);
– Diffs de arquivos binários;
SCM
slide 32 de 39

33. Ferramentas
• Controle de Versão (outras opções)
– Open source:
• GIT, Mercurial, Arch, Monotone, ...
– Comerciais:
• Rational Clearcase;
• IBM Starteam;
• Visual Source Safe;
• Perforce;
• ...
SCM
slide 33 de 39

34. Ferramentas
• Controle de Mudanças
– Sistema para registrar e gerenciar as mudanças aos softwares;
– Propicia:
• Acompanhamento dos estados de cada requisição;
• Controle de acesso;
• Histórico de alteração;
• Notificações por email do andamento das requisições;
• Status accounting;
SCM
slide 34 de 39

35. Ferramentas
• Controle de
Mudanças
SCM
slide 35 de 39

36. Ferramentas
• Controle de Mudanças (opções recomendadas)
– Bugzilla (perl) x Mantis (php)
• Embora o Bugzilla tenha evoluido bastante,
o Mantis ainda tem uma melhor usabilidade;
• Customização da máquina de estados;
• Internacionalização;
• Web services (facilitando a extensão);
• Controle de acesso por projeto (níveis de acesso);
• Relatórios de métricas;
SCM
slide 36 de 39

37. Ferramentas
• Controle de Mudanças (outras opções)
– Trac (python)
• Difícil instalação;
• Bug tracking, wiki, svn browser;
• Plugins (forum, blog, autenticação, relatórios, ...);
– Atlassian Jira (j2ee) (comercial)
• Mais completo e mais complexo;
• Excelente apresentação;
• Flexibilidade e extensibilidade;
• Free para projetos open-source;
SCM
slide 37 de 39

38. Outras Ferramentas Relacionadas
• Automatização de Builds
– GNU Make, Ant, Maven, Shell/Batch Script, ...
• Integração Contínua
– Cruise Control, Luntbuild, Anthill, Continuum, Mojo, ...
• Gerenciamento de Testes
– Testlink, Salomè, Test Director, TestManager, ...
• Gerenciamento de Requisitos
– RTH, Requisite Pro, Caliber, ...
• Revisão
– Code Striker;
SCM
slide 38 de 39

39. Ryan Leite Albuquerque
[ ryan@cesar.org.br ]
81 8727.4111