Gestão de Configurações II

(1)

(2)

Gestão de Projecto 14

Bibliografia

 

Livro: Software Configuration

Management Patterns: Effective

Teamwork, Practical Integration

(3)

Padrões de Gestão

 

Os padrões de gestão de

configurações são úteis pois:

  Consideram como as pessoas trabalham

para além dos mecanismos de como se constrói o código

  Envolvem processos de construção e os

artefactos resultantes

  Pequenas alterações na forma como se

faz a gestão de configurações pode melhorar em muito o processo

(4)

(5)

Padrões

  Sequência de código   Sequência principal   Sequência activa   Política da sequência   Versões privadas   Sequência da entrega   Sequência de preparação para entrega   Espaço de trabalho   Espaço de trabalho privado   Repositório   Construção privada do sistema   Construção de integração   Sequência de terceiros   Confirmação de nível tarefa   Teste de despistagem   Teste de unidade   Teste de regressão

(6)

Sequência Principal

  Denominada “Main Line” ou “HEAD”   Contexto

  Desenvolvimento de software por várias pessoas em

paralelo

  A ferramenta de controlo de versões suporta ramos e

(7)

Sequência Principal

 

Problema

  Como manter o número de sequências

de código activas em número pequeno de forma a facilitar a gestão, sem a

árvore de versões do projecto ficar demasiado larga e densa? Como se minimiza o esforço adicional de fazer integrações?

(8)

Sequência Principal

 

Criar ramos é um mecanismo para

isolarmos-nos de e/ou isolarmos

alterações

 

Integração pode ser difícil devido aos

conflitos de alterações podendo exigir

a presença de todos os intervenientes

 

A dificuldade de integração aumenta

(9)

Sequência Principal

 

Solução

  Simplificar o modelo de ramos

  Quando se está a desenvolver uma única

versão do produto deve-se trabalhar numa sequência principal

  Uma sequência principal é a sequência onde

é feito todo o desenvolvimento, excepto em circunstâncias especiais

  Quando se pretende criar um ramo deve-se

pensar na estratégia global antes de o criar

  Se houver dúvidas, escolher o modelo mais

(10)

Sequência Principal

  A sequência principal funciona como

a base de ramos e integrações resultantes – evitar modelos em escada

  O desenvolvimento na sequência

principal tem as seguintes vantagens:

  Reduz integrações e sincronizações   Permite que as alterações sejam

(11)

Sequência Principal

 

Deve-se criar ramos quando:

  Versões para o cliente em que já se está

a fazer depuração – isolam a versão a entregar ao cliente de novas

funcionalidades

  Tarefas de longa duração em que várias

(12)

Sequência Principal

 

Aspectos por resolver

  Como manter a sequência principal

usável quando muitas pessoas estão a trabalhar nela?

(13)

Sequência Activa

 

Contexto

  O desenvolvimento de uma nova versão

do produto está a ser feito numa sequência principal

  O código está a ser alterado por muitas

pessoas

  As alterações podem corromper o

sistema e/ou podem ocorrer conflitos entre alterações

(14)

Sequência Activa

 

Problema

  Como manter uma sequência de código

que evolui rapidamente num estado suficientemente estável para que seja útil?

(15)

Sequência Activa

 

Pretende-se que a equipa trabalhe

em paralelo

 

Uma sequência de código com erros

atrasa o desenvolvimento

 

Situações de impasse podem ocorrer

se não forem criados pontos de

sincronização

 

Testes podem ser demorados e

provocar atrasos

(16)

Sequência Activa

 

Solução

  Estabelecer políticas que tornem a

sequência de código principal

suficientemente estável para o trabalho que é necessário

  Não procurar uma sequência de

desenvolvimento activa perfeita, mas sim uma sequência principal que é

usável e suficientemente activa para as necessidades

(17)

Sequência Activa

 

O que é difícil é perceber quão “boa”

deve ser a sequência de código:

  Quem usa a sequência de código?   Que percentagem do sistema está a

evoluir?

  Qual é o ciclo de entrega?

  Que mecanismos de testes temos

disponíveis?

  Qual é o preço de um ciclo em que a

(18)

Sequência Activa

 

Aspectos por resolver

  Uma política da sequência deve

estabelecer como deve ser o processo de confirmação da sequência

  Os programadores devem usar um

espaço de trabalho privado para isolar alterações e manter a sequência activa

  Uma sequência de preparação para

