CESAR

Prévia do material em texto

Software Configuration Management
Problemas e Soluções
Ryan Leite Albuquerque
slide 2 de 39 SCM
ROTEIROROTEIRO
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;
slide 3 de 39 SCM
O que é GC ?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;
slide 4 de 39 SCM
O que é GC ?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.
slide 5 de 39 SCM
Problemas ClássicosProblemas 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!
slide 6 de 39 SCM
Problemas ClássicosProblemas 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);
slide 7 de 39 SCM
Problemas ClássicosProblemas 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;
slide 8 de 39 SCM
Problemas ClássicosProblemas 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;
slide 9 de 39 SCM
Soluções ClássicasSoluçõ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, ...;
slide 10 de 39 SCM
Soluções ClássicasSoluçõ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;
slide 11 de 39 SCM
Soluções ClássicasSoluçõ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;
slide 12 de 39 SCM
Problemas não tão ClássicosProblemas 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!
slide 13 de 39 SCM
Problemas não tão ClássicosProblemas 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;
slide 14 de 39 SCM
Problemas não tão ClássicosProblemas 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...
slide 15 de 39 SCM
Problemas não tão ClássicosProblemas 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;
slide 16 de 39 SCM
Problemas não tão ClássicosProblemas 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;
slide 17 de 39 SCM
Problemas não tão ClássicosProblemas 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?
slide 18 de 39 SCM
Problemas não tão ClássicosProblemas não tão Clássicos
• Branches e Merges
As alterações não podem ser 
incluídas ao mesmo tempo.
slide 19 de 39 SCM
Problemas não tão ClássicosProblemas não tão Clássicos
• Branches e Merges
As alterações precisam ser 
incluídas ao mesmo tempo.
slide 20 de 39 SCM
Problemas não tão ClássicosProblemas 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;
slide 21 de 39 SCM
Problemas não tão ClássicosProblemas 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.Restamos 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;
slide 22 de 39 SCM
Problemas não tão ClássicosProblemas 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 Uso
Código
Casos de Teste
Mudanças Revisões
slide 23 de 39 SCM
Problemas não tão ClássicosProblemas 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?
slide 24 de 39 SCM
Problemas não tão ClássicosProblemas 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);
slide 25 de 39 SCM
Problemas não tão ClássicosProblemas 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);
slide 26 de 39 SCM
Problemas não tão ClássicosProblemas 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;
slide 27 de 39 SCM
ProcessosProcessos
• 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;
slide 28 de 39 SCM
ProcessosProcessos
• 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);
slide 29 de 39 SCM
FerramentasFerramentas
• 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;
slide 30 de 39 SCM
FerramentasFerramentas
• Controle de Versão
Sem controle de versão
Controle CVS like Controle SVN like
slide 31 de 39 SCM
FerramentasFerramentas
• Controle de Versão
slide 32 de 39 SCM
FerramentasFerramentas
• 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;
slide 33 de 39 SCM
FerramentasFerramentas
• Controle de Versão (outras opções)
– Open source:
• GIT, Mercurial, Arch, Monotone, ...
– Comerciais:
• Rational Clearcase;
• IBM Starteam;
• Visual Source Safe;
• Perforce;
• ...
slide 34 de 39 SCM
FerramentasFerramentas
• 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;
slide 35 de 39 SCM
FerramentasFerramentas
• Controle de 
Mudanças
slide 36 de 39 SCM
FerramentasFerramentas
• 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;
slide 37 de 39 SCM
FerramentasFerramentas
• 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;
slide 38 de 39 SCM
Outras Ferramentas RelacionadasOutras 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;
Ryan Leite Albuquerque
[ ryan@cesar.org.br ]
81 8727.4111
Ryan Leite Albuquerque
[ ryan@cesar.org.br ]
81 8727.4111