conﬁguraon* management foundaonsleomurta/courses/2017.1/gc/aula3.pdfleonardomurta*...

Configura)on Management Founda)ons

Leonardo Gresta Paulino Murta [email protected]

Leonardo Murta Configura)on Management Founda)ons 2

Configura)on Item •  Hardware or so@ware aggrega)on subject to configura)on management

•  Examples: – CM plan – Requirement Engineering Process – Requirements – Models – Source-‐code of component X – Etc.


Configura)on Item •  The selec)on of CI should take into considera)ons basic

design principles such as coupling and cohesion •  High coupling introduces complexity to the building process

–  Many dependencies among CI

•  Low cohesion introduces complexity to the development process –  Many developers working over the same CI

•  CM benefits from well defined architectures


Configura)on Item

System

Module

Procedure

Granularity Coarse

Fine

Command Paragraph

Sec)on

Document Program

Perspec)ve: Code Documenta)on

Line

File

Directory

Tool Demand

Lower

Higher


Derived Item •  A CI may be derived from other CI (source items)

•  Example: –  Executable files are derived from the source code

–  DB Schema is derived from class models

–  Etc.

•  CM Strategies –  Version control the derived items

–  Document and version control the deriva)on process (script, tools, environment, etc.)


Building •  Process that generates derived items from source items considering a target configura)on

•  Uses automated build scripts to describe the process •  Example:

– makefile, –  build.xml, –  pom.xml

•  The build scripts are also subject to CM


Version •  Different instances of the same CI •  Three types of Versions:

Version

Revision Variant Coopera)on (dra@)

(Conradi and Wes_echtel 1998)

Revisions


iMac genera)ons (1998 – 2013)

Variants


Hatchback

Coupe

Sedan

Honda Civic

Coopera)on (dra@ versions)


John’s workspace

Mary’s workspace

Peter’s workspace

Base version

Dra@ versions may be merged


John’s workspace Mary’s workspace Peter’s workspace

Revisions

Conflicts may happen during merge


John workspace Fred workspace

Revisions

Two other important opera)ons…

… for storing, transferring, and comprehending versions Leonardo Murta Configura)on Management Founda)ons 13

Diff =

Patch =

Versions in the wild •  Mul)tude of revisions and variants altogether (set aside dra@ versions)


History of Git

But, what are versions good for? •  Synchronizing teamwork •  Reproducing previous configura)ons •  Exploring possibili)es •  Segrega)ng developers •  Customizing products (SPL) •  Tracing bug introduc)on (bisect) •  Understanding evolu)on (MSR) •  Audi)ng changes (annotate) •  Etc.


CM System


Version 1

Version 2

Version 3

Version 4

Version 5

CM System


CI

Version Control

Build and Release

Issue Tracking

Change Requests

Version Control


Storage? Collabora)on? Query?

Topology? CI

Repository

Topology


Repository

Workspace

Centralized Distributed

check-‐in / commit

check-‐out / update Repository

Workspace check-‐in

check-‐out / update

Repository

Workspace

clone / pull

push

Storage


v.3

v.2

v.1

Complete

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

c.1

Collabora)on


c.3

c.2

c.1

Pessimist

merge

Optimist Mixed

c.3 c.2

c.1

merge

c.3 c.2

Query


Repository (version 1) Ar)fact1 (version 1) Ar)fact2 (version 1) Ar)fact3 (version 1)


Repository (version 0) Repository (version 3) Ar)fact1 (version 2) Ar)fact2 (version 3) Ar)fact3 (version 1) Ar)fact4 (version 3)

Repository (version 4) Ar)fact1 (version 4) Ar)fact2 (version 3) Ar)fact3 (version 4) Ar)fact4 (version 3)

Ar)fact1 Version 1 Version 2 Version 4

Ar)fact2 Version 1 Version 3

Ar)fact3 Version 1 Version 4

Ar)fact4 Version 3

Query by ar)fact 1st change

2nd change 4th change 3rd change

Query


1st change Ar)fact1 added Ar)fact2 added Ar)fact3 added

2nd change Ar)fact1 changed

3rd change Ar)fact2 changed Ar)fact4 added

Query by change

4th change Ar)fact1 changed Ar)fact3 changed



Repository (version 0) Repository (version 3) Ar)fact1 (version 2) Ar)fact2 (version 3) Ar)fact3 (version 1) Ar)fact4 (version 3)

Repository (version 4) Ar)fact1 (version 4) Ar)fact2 (version 3) Ar)fact3 (version 4) Ar)fact4 (version 3)

1st change

2nd change 4th change 3rd change

Query


Ar)fact1 Version 1 Version 2 Version 4

Change 4 Ar)fact1 Ar)fact3

Version

CI Change

*

1

* 1


Configura)on •  A set of CI versions where there is one and only one version

per CI •  A configura)on can be seen as a CI composed by other CI •  Examples

–  System configura)on –  Process configura)on –  Module X configura)on –  Requirements configura)on –  Source-‐code configura)on


Configura)on vs. version

Configura)on

Version

Composite CI Atomic CI

CI