entrega deve ser criada se se procura estabilidade

  Criar um ramo para tarefas de longa

(19)

(20)

Bibliografia

 

A Visual Guide to Version Control

http://betterexplained.com/articles/a-visual-guide-to-version-control/

 

Distributed Version Control

http://www.joelonsoftware.com/items/ 2010/03/17.html

 

Livro: Software Configuration

Management Patterns: Effective

Teamwork, Practical Integration

(21)

Espaço de Trabalho Privado

 

Contexto

  Está-se a trabalhar numa sequência

activa

  Pretende-se trabalhar com o código mais

actualizado

  Pretende-se controlar quando se começa

a trabalhar com as alterações que os outros entretanto fizeram

(22)

Espaço de Trabalho Privado

 

Problema

  Como se manter actualizado com as

alterações mais recentes do código mas sem sofrer alterações não controladas do ambiente de trabalho, de forma a poder progredir?

(23)

Espaço de Trabalho Privado

 

O desenvolvimento no contexto de

uma equipa envolve os seguintes

passos:

  Escrever e testar as nossas alterações ao

código

  Integrar o nosso código com o trabalho

das outras pessoas

 

A integração pode ser:

  Contínua   Diferida

(24)

Espaço de Trabalho Privado

 

Solução

  Fazer o trabalho num espaço privado

onde se pode controlar as versões do código com que se está a trabalhar

(25)

Espaço de Trabalho Privado

 

Um espaço de trabalho contém o

seguinte:

  Código que se está a editar

  Componentes construídos localmente   Objectos de terceiros que não se

pretende construir

  Configuração e dados necessários para

executar e testar o sistema

  Scripts de construção do sistema neste

espaço de trabalho

  Informação identificando as versões de

(26)

Espaço de Trabalho Privado

 

Um espaço de trabalho não deve

conter o seguinte:

  Scripts privados genéricos de construção

do sistema

  Ferramentas e compiladores que são os

mesmos para todas as versões do produto

(27)

Espaço de Trabalho Privado

  O seguinte procedimento deve ser

seguido:

1.  Obter os dados mais recentes da sequência activa

2.  Fazer alterações

3.  Fazer uma Construção Privada do Sistema

4.  Testar as alterações com Testes de Unidade

5.  Actualizar o espaço de trabalho com a versão mais recente dos componentes na sequência activa

6.  Construir o sistema e executar Testes de Despistagem para garantir que não se

(28)

Espaço de Trabalho Privado

 

Aspectos por resolver

  Uma Construção Privada do Sistema

evita que se introduzam erros quando se fazem confirmações

  É necessário carregar o espaço de

trabalho de um Repositório

  Componentes externos devem vir de

uma Sequência de Terceiros

  Uma vez que o trabalho isolado está

terminado é necessário integrar com o resto do sistema fazendo uma

(29)

Repositório

 

Contexto

  Para criar um Espaço de Trabalho

Privado ou para executar uma

Construção de Integração é necessário obter os componentes certos

 

Problema

  Como obter as versões correctas dos

componentes certos num espaço de trabalho?

(30)

Repositório

 

Solução

  Ter um único ponto de acesso, ou

repositório, para o código e outros artefactos relacionados

  Fazer com que criar um espaço de

trabalho seja o mais simples e transparente possível

(31)

Repositório

 

Uma forma simples de implementar

este padrão é colocar todo o código

fonte, ficheiros de configuração,

scripts de construção e componentes

de terceiras partes no sistema de

controlo de versões

 

Aspectos por resolver

  Organizar o código de terceiras partes

(32)

Construção Privada do Sistema

 

Contexto

  As alterações feitas no Espaço de

Trabalho Privado devem funcionar com o restante sistema

 

Problema

  Como se verifica, antes de se confirmar

as alterações, que as nossas alterações não vão corromper o sistema?

(33)

Construção Privada do Sistema

  Fazer confirmação de alterações que podem

corromper o sistema e fazem perder tempo

  A construção de pré confirmação pode

funcionar bem mas a construção da noite falha

  A depuração feita a partir do nosso

ambiente de desenvolvimento dá mais pistas do que a que é feita a partir do sistema em produção

(34)

Construção Privada do Sistema

 

Solução

  Antes de confirmar o código deve-se

construir o sistema usando uma

construção privada similar à construção da noite

(35)

Construção Privada do Sistema

 

A construção privada deve ter as

