gerênciade) conﬁguração:) terminologialeomurta/courses/2013.1/gc/aula3.pdfleonardo)murta...

Gerência de Configuração: Terminologia

Leonardo Gresta Paulino Murta [email protected]

Leonardo Murta Gerência de Configuração: Terminologia 2

Item de configuração •  Agregação de hardware e/ou soEware que será passível de gerência de configuração e tratado como um elemento único

•  Tipos de ICs – Produtos de trabalho do projeto – Produtos de trabalho de processos

•  Exemplos: plano de GC, requisitos, modelos, código-‐fonte, etc.


Item de configuração •  A seleção de ICs deve levar em conta princípios como

acoplamento e coesão •  ICs com alto acoplamento tornam complexo o processo de

construção –  Muitas dependências para outros ICs

•  ICs com baixa coesão tornam o processo de desenvolvimento complexo –  Vários desenvolvedores concorrendo para modificar o IC

•  GCS é altamente beneficiada por sistemas com arquitetura corretamente definida


Item de configuração Sistema

Subsistema

Procedimento

Módulo

Granularidade Grossa

Fina

Comando Parágrafo

Seção

Documento Programa

PerspecZva: Desenvolvimento Gerencial

Linha

Arquivo

Diretório

Processo

Necessidade de ferram

entas

Menor

Maior


Item derivado •  Item de configuração que pode ser obZdo a parZr de outro item de

configuração (item fonte)

•  Exemplo

–  Os itens de configuração que compõem o código-‐fonte são itens fonte para o programa executável, que é item derivado

•  Estratégias

–  Versionamento do item derivado

–  Documentação do processo de derivação (roteiro, ferramentas, ambiente, etc.)


Construção (building)

•  Processo de compilação do sistema a parZr dos itens fonte para uma configuração alvo

•  UZliza arquivo de comandos que descreve como deve ocorrer a construção

•  Exemplo: makefile, build.xml, pom.xml

•  Os arquivos de comandos também devem ser considerados itens de configuração


Versões •  Instâncias de um mesmo item de configuração que diferem entre si em algo

•  Revisões: versões criadas para subsZtuir versões anteriores seguindo uma linha temporal (e.g., em resposta a correção ou evolução)

•  Variantes: versões coexistentes, projetadas para propósitos disZntos (e.g., em resposta a diferentes arquiteturas de hardware ou sistemas operacionais)


Versões

[Pressman, 1997] ICs, versões e variantes

Variantes

ICs

Versões

IC 1.0

IC 1.1

IC 1.2

IC 1.1.1

IC 1.1.2

IC 1.3

IC 2.0

IC 1.4

IC 2.1

A1 A2 A3

A4’ A4’’

Sistema de Gerência de Configuração


Versão 1

Versão 2

Versão 3

Versão 4

Versão 5



Versão 1

Versão 2

Versão 3

Versão 4

Versão 5



Artefatos

Controle de Versões

Construção e Release

Controle de Modificações

Solicitações

Controle de versões


Armazenamento? Colaboração? Consulta?

Topologia?

IC

Repositório

O Repositório •  Local onde os ICs são armazenados

–  Armazena o histórico do projeto –  Controle na entrada e saída de ICs –  Poucos por projeto (normalmente, somente um)

•  UZliza diferentes mecanismos de armazenamento –  Versionamento completo –  Versionamento de diferenças (delta)

•  UZliza diferentes mecanismos de controle de concorrência –  Pessimista –  OZmista –  Misto

•  Permite a geração de diferentes relatórios –  Por item de configuração –  Por modificação

Gerência de Configuração: Terminologia 14 Leonardo Murta

Topologia


Repositório

Espaço de Trabalho

Centralizado Distribuído

check-‐in / commit

check-‐out / update Repositório

Espaço de Trabalho ch

eck-‐in

check-‐out / update

Repositório

Espaço de Trabalho

clone / pull

push


Armazenamento •  Versionamento completo

– Demanda grande espaço em disco – Permite rápida recuperação dos ICs

•  Versionamento de diferenças – Reduz o espaço requerido em disco – Qualquer versão pode ser derivada a parZr da aplicação dos deltas sobre a versão base

– Pode demandar grande carga de processamento para recuperar ICs

– Tipos existentes: forward, reverse e in-‐line

Armazenamento


v.3

v.2

v.1

Completo

delta 1à2

v.1

Forward

delta 2à3

delta 3à2

v.3

Reverse

delta 2à1

In-line

v.1 v.2/3

v.1/2 v.3


Colaboração •  Controle de concorrência pessimista

–  Somente um desenvolvedor pode modificar o IC em um dado momento –  Custo zero de junção de trabalho –  Ausência de paralelismo no desenvolvimento

