O Fluxo de Gerência de
Configuração e Mudança
© Alexandre Vasconcelos
[email protected]
[email protected]
Centro de Informática da UFPE/
Qualiti Software Processes
1/33
Objetivo

Compreender a importância do uso de
mecanismos de gerência de configuração e de
mudança, seus métodos, processos e
ferramentas.
2/33
Tópicos






Introdução
A necessidade de controle do código fonte
Controle do código fonte
Builds
Controle de defeitos
Gerência de mudança
3/33
Introdução

SEI CMM/CMMI:


Gerência de Configuração (CM) e de Solicitações de
Mudança (CRM) controlam as mudanças e mantêm a
integridade dos artefatos de um projeto.
CM e CRM envolvem:
identificar itens de configuração
 restringir as modificações nesses itens
 auditar modificações nesses itens (porque, quando e por
quem um artefato foi modificado)
 definir e administrar configurações desses itens, ao longo
do processo de desenvolvimento.

4/33
Introdução


Parte essencial do processo de
desenvolvimento.
Visa eliminar problemas de
 atualizações
simultâneas
 existência de múltiplas versões do sistema
(produção, desenvolvimento, teste etc.)
5/33
Introdução

Ao longo do ciclo de vida de um software, seus
artefatos sofrem diversas alterações, causadas por
correção de defeitos no produto
 melhorias de funcionalidades do produto


Estas alterações afetam todos os tipos de artefatos:
documentos de requisitos
 documentos de análise e projeto
 código fonte
 programas e scripts de testes

6/33
Introdução


Vamos nos referir nesta aula ao código fonte,
que é o artefato em que é mais modificado.
Mas a gerência de configuração pode e deve
ser usada para todos os artefatos, dependendo
do tamanho e complexidade do projeto.
7/33
A necessidade de controle do
código fonte

Software desenvolvido por uma equipe
 Programas
precisam ser acessados e alterados
por várias pessoas da equipe.
 Modularização do projeto normalmente não é
suficiente para resolver este problema.
 Como controlar o acesso aos programas?
 Como saber qual a versão mais atualizada dos
arquivos?
 Como voltar para uma versão anterior do
programa?
8/33
Check-in

Ação de inserir/atualizar o conteúdo de um
arquivo no sistema de controle de código fonte.
 verifica
permissão de acesso ao arquivo
 verifica e incrementa identificador de versão do
arquivo
 guarda data, hora e autor da alteração

Informações são guardadas no próprio arquivo
ou junto com ele.
Desenvolvedor
Repositório
9/33
Check-out


Ação de ler/copiar a (última) versão de um
arquivo guardada no sistema
Tipos de checkout
 somente
para leitura (read-only)
 para edição (read/write)
Desenvolvedor
Repositório
10/33
Locking


Sistemas de controle de versão e configuração
usam um mecanismo de locking para evitar
que mudanças acidentais ou intencionais
ocorram em momentos inapropriados.
Evita alterações simultâneas
 permite
check-out, mas somente para leitura.
prog1.c
Desenvolvedor
prog2.c
prog3.c
Repositório
11/33
Tagging


Permite “marcar” um conjunto de arquivos com
um nome (tag).
Um tag representa um ou mais arquivos em um
ou mais diretórios.
 Ex:
Tagging de versão de projeto: controla uma
dada versão do projeto, em determinada data
ou com determinada funcionalidade.
12/33
Branching


Uso de locks limita o trabalho dos
programadores.
Estratégias de branching são regras que
definem como ocorrerão atividades de
mudança em paralelo no código fonte.
 Sem
uma estratégia bem definida, pode-se
esperar pelo caos.
13/33
Branching

Em um sistema sem branches, um arquivo
começa com sua versão 1, e a cada check-in
sua versão é incrementada.
 Se
a versão mais recente é 5, você não pode
fazer checkout para editar a versão 2, por
exemplo.
14/33
Branching

Branching tenta reduzir estas limitações,
permitindo a criação de caminhos separados
(linhas) de desenvolvimento para um mesmo
arquivo ou conjunto de arquivos.
 Cada
branch tem o seu conjunto de alterações e
versões.
 Um branch guarda ligação com seu nó (versão
do “ramo” principal) de origem.
 Extremamente poderoso, e perigoso!