seguintes características:

  Ser, tanto quanto possível, como a

Construção de Integração e as construções do produto

  Incluir todas as dependências

  Incluir todos os componentes que

(36)

Construção Privada do Sistema

 

Pode ser feita uma construção

completa ou uma construção

incremental

 

Deve ser feita uma construção

completa sempre que:

  Se estão a adicionar novos ficheiros ao

sistema de controlo de versões – deve-se começar com um espaço de trabalho vazio

  Houve alterações profundas de

(37)

Construção Privada do Sistema

 

Aspectos por resolver

  Depois de se ter verificado que se

consegue construir o sistema deve ser feito um Teste de Despistagem para verificar se a funcionalidade não ficou corrompida

  Se o sistema é muito grande pode não

ser eficiente construir todos os

componentes que usam os nossos

componentes, sendo isso deixado para a Construção de Integração

(38)

Construção de Integração

 

Contexto

  Os programadores trabalham

separadamente nos seus espaços de trabalho

  O trabalho deve ser integrado

 

Problema

  Como garantir que a construção na

sequência activa que resulta da

integração dos espaços de trabalho é fiável?

(39)

Construção de Integração

  Alterações em paralelo podem não ser

compatíveis

  Uma construção completa e centralizada

pode resolver o problema

  Solução

  Garantir que todas as alterações, e suas

dependências, são construídas usando um processo de integração central. Deve ser:

  Reproduzível

  Similar à construção do produto final

  Automatizado ou requerendo pouca intervenção   Mecanismos de notificação e história

(40)

Construção de Integração

 

Fazer a integração num espaço de

trabalho que contenha os

componentes a serem integrados

 

Determinar a frequência das

construções de integração baseado

em:

  Quanto tempo demora a construir o

sistema

(41)

Construção de Integração

 

Aspectos a resolver

  Após a construção de integração fazer

Teste de Despistagem

  Se a construção for publicada como uma

(42)

Sequência de terceiros

 

Contexto

  A sequência de código está associada a

um conjunto de componentes externos que fazem parte do produto

  Alguns dos produtos externos podem ter

de ser adaptados

  Pode ser necessário associar versões de

componentes externos ao nosso produto

  Os componentes externos devem ser

(43)

Sequência de terceiros

  Problema

  Qual a estratégia mais eficaz de coordenar

as versões de componentes externos com versões do código do produto?

(44)

Sequência de terceiros

 

Os ciclos de versões de entrega de

um vendedor são diferentes dos ciclos

de versões do nosso produto

 

É necessário identificar que versões

do componente externo fazem parte

de cada versão do nosso produto

 

Se forem feitas alterações ao

componente externo é necessário que

essas alterações sejam integradas

(45)

Sequência de terceiros

 

Solução

  Criar uma sequência de código para

código de terceiros

  Construir espaços de trabalho e

procedimentos de instalação a partir desta sequência de código

(46)

Sequência de terceiros

  Criar ramos separados para o código da

terceiros e para as versões das adaptações a ele feitas

(47)

Alteração de Nível Tarefa

 

Contexto

  Uma construção de integração é fácil de

depurar se soubermos o que podemos retirar até ela funcionar

 

Problema

  Quanto trabalho deve ser feito entre

submissões ao sistema de controlo de versões?

  Quanto tempo se deve esperar antes

(48)

Alteração de Nível Tarefa

 

Codificar é uma sequência de

depuração de erros, melhorias e

novas funcionalidades que devem ser

registadas

 

Adicionar uma funcionalidade ou

corrigir um erro pode levar a muitas

alterações no código

 

Deve ser possível recuperar para um

estado anterior às alterações se elas

corromperem o sistema

(49)

Alteração de Nível Tarefa

 

Quando uma construção de

integração falha deve ser possível

identificar a alteração que provocou a

falha

  Uma história de alterações de grande

granularidade reduz a sobrecarga de confirmações

  Uma história detalhada de alterações

(50)

Alteração de Nível Tarefa

 

Solução

  Fazer uma confirmação por cada tarefa

consistente de pequena granularidade

  Cada alteração deve representar um

(51)

Confirmação de Nível Tarefa

 

Aspectos por resolver

  As alterações que demoram muito tempo

e são difíceis de alcançar devem ser feitas num Ramo por Tarefa

  A existência de testes de unidade,

regressão e despistagem permitem motivar confirmações de pequena granularidade

(52)

Teste de Despistagem

 