•  Controle de concorrência oZmista –  Vários desenvolvedores pode modificar um mesmo IC ao mesmo tempo –  Alto custo de junção de trabalho no caso de ICs complexos (e.g.: IC binários) –  Permite paralelismo no desenvolvimento

•  Controle de concorrência oZmista com noZficação –  Permite que qualquer desenvolvedor saiba quem mais está modificando o IC –  Bom custo/beneqcio entre controle oZmista e pessimista

Colaboração


m.3

m.2

m.1

Pessimista

junção

m.1

Otimista Misto

m.2 m.3

junção

m.1 m.2 m.3

Consulta


Repositório (versão 1) Artefato1 (versão 1) Artefato2 (versão 1) Artefato3 (versão 1)


Repositório (versão 0) Repositório (versão 3) Artefato1 (versão 2) Artefato2 (versão 3) Artefato3 (versão 1) Artefato4 (versão 3)

Repositório (versão 4) Artefato1 (versão 4) Artefato2 (versão 3) Artefato3 (versão 4) Artefato4 (versão 3)

Artefato1 Versão 1 Versão 2 Versão 4

Artefato2 Versão 1 Versão 3

Artefato3 Versão 1 Versão 4

Artefato4 Versão 3

Consulta por artefato 1ª modificação

2ª modificação 4ª modificação 3ª modificação

Consulta




Repositório (versão 0)

1ª modificação

2ª modificação



4ª modificação 3ª modificação

1ª modificação Artefato1 adicionado Artefato2 adicionado Artefato3 adicionado

2ª modificação Artefato1 modificado

3ª modificação Artefato2 modificado Artefato4 adicionado

Consulta por modificação

4ª modificação Artefato1 modificado Artefato3 modificado

Consulta


Item de ConfiguraÁ„o

Vers„o

1

*

ModificaÁ„o

*

1

Arquivo 5 Versão 1 Versão 2 Versão 4

Modificação 4 Arquivo 2 Arquivo 5 Arquivo 7


Espaço de trabalho •  Local onde o usuário pode fazer seu trabalho de forma isolada

–  Armazena um momento específico do projeto

–  Controle sobre quando sincronizar com o repositório

– Muitos por projeto (normalmente, um ou mais por desenvolvedor)

–  Sinônimo: caixa de areia (sandbox)


Configuração •  Um conjunto de versões de ICs, onde existe somente uma

versão selecionada para cada IC do conjunto •  Uma configuração pode ser vista como um IC composto de

outros ICs •  Exemplos

–  Configuração do sistema –  Configuração do processo –  Configuração do módulo X –  Configuração dos requisitos do sistema –  Configuração do código fonte


Configuração x versão

Configuração

Versão

IC composto IC primiZvo

IC

•  Genericamente –  O sistema S é composto pelos arquivos X, Y e Z

•  Concretamente –  A configuração 5 do sistema S é composta pela versão 2 do arquivo X,

versão 4 do arquivo Y e versão 6 do arquivo Z


Rótulo (label) •  Mecanismo usado para idenZficar uma configuração

–  As diversas versões de ICs marcadas com um rótulo consZtuem uma configuração do sistema

•  Permite idenZficar níveis de qualidade dos ICs

•  Sinônimo: eZqueta (tag)

1.1

1.2

1.3

AloMundo.java

1.1

1.2

1.3

BemVindo.java

1.1

1.2

build.xml

1.1

1.2

Usuario.java

RECUSADA

ACEITA

Rótulos


Configuração x versão IC composto

Conf. 1

Conf. 2

Conf. 3

IC primiZvo 1 IC primiZvo 2 IC primiZvo 3

V.1

V.2

V.3

V.4

V.1

V.2

V.1

V.2

V.3


Baseline •  Configuração revisada e aprovada que serve como base para uma

próxima etapa de desenvolvimento e que somente pode ser modificada via processo formal de GCS

•  São estabelecidas ao final de cada fase de desenvolvimento: análise (func=onal), projeto (allocated) e implementação (product)

•  Momento de criar: balanceamento entre controle e burocracia


Baseline

Tarefas de engenharia de software

ICs

Revisões técnicas formais

ICs

modificados

Controle de GC ICs

ICs aprovados

extraídos

ICs armazenados

[Pressman, 1997] Processo de atualização de configurações de referência


Baseline (níveis de controle)

Coordenação c/ auditoria Controle

Pré baseline: • Informal • Sem requisição • Sem aprovação • Sem verificação • Ágil • Ad-‐hoc

Pós baseline: • Formal • Com requisição • Com aprovação • Com verificação • BurocráZco • Planejado

Nível de controle

Baseline (níveis de controle) Requisito 1 Análise Projeto

Baseline 1: • An. Req. 1

Requisito 2 Análise Projeto

Tempo