15/33
Branching
file.c
1
2
3
4
2.1
2.2
16/33
Merging

Merging é o processo de combinar múltiplas
versões de um arquivo para criar uma nova
versão.
o
desafio é garantir que a funcionalidade do
código antes do merge seja preservada após o
merge.
17/33
Merging

Situações a serem tratadas:
 funcionalidades
diferentes, sem conflito.
 funcionalidades em conflito, que não podem ser
combinadas.
 Neste
caso, os desenvolvedores têm que entrar
em acordo.
18/33
Política de gerência de
configuração

Deve haver uma política clara sobre:
 convenção
de formato de nomes, extensões.
 responsabilidade por mudanças.
 documentação de mudanças (ex: comentários).
 criação e nomes de diretórios.
19/33
Builds


“Build” é um termo usado para identificar as
atividades associadas com o processamento
dos fontes para gerar um executável.
Ações
 verificar
dependências
 compilar
 linkar
 gerar outros arquivos (se necessário)
20/33
Controle de Defeitos


“Bug tracking”
composto de
 relato
 análise
 atualização
de status
21/33
Gerência de Mudança



Define o mecanismo de aprovação de
mudanças no sistema.
Normalmente não é implementado
completamente até o primeiro release (ou
próximo dele).
Pode ser mais ou menos formal, dependendo
do tamanho do projeto.
22/33
Grupo de Controle de Mudança

Avalia:
o
impacto na funcionalidade do produto.
 validade técnica da mudança
 consistência,


uniformidade
Aprova, rejeita, ou põe em espera
Segue um Cronograma
23/33
Componentes de um pedido de
mudança








Descrição da mudança
Alternativas
Complexidade
Cronograma
Impacto
Custo
Relação com outras mudanças
Testes
24/33
RUP - Conceitos

Baseline
snapshot dos artefatos do modelo de implementação, a
partir do qual trabalhos futuros serão desenvolvidos.
 ponto estável dos artefatos (para criação de branches
etc.)
 artefatos devidamente marcados (tag)
 ponto para possível rollback
 ponto para reproduzir bugs
 produzido ao fim de cada fase (major milestone), ou ao
final das iterações (minor milestones)

25/33
RUP - Conceitos

Método de promoção
 como
migrar artefatos do workspace individual
para o workspace global (integração de
(sub)sistemas, build, teste, release).
26/33
O Fluxo Gerência de Configuração do RUP
Gerente de
Configuração
e Ambiente
Definir
ferramentas e
equipamentos
Estruturar
ambiente
Planejar
gerência de
configuração
Implantar e
administrar
ambiente
27/33
Atividade: Definir Ferramentas e
Equipamentos

Objetivos
 Definir
ferramentas de suporte ao
desenvolvimento, controle de versões e
softwares em geral
 Definir hardwares e suas configurações
 Definir regras para atualizações de hardware e
software
28/33
Atividade: Estruturar Ambiente

Objetivos
 Determinar
a estrutura de diretórios que será
adotada para o projeto
 Definir os diferentes ambientes
(desenvolvimento, integração, testes, produção)
 Definir a política de uso do ambiente
29/33
Atividade: Planejar Gerência de
Configuração

Objetivos
 Definir
os papéis e responsabilidades dos
membros da equipe responsável pelas
atividades de gerência de configuração (GC)
 Definir os baselines que deverão ser
estabelecidos
 Definir o cronograma das atividades de GC
 Definir as políticas, procedimentos e padrões
que guiarão essas atividades
 Identificar os itens de configuração
30/33
Atividade: Implantar e Administrar
Ambiente

Objetivos
 Implantar
o ambiente com base na estrutura
definida na atividade anterior
 Gerenciar a utilização do ambiente de acordo
com as normas propostas
 Avaliar e revisar o ambiente
31/33
Referências



Descrição do workflow de gerência de
configuração e mudanças do RUP
Configuration Management Today http://cmtoday.com
Software Release Methodology, M.E.Bays,
Prentice Hall, 1999.
32/33
O Fluxo de Gerência de
Configuração e Mudança
© Alexandre Vasconcelos
[email protected]
[email protected]
Centro de Informática da UFPE/
Qualiti Software Processes
33/33