Contexto

  A construção de integração e a

construção privada do sistema são úteis para verificar aspectos de integração em tempo de construção

  É necessário verificar aspectos de tempo

de execução

 

Problema

  Como saber que o sistema continua a

funcionar após se ter feito uma alteração?

(53)

Teste de Despistagem

 

Podem-se escrever testes que cobrem

as partes mais críticas e sujeitas a

falhas do sistema, mas é difícil de

desenvolver testes completos

 

Correr todos os testes disponíveis

pode ser muito demorado

 

Testes que demoram muito a

executar levam a que o programador

aumente o tempo entre integrações

(54)

Teste de Despistagem

 

Solução

  Sujeitar cada construção a um teste de

despistagem que verifica que o sistema não se corrompeu de uma forma óbvia

  Os testes de despistagem devem ser

automatizados

 

Os testes de despistagem não

substituem testes mais exaustivos

 

Não são desculpa para não testar o

(55)

Teste de Despistagem

 

Um teste de despistagem deve:

  Rápido a executar

  Indicar automaticamente do seu sucesso

ou insucesso

  Fornecer uma cobertura abrangente do

sistema que é o nosso alvo

  Poder ser executado pelos

programadores como parte do processo de garantia de qualidade

(56)

Teste de Despistagem

 

Aspectos por resolver

  Um teste de despistagem deixa muitos

aspectos por testar que devem ser

considerados num Teste de Regressão

  Os programadores devem fazer um Teste

de Unidade por cada módulo que necessitam

  Utilizar Teste de Unidade para verificar

que o módulo que se está a alterar

(57)

Teste de Unidade

 

Contexto

  Um teste de despistagem não é

suficiente para testar uma alteração em detalhe, especialmente quando se está a trabalhar num novo módulo

 

Problema

  Como testar que um módulo continua a

funcionar correctamente após ter sido alterado

(58)

Teste de Unidade

 

Quando um teste de despistagem

falha desejamos saber que parte do

sistema falhou

 

Desejamos isolar os aspectos de

integração das alterações locais

 

Desejamos testar o contrato que cada

(59)

Teste de Unidade

 

Solução

  Desenvolver e executar testes de

unidade

 

Os testes de unidade devem ter as

seguintes características:

  São automáticos e auto avaliam-se   Têm pequena granularidade

  São isolados

(60)

Teste de Unidade

 

Os testes de unidade devem ser

executados quando:

  Se está a codificar

  Antes de confirmar uma alteração

  Para encontrar um problema com um

teste de despistagem ou de regressão

 

Os testes de unidade devem ser

suportados por “frameworks” como o

Junit, CxxUnit, PyUnit, etc

(61)

(62)

Política da Sequência

 

Contexto

  Existem diversas sequências de código e

os programadores necessitam de saber como trabalhar em cada uma delas

  Uma Sequência da Entrega deve ter

regras muitos restritivas acerca de como e quando se pode alterar

  Numa Sequência Activa as regras devem

(63)

Política da Sequência

 

Problema

  Como é que os programadores sabem

em que sequência de código confirmar o seu código, quando o fazer e que testes devem correr antes de o fazer?

(64)

Política da Sequência

  Cada sequência de código tem objectivos

diferentes

  Depuração   Entrega

  Portar para outra plataforma   Nova versão

  ...

  Cada sequência tem requisitos de

estabilidade diferentes

  É difícil garantir que os programadores

(65)

Política da Sequência

 

Solução

  Para cada sequência de código

estabelecer uma política que determina quando e como os programadores

podem fazer alterações

  As políticas devem ser   concisas

  1 a 3 parágrafos, máximo 1 página

  auditáveis   acessíveis

(66)

Política da Sequência

  A descrição do objectivo da sequência (3

parágrafos) pode incluir:

  Tipo de trabalho – desenvolvimento,

manutenção, versão, função, subsistema

  Quando e como devem os elementos ser

confirmados, checked out, criados ramos ou integrados

  Restrições de acesso por indivíduo, papel ou

grupo

  Relações com outras sequências

  Duração do trabalho e quando a sequência deve

terminar

  Carga esperada de actividade e frequência de

(67)

Política da Sequência

  Algumas políticas de sequências

  Desenvolvimento – alterações intermédias ao

código devem ser confirmados e os

componentes afectados devem ser construídos

  Entrega – o sistema deve ser construído e

passar testes de regressão antes da