Req. Análise Projeto Análise Projeto Análise Projeto 1 Inform. - Formal Inform. Formal Formal 2 - - Inform. - Formal Inform.

Baseline 2: • An. Req. 1 • Pr. Req. 1 • An. Req. 2



Liberação (release) •  SubstanZvo: Versão disponibilizada para um propósito específico

•  Verbo: NoZficação formal e distribuição de uma versão aprovada

•  Importante

–  Toda liberação é uma versão

–  Nem toda versão é uma liberação

•  Em alguns casos liberações podem ser desenvolvidas em paralelo (=me to market)

•  Exemplos

–  Liberação para testes de sistema

–  Liberação para homologação

–  Liberação para entrega ao cliente


Exemplo de liberações

1.1

1.2

1.3

1.4

1.5

AloMundo.java

1.1

1.2

1.3

1.4

1.5

BemVindo.java

1.1

1.2

build.xml

1.1

1.2

1.3

Usuario.java

rel_1-‐0-‐0

rel_1-‐0-‐1

rel_1-‐1-‐0

1.6

Rótulos

HEAD


Ramos (branches) •  Versões que não seguem a linha principal de desenvolvimento

•  Fornecem isolamento para o processo de desenvolvimento

–  Ramos usualmente são migrados à linha principal de desenvolvimento

–  A migração pode ser complicada no caso de isolamento longo

•  O espaço de trabalho de um desenvolvedor pode ser visto como um ramo

–  Extremamente isolado (ramos são comparZlhados por outras pessoas)

–  Que reside no cliente (ramos residem no servidor)

–  Que são momentâneos (ramos são históricos)

–  Que são temporários (ramos são permanentes)


Exemplo de ramo

1.2

AloMundo.java

1.2

BemVindo.java

1.1

build.xml

1.1

Usuario.java

rel_1-‐0-‐0

Rótulo

remendos_rel_1-‐0-‐0

1.2.2.1 1.2.2.1 1.1.2.1 1.1.2.1

Ramo

... ... ... ...


Junção •  Processo de migração de

–  Espaços de trabalho –  Ramos

•  É necessário inclusive em desenvolvimento seqüencial (check-‐out reservado) quando são uZlizados ramos

•  Algoritmos automáZcos se dividem em duas categorias –  Genéricos (servem para qualquer linguagem) –  Específicos (levam em conta a estrutura semânZca da linguagem)


Junção •  As ferramentas de GCS usualmente uZlizam algoritmos

genéricos –  2-‐way merge –  3-‐way merge

Linha 1 Linha 2 Linha 3

Linha 1’ Linha 2

<Linha 1> ou <Linha 1’>? Linha 2 <Linha 3> ou nada?

Linha 1 Linha 2 Linha 3

Linha 1’ Linha 2

Linha 1’ Linha 2 Linha 3

Linha 1 Linha 2


Exemplo de junção

1.1 1.2 1.3 1.4 1.5 BemVindo.java

1.2.2.1 1.2.2.2

Δ2

Δ1

1.6

1.6 = 1.2 + Δ1 + Δ2

•  A junção é efetuada para cada artefato do ramo •  São levadas em consideração todas as modificações

desde o ancestral em comum


Exemplo de junção (incremental)

1.2 1.3 1.4 1.5

AloMundo.java

1.2.2.1 1.2.2.2

Δ2

Δ1

1.6

•  O que fazer quando o ramo conZnua evoluindo mesmo depois da junção?

1.7 1.8

Δ3

1.2.2.3 1.2.2.4

Δ4


Exemplo de junção (incremental)

1.2 1.3 1.4 1.5

AloMundo.java

1.2.2.1 1.2.2.2

Δ2

Δ1

1.6 1.7 1.8

Δ3

1.9

1.2.2.3 1.2.2.4

Δ4

1.9 = 1.6 + Δ3 + Δ4

rel_1-‐0-‐1 rel_1-‐0-‐2

HEAD

BASE


Conflitos •  Situação onde não é possível executar a junção de forma

automáZca •  Tipos

–  Físico (linha do arquivo) –  Lógico (sintaxe do arquivo) –  SemânZco (conteúdo do arquivo)

•  O suporte atual concentra no nível qsico! •  Exemplos de conflitos qsicos

–  Alterações em paralelo de uma mesma linha –  Remoção e alteração em paralelo de uma mesma linha –  Adições de linhas em paralelo na mesma região do arquivo


Conflitos no vi


Conflitos no Eclipse


Conflitos no NetBeans


Conflitos no JBuilder

Gerência de Configuração: Terminologia

Leonardo Gresta Paulino Murta [email protected]

gerênciade) conﬁguração:) terminologialeomurta/courses/2013.1/gc/aula3.pdfleonardo)murta...

Documents