•  Generically speaking –  The system S is composed by CI X, Y, and Z

•  Concretely speaking –  The configura)on 5 of system S is composed by version 2 of CI X,

version 4 of CI Y, and version 6 of CI Z


Tag •  VCS usually register mul)ple configura)ons, but just few are of interest to the

user

•  Tags allow naming such configura)ons

•  Names can be user to indicate versions, quality levels, etc.

1.1

1.2

1.3

HelloWorld.java

1.1

1.2

1.3

Welcome.java

1.1

1.2

build.xml

1.1

1.2

User.java

REJECTED

ACCEPTED

Tags


Configura)on vs. version Composite CI

Conf. 1

Conf. 2

Conf. 3

Atomic CI Atomic CI Atomic CI

V.1

V.2

V.3

V.4

V.1

V.2

V.1

V.2

V.3


Baseline •  “A specifica)on or product that has been formally reviewed and

agreed upon, that therea@er serves as the basis for further development, and that can be changed only through formal change control procedures” (IEEE 610.12, 1990).

•  Baselines are created at the end of each development phase: analysis (func)onal), design (allocated) and coding (product)

•  When is the correct moment for crea)ng baselines? –  Control vs. Bureaucracy


Baseline

SE Tasks

CI

Formal techinical reviews

CI

changed

Change Control CI

CI approved

checked-out

CI stored

[Pressman, 1997] Baseline update process


Baseline (levels of control)

Coordina)on and audi)ng Control

Pre baseline: • Informal • Without request • Without evalua)on • Without verifica)on • Agile • Ad-‐hoc

Post baseline: • Formal • With request • With evalua)on • With verifica)on • Bureaucra)c • Planned

Levels of control

Baseline (levels of control) Requirement 1 Analysis Design

Baseline 1: • An. Req. 1

Requirement 2 Analysis Design

Time

Req. Analysis Design Analysis Design Analysis Design 1 Inform. - Formal Inform. Formal Formal 2 - - Inform. - Formal Inform.

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



Release •  Noun: Version provided for a specific purpose •  Verb: Formal no)fica)on and distribu)on of a version (usually

baseline)

•  All release are versions, but not all versions are released •  Some)mes, releases may be developed in parallel due to time to

market

•  Examples –  Test release –  Staging release –  Product release


Tags naming releases

1.1

1.2

1.3

1.4

1.5

HelloWorld.java

1.1

1.2

1.3

1.4

1.5

Welcome.java

1.1

1.2

build.xml

1.1

1.2

1.3

User.java

1.0.0

1.0.1

1.1.0

1.6

Tags

HEAD


Branches

•  Versions that deviate from the main development line

•  Allow isola)on to the development process –  Usually reintegrated to the main development line

–  The reintegra)on some)mes is a difficult process

•  Workspaces (CVCS) can be seen as a temporary branch

•  Clones (DVCS) can be seen as repository forks that may

lead to branches if parallel development occurs


Branch example

1.2

HelloWorld.java

1.2

Welcome.java

1.1

build.xml

1.1

Users.java

1.0.0

Tag

1.0.x

1.2.2.1 1.2.2.1 1.1.2.1 1.1.2.1

Branch

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


Merge •  Help on reintegra)ng

–  Workspaces –  Branches

•  It is necessary even when pessimis)c concurrency control (lock) is in place, due to branches

•  Automa)c algorithms categories –  Generic (work with all programming languages) –  Language Specific (take into considera)on the syntax and seman)cs of the programming language)


Merge •  Types of generic merge algorithms

–  2-‐way merge –  3-‐way merge

X Y Z

W Y

X or W? Y

Z or nothing?

X Y Z

W Y

X Y

W Y Z


Merge

1.1 1.2 1.3 1.4 1.5 HelloWorld.java

1.2.2.1 1.2.2.2

Δ2

Δ1

1.6

1.6 = 1.2 + Δ1 + Δ2

•  Merge occurs for each CI in the branch •  All changes since the common ancestor are taken into

considera)on


Merge

1.2 1.3 1.4 1.5

HelloWorld.java

1.2.2.1 1.2.2.2

Δ2

Δ1

1.6

•  Merge can be done incrementally

1.7 1.8

Δ3

1.2.2.3 1.2.2.4

Δ4


Merge

1.2 1.3 1.4 1.5

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

•  Merge can be done incrementally


Conflicts •  Situa)ons where it is not possible to perform automa)c

merge •  Types

–  Physical (line of a file) –  Syntac)c (elements of the file grammar) –  Seman)c (dependencies among elements)

•  Current tool support focus on the physical level! •  Examples of physical conflicts

–  Parallel change in the same line –  Parallel change and dele)on of the same line –  Parallel addi)ons of lines in the same file region


Raw conflict demarca)on


IDE conflict resolu)on

Configura)on Management Founda)ons

Leonardo Gresta Paulino Murta [email protected]

conﬁguraon* management foundaons*leomurta/courses/2017.1/gc/aula3.pdfleonardo*murta*...

Documents

conﬁguraon* management foundaonsleomurta/courses/2017.1/gc/aula3.pdfleonardomurta*...