Laboratório de Desenvolvimento de Aplicações com Métodos Ágeis
Gestão de Configuração
Pós-Graduação
Engenharia de Software
Prof. Dr. Rogério Augusto Rondini [email protected]
2
Gestão de Configuração:
Configuração, Item de Configuração,
Base Line, Repositório
Configuração
●
A configuração de software é um
conjunto de itens produzidos durante
o ciclo de vida do projeto
– Programas
– Documentação – Dados
●
Em SCM, esses itens são
denominados Itens de
Configuração
4
Item de Configuração
●
Pode ser qualquer artefato produzido
durante o ciclo de vida do projeto
que precise ser gerenciado
●
Menor item de controle (executável,
documento, código-fonte, …)
●
Organizado p/ formar objetos de
configuração
●
No dia-a-dia, um item possui várias
Item de Configuração
●
Exemplos de itens de configuração
1 Especificação de Sistema 11 Plano e procedimento de testes 2 Plano do Projeto 12 Casos de testes e resultados 3 Especificação de Requisitos 13 Manuais de instalação
4 Protótipo 14 Manual de operação
5 Manual preliminar do usuário 15 Programa executável
6 Descrição do projeto de dados 16 Descrição do banco de dados 7 Descrição do projeto arquitetural 17 Manual do usuário
8 Descrição do projeto de Interfaces 18 Relatório de problemas de software 9 Descrição dos objetos 19 Solicitações de manutenções
10 Códigos-fontes 20 Pedidos de mudanças
OBS: Em algumas situações, até emails e atas de reuniões são colocadas sob controle...
6
Item de Configuração
Identificação Armazenamento V1 Controle de Mudança PRODUÇÃO
Identificação Armazenamento V1 Controle de Mudança PRODUÇÃO
Identificação Armazenamento V1 Controle de Mudança PRODUÇÃO
V2
Item de Configuração
●
Controle de mudança gera
requisições que irão afetar itens de
configuração, tipicamente uma
mudança de versão
●
Cada nova versão é diferente da
anterior. Isso faz com que seja
possível voltar facilmente à versão
anterior. Este é um dos pontos
mais fortes da GCS.
8
Metadados
●
Informações compartilhadas
relativas aos itens de configuração
– Ex: data criação, data entrada
produção, relacionamento com outros itens, etc..
●
Principalmente utilizados para
registrar e rastrear mudanças (o que
10
Identificação
●
Tarefa de atribuição de metadados a
itens de configuração
●
Ocorre em dois momentos
– Quando o item de configuração é
colocado sob controle
– Quando tem uma solicitação de
mudança que afetará o item de configuração
Identificação
●
Pontos importantes
– Identificação única → cada empresa
precisa definir suas próprias
convensões para identificação de itens de configuração
– Autorização → relacionada aos
processos da empresa, para definir
quem pode o quê em cada item de
configuração. Além disso, deve-se prever registros para garantir
12
Armazenamento
●
Tarefa para garantir que o item de
configuração possa ser encontrado a
qualquer momento
●
Deve permitir rastreamento do item,
ou seja, com quem teve, com quem
está, o que foi feito, qual versão, etc..
Armazenamento
●
Checkout
– Ato de copiar localmente um item
de configuração para modificação
– Adicionalmente, pode-se bloquear o
item para que outro usuário não faça checkout.
14
Armazenamento
●
Checkin
– Ato de atualizar o repositório coma
as alterações realizadas.
– Em algumas situações pode ser
necessário realizar um merge para combinar as alterações realizadas por diferentes usuários
Armazenamento
●
Tags
– Rótulos que são associados a
conjunto de itens de configuração
– Utilizadas para:
● Denominar projetos, rotulando
todos os itens de configuração associados
● Denominar uma versão específica
do projeto, rotulando todos os itens de configuração associados
16
Armazenamento
●
Branch
– Fluxo alternativo para atualização
de versões de itens de configuração
– Tipicamente utilizado quando se
tem diferentes versões de um
mesmo produto em produção ou em desenvolvimento
Armazenamento
●
Merge
– Unificação de diferentes versões de
um item de configuração
– Integração de um item de
configuração de um branch com o item de um fluxo principal
18
Armazenamento
●Branch/Merge
principal Cliente A Cliente B merge mergeArmazenamento
●
Dois conceitos importantes
– Controle de Versão → controle de
versão independente dos itens de configuração ao longo do seu ciclo de vida
– Baseline → Conjunto de itens de
configuração identificados e
liberados para uso independente de suas versões
20
Baseline
●
Utilizado para sincronizar um
produto ou algo a ser entregue ou
desenvolvido
●
Representa uma foto do estado da
última versão dos itens de
configuração
22
Baseline
●
Razões para criar baselines
– Reprodutibilidade → habilidade de
reproduzir versão anterior
– Rastreabilidade → relação entre
artefatos do projeto (ex. especificação e código)
– Documentação → por exemplo
release notes
– Organização → fácilidade para
Baseline
●Baselines importantes
– Funcional ● Requisitos – De Produto ● Versões ● Releases ● iterações24
Baseline
●Baselines importantes
Engenharia de Sistemas _____________________________ Especificação de Sistema Análise de Requisitos_____________________________ Especificação de Requisitos de Software Projeto de Software _____________________________ Especificação de Projeto Codificação Código-fonte ________________________ _________ Testes Planos de Testes ______________________________________ Pressman, 1995
Controle de Mudança
●
Controlar todo e qualquer pedido (ou
requisição) de mudança de um
produto e de mudanças já
implementadas
●
Identificar quem, quando, por que
e o que mudou em cada item de
configuração
26
Análise de Status
●
Atividade para disponibilizar
informações úteis para
gerenciamento ao longo do
desenvolvimento de um produto
– Por exemplo, métricas (conforme
visto no relacionamento entre SCM e Qualidade de Software)
Padrões
●
O que é um padrão ?
– Solução documentada para um
problema comum em um dado contexto
– Existem padrões para as mais
variadas áreas da engenharia de software, os quais podem ser
28
Padrões
●
Classificação baseada na tecnologia
– Padrões JEE (Core J2EE Patterns) – Padrões para XML (XML Patterns) – Padrões para banco de dados
– Padrões para interface de usuário – ...
Padrões
●
Classificação de acordo com a fase
de desenvolvimento
– Padrões de Análise (analisys
patterns)
– Padrões de Projeto (design
patterns)
● Gang of Four (GoF)
– Padrões de Arquitetura
30
Padrões
●
Classificação baseada em processos
de desenvolvimento e ambientes de
execução
– Padrões de Gestão de
Configuração (SCM Patterns)
– Padrões de Segurança (Security
SCM Patterns
●
Conjunto de padrões para gestão de
configuração de software
●
Descreve problemas comumumente
enfrentados no desenvolvimento de
software e aponta caminhos para
melhor estruturação do ambiente de
desenvolvimento para melhor uso
32
SCM Patterns
●
Classificados em dois grupos
– Workspace patterns
● Private workspace, repository,
private system build, integration build, third party codeline, task
level commit, smoke test, unit test e regression test
– Codeline patterns
● Mainline, Active Development Line,
Codeline Policy, Private Version,
Release Line, Task Branch, Release-Prep Code Line
34
Mainline
●
Objetivo
– Minimizar o merge e manter um
número gerenciável de linhas de desenvolvimento ativas
●
Solução
– Combinar frequentemente as linhas
de desenvolvimento à linha principal
Mainline
mainline 1.0 1.1 2.0 Branch 2.0 1.1 Branch 1.1 2.0 Branch 2.1 2.1 Merge36
Active Development Line
●
Objetivo
– Manter uma linha de
desenvolvimento rapidamente estável para que possa servir de base de novas linhas ativas
●
Alguns problemas
– Como saber se uma linha de
desenvolvimento está estável ?
– Como isolar o trabalho dos
Active Development Line
Mainline → linha de desenvolvimento estável
1.0 1.1 2.0 Branch 2.0 1.1 Branch 1.1 2.0 Branch 2.1 2.1 Merge
38
Codeline Policy
●
Objetivo
– Criar uma política de linhas de
desenvolvimento para auxiliar os desenvolvedores a decidir sobre momentos de realizar checkin,
Private Workspace
●
Objetivo
– Prevenir que mudanças afetem o
trabalho de outros desenvolvedores e vice-versa, mantendo uma área
de código para cada desenvolvedor
● Repositórios locais
●
Complementos
– Private System Build, Smoke Test,
40
Private System Build
●
Objetivo
– Verificar se suas alterações não
irão “quebrar“ a build, realizando uma integração privada da
aplicação antes de efetivar suas
alterações
– Deve incluir todas as dependências
Private System Build
●
Como saber se você não está
inserindo problemas ao seu código ?
42
Smoke Test
●
Objetivo
– Teste sobre as funcionalidades
básicas
– Procura defeitos básicos, por
exemplo, compilação...
Observação:
O termo teste rápido (smoke test) originou-se na indústria de hardware. Depois que um componente de hardware fosse alterado ou reparado, o equipamento era simplesmente ligado.Se não houvesse nenhuma fumaça (smoke), o componente passou no teste.
Unit Test
●
Objetivo
– Execução de teste unitário no
componente ou código alterado
– Testes unitários
● Devem ser automatizados ● Isolados de outros testes
● Testa o contrato do elemento ● Deve estar disponível p/ uso a
qualquer momento (e.g antes, durante e após alteração...
44
Regression Test
●
Objetivo
– Garantir que um código existente
não piore após a implementação de melhorias ou novas funcinalidades
– Executado p/ toda a build
● Smoke test não testa
exaustivamente
● Unit Test testam partes
Integration Build
●
Objetivo
– Garantir estabilidade da aplicação
através de integração periódica
– Pode ser realizada através da integração contínua
●
Como garantir que a build de
integração é estável
46
SCM Patterns
mainline
Active dev. line
Private workspace
Codeline Policy
Integration Build Private System Build
Smoke Test
SCM Patterns
●
Muitos já utilizam alguns desses
padrões sem o conhecimento de que
existe o conceito de SCM Patterns
●