confirmação; as confirmações estão limitados à depuração de erros; não são introduzidas novas funcionalidades; após a confirmação a sequência não sofre alterações até que todo o ciclo de QA termina

  Principal – todos os componentes devem

compilar e passar testes de regressão, e novas funcionalidades completamente testadas podem ser confirmadas

(68)

Política da Sequência

 

Aspectos por resolver

  É necessário utilizar automatização e ter

em consideração a cultura da equipa

(69)

Versões Privadas

 

Contexto

  É necessário avaliar rapidamente uma

alteração complexa que pode corromper o sistema que está a ser desenvolvido na sequência activa

 

Problema

  Como se pode experimentar uma

alteração complexa, tirando ao mesmo tempo partido do sistema de controlo de versões, sem tornar as alterações

(70)

Versões Privadas

 

As alterações, mesmo as complexas,

são melhor feitas em pequenos

passos que podem ser refeitos

 

O processo de alteração pode

consistir em experimentar diversas

alternativas

 

O sistema de controlo de versões

permite criar pontos de recuperação

(checkpoint)

 

Trabalhando só no espaço de trabalho

(71)

Versões Privadas

 

Solução

  Fornecer aos programadores um

mecanismo de guardar as alterações a um nível de granularidade com que eles estejam confortáveis

  Utilizar uma área local de controlo de

revisões

  Apenas o código estável é confirmado no

(72)

Versões Privadas

 

A área local de controlo de versões

pode ser um ramo

 

Deve-se assegurar que os

programadores que utilizam a versão

privada migram as alterações para o

sistema de controlo de versões

(73)

Sequência da Entrega

 

Contexto

  Está-se a fazer desenvolvimento sobre

uma sequência activa

  Foram entregues versões que

necessitam de manutenção e pequenas melhorias

  Pretende-se manter a versão entregue

estável

 

Problema

  Como fazer a manutenção de uma

versão entregue sem interferir com o

(74)

Sequência da Entrega

 

É necessário reparar urgentemente

um erro de uma versão em produção

e a versão em desenvolvimento não

vai estar pronta rapidamente

 

Os utilizadores não querem fazer

actualização para uma nova versão

 

O esforço de manutenção da versão

entregue pode ser incompatível com

alguma da funcionalidade ou

refactorização em curso na versão em

desenvolvimento

(75)

Sequência da Entrega

  Solução

  Separar a versão entregue e a nova versão em

diferentes sequências de código

  Cada versão entregue é

  uma sequência (sequência da entrega)   ramo da sequência principal

  Na sequência da entrega será feita a

(76)

Sequência da Entrega

 

Alterações na sequência de entrega

são propagadas para a sequência

activa com regularidade – sempre

antes da próxima entrega

 

Correcções de erros na sequência

principal devem ser propagados para

a sequência de entrega se possível

 

O código da sequência da entrega fica

“morto” quando a versão deixa de ser

suportada

(77)

Sequência de Preparação para Entrega

 

Contexto

  Está-se a terminar uma entrega e é

necessário iniciar o desenvolvimento de uma nova versão

 

Problema

  Como estabilizar o código que se está a

preparar para um entrega permitindo contudo que novo trabalho continue na sequência activa

(78)

Sequência de Preparação para Entrega

 

Por vezes o processo de preparação

de uma entrega pode-se prolongar

devido a vários factores –

configurações, instalações, erros

imprevistos,...

 

Nem toda a equipa necessita de estar

envolvida na actividade de preparar a

entrega

(79)

Sequência de Preparação para Entrega

 

Solução

  Criar um ramo de engenharia da entrega

quando o código começa a ter a

qualidade necessária para a entrega

  Terminar de preparar a entrega neste

ramo enquanto que na sequência activa continua o restante desenvolvimento

  O ramo torna-se no ramo da entrega   O responsável pela sequência activa

define a política sobre como e quando as alterações são propagadas da sequência de preparação para a sequência activa

(80)

Sequência de Preparação para Entrega

 

Aspectos por resolver

  Se poucas pessoas estão a trabalhar na

nova versão cria-se um ramo por tarefa para a nova versão

(81)

Ramo por Tarefa

 

Contexto

  Algumas tarefas de desenvolvimento

demoram muito tempo e os seus passos intermédios geram muita instabilidade

 

Problema

  Como pode uma equipa fazer múltiplas

alterações, e de longa duração, a uma sequência de código, sem comprometer a sua consistência e integridade