software configuration management problemas e soluções

Software Configuration Management

Problemas e Soluções

Ryan Leite Albuquerque

de 39 SCM

ROTEIROROTEIRO1. 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;

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;

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.

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!

de 39 SCM


• 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);

de 39 SCM


• 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;

de 39 SCM


• 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;

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, ...;

de 39 SCM


• 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;

de 39 SCM


• 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;

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!

de 39 SCM


• 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;

de 39 SCM


• 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...

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;

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;

de 39 SCM


• 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?

de 39 SCM



As alterações não podem ser

incluídas ao mesmo tempo.

de 39 SCM



As alterações precisam ser

incluídas ao mesmo tempo.

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;

de 39 SCM


• 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;

de 39 SCM


• 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

de 39 SCM


• 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?

de 39 SCM


• 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);

de 39 SCM


• 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);

de 39 SCM


• 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;

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;

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);

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;

de 39 SCM



Sem controle de versão

Controle CVS like Controle SVN like

de 39 SCM



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;

de 39 SCM


• Controle de Versão (outras opções)

– Open source:

• GIT, Mercurial, Arch, Monotone, ...

– Comerciais:

• Rational Clearcase;

• IBM Starteam;

• Visual Source Safe;

• Perforce;

• ...

de 39 SCM


• 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;

de 39 SCM


• Controle de

Mudanças

de 39 SCM


• 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;

de 39 SCM


• 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;

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;


[ [email protected] ]

81 8727.4111


[ [email protected] ]

81 8727.4111

software configuration management problemas e soluções

Technology