ALM und dezentrales SCM – Die Quadratur des Kreises?

ALM und dezentrales SCM – Die Quadratur des Kreises?

© Zühlke 2010

28. Oktober 2010

Dr. Klaus Alfert Torben Knerr

Folie 1


ALMconf 2010


© Zühlke 2010

28. Oktober 2010


Folie 2

Viele Open-Source Projekte wechseln zur Zeit ihre Versionsverwaltung. Warum?

http://blog.kayloos.dk/wp-content/uploads/2010/01/rails.png

http://de.wikipedia.org/w/index.php?title=Datei:Qt_%28Bibliothek%29_logo.svg&filetimestamp=20081228115452

http://www.debian.org/

http://www.debian.org/


© Zühlke 2010

28. Oktober 2010


Folie 3

Der Industrie-Standard: Zentrale Versionskontrolle

SVN

CVS

perforce VSS

TFS

ClearCase

MKS Integrity

Harvest

Dimensions

Team Concert

PVCS

RCS SCCS

Depot


© Zühlke 2010

28. Oktober 2010


Folie 4


Repository

Zentral


© Zühlke 2010

28. Oktober 2010


Folie 4


commit

checkout

Repository

Working Copy

Zentral


© Zühlke 2010

28. Oktober 2010


Folie 4


commit

update checkout

Repository

Working Copy

Working Copy

branch

Zentral


© Zühlke 2010

28. Oktober 2010


Folie 4


commit

update checkout merge

Repository

Working Copy

Working Copy

Working Copy

branch commit

Zentral

Optimistisch? Pessimistisch?


© Zühlke 2010

28. Oktober 2010


Folie 5

Dezentrale Versionskontrolle

Die neumodische Variante

git

Bazaar

Darcs Mercurial (hg)

BitKeeper


© Zühlke 2010

28. Oktober 2010


Folie 6

Dezentrale Versionskontrolle (1) Ein Entwickler – ein Repository

Dezentral, 1:1

Repository


© Zühlke 2010

28. Oktober 2010


Folie 6


Dezentral, 1:1

clone

Repository A

Working Copy

Repository


© Zühlke 2010

28. Oktober 2010


Folie 6


Dezentral, 1:1

clone

commit

branch

merge Repository A

Working Copy

Repository

log


© Zühlke 2010

28. Oktober 2010


Folie 6


Dezentral, 1:1

clone

commit

branch

merge Repository A

Working Copy

Repository

push

log


© Zühlke 2010

28. Oktober 2010


Folie 7

Dezentrale Versionskontrolle (2) Mehrere Entwickler – ein gemeinsames Repository

Dezentral, 1:N

Repository A

Working Copy

Repository


© Zühlke 2010

28. Oktober 2010


Folie 7


Dezentral, 1:N

Repository A

Working Copy

Repository

Repository B

Working Copy

clone


© Zühlke 2010

28. Oktober 2010


Folie 7


Dezentral, 1:N

commit

branch

merge Repository A

Working Copy

Repository

Repository B

Working Copy

log

clone


© Zühlke 2010

28. Oktober 2010


Folie 7


Dezentral, 1:N

pull

commit

branch

merge Repository A

Working Copy

Repository

Repository B

Working Copy

push

log

clone


© Zühlke 2010

28. Oktober 2010


Folie 8

Dezentrale Versionskontrolle (3) Mehrere Entwickler – mehrere Repositories

Dezentral, M:N

Repository A

Working Copy

Repository

Repository B

Working Copy


© Zühlke 2010

28. Oktober 2010


Folie 8


Dezentral, M:N

Repository A

Working Copy

Repository

Repository B

Working Copy

push

pull


© Zühlke 2010

28. Oktober 2010


Folie 8


Dezentral, M:N

Repository A

Working Copy

Repository Repository

Repository B

Working Copy

init push

pull

push


© Zühlke 2010

28. Oktober 2010


Folie 8


Dezentral, M:N

clone

Repository A

Working Copy

Repository Repository

Repository C Repository B

Working Copy

Working Copy

pull

init push

pull

push


© Zühlke 2010

28. Oktober 2010


Folie 8


Dezentral, M:N

clone

commit

branch

merge Repository A

Working Copy

Repository Repository Repository

Repository C Repository B

Working Copy

Working Copy

push

log

pull

init push

pull

push


© Zühlke 2010

28. Oktober 2010


Folie 9

Dezentrale Versionskontrolle – Warum will ich das?

Fast alle Operationen sind lokal – Extrem schnell – Offline-Arbeiten – Feingranulare Commits

Jeder hat eine Kopie des Repositories – Backups – Komplette Historie (GUIDs vs. Counter)

Branching/Merging an der Tagesordnung – Branching ist schnell – Merging ist einfach

Kein zentrales Repository notwendig – Alle Repositories sind gleichberechtigt – Jeder kann von jedem „klonen“


© Zühlke 2010

28. Oktober 2010


Folie 10

Das große Risiko: Unbeherrschbare Strukturen…

Repository

WorkingCopy

WorkingCopy

Repository

WorkingCopy

WorkingCopy

Repository

WorkingCopy

WorkingCopy

Repository

WorkingCopy

WorkingCopy

Repository

WorkingCopy

WorkingCopy

Repository

WorkingCopy

WorkingCopy


© Zühlke 2010

28. Oktober 2010


Folie 11

Organisation und technische Kontrolle

Wie organisieren sich Open Source Projekte?


© Zühlke 2010

28. Oktober 2010


Folie 12

Organisation von Repositories und Workflows (1)

Kleinere OS Projekte

Maintainer

Contributor


© Zühlke 2010

28. Oktober 2010


Folie 13


Integration Manager Workflow

Integration Repository

Entwickler

Integrator


© Zühlke 2010

28. Oktober 2010


Folie 13



push push


Entwickler

Integrator


© Zühlke 2010

28. Oktober 2010


Folie 13



push push

pull

pull


Entwickler

Integrator


© Zühlke 2010

28. Oktober 2010


Folie 13



push

push push

pull

pull


Entwickler

Integrator


© Zühlke 2010

28. Oktober 2010


Folie 13



push

push push

pull

pull pull pull


Entwickler

Integrator


© Zühlke 2010

28. Oktober 2010


Folie 14


Größere OS Projekte

Maintainer

Committer

Contributor


© Zühlke 2010

28. Oktober 2010


Folie 15



Entwickler

Leutnant

Diktator

Diktator und Leutnant Workflow


© Zühlke 2010

28. Oktober 2010


Folie 15



Entwickler

Leutnant

Diktator


push push push push


© Zühlke 2010

28. Oktober 2010


Folie 15



Entwickler

Leutnant

Diktator


pull pull

push push push push


© Zühlke 2010

28. Oktober 2010


Folie 15



Entwickler

Leutnant

Diktator


pull pull

push push

push push push push


© Zühlke 2010

28. Oktober 2010


Folie 15



Entwickler

Leutnant

Diktator


pull pull

pull

push push

push push push push


© Zühlke 2010

28. Oktober 2010


Folie 15



Entwickler

Leutnant

Diktator


pull pull

pull

push

push push

push push push push


© Zühlke 2010

28. Oktober 2010


Folie 15



Entwickler

Leutnant

Diktator


pull pull

pull

push

pull pull pull

push push

pull


© Zühlke 2010

28. Oktober 2010


Folie 17

Die Organisationen von OS Projekten und Unternhemen sind strukturell ähnlich Rollen heißen anders, machen aber ähnliches

Integrator

Release Manager, Chef-Architekt

Entwickler


© Zühlke 2010

28. Oktober 2010


Folie 18

Repositories ersetzen Branches

Zentralisierte Verwaltung kann dezentral in anderen Kategorien gehalten werden

• Integration Branches Integration Repositories

• Team/Features Branches Team Repositories Feature Branches innerhalb der Repositories

• Release Branches Release Repositories

Die Nutzer sehen innerhalb ihrer Repositories nur die Branches, die für ihren Kontext relevant sind.


© Zühlke 2010

28. Oktober 2010


Folie 19

In großen Systemen werden zentrale Branchstrukturen schnell unübersichtlich

MSR1200

MUR1200S00

RTM1200S00U00

Gleichzeitigangelegt

Bran

ch

Bran

ch

StabilisierungRelease 12.0.0.0

Release 12.0.0.0

RI

RI

Bran

ch

Bran

ch


Release 12.0.1.0

RI

RI

MUR1200S01

RTM1200S01U00


R/O R/O

Bran

ch

RTM1200S01U00P42

Kundenspezifischer Patch. Integration

nicht zwingend erforderlich!

Bran

ch

MAIN

FI RIRI

MSR1201

MUR1201S00

RTM1201S00U00


Bran

ch

Bran

ch


Release 12.1.0.0

RI

RI

R/O

Bran

ch

RI

RTM1201S00U01

Bran

ch


Release 12.1.0.1

RI

R/O

RI

RI

CM

En

twic

klu

ng

Reife für R12.0 erreicht

Reife für R12.1 erreicht

Bran

ch

I1500

FI RI

Stabilisierung

FI RI

Stabilisierung

Bran

ch

I1500_TCOMM

RI

Stabilisierung

FI RI

Stabilisierung

FI

Bran

ch

I1501

FI RI

Stabilisierung

Bran

ch

I1501_TCOMMU01

Bran

ch

I1501_TCOMMU42

FI RI

Stabilisierung

FI RI

Stabilisierung

Bran

ch

I1501_TCOMMU42_WXYZ

RI

Stabilisierung

FI

BM

Baseless Merge:Möglich, aber nicht zu empfehlen!

Bran

ch

I1501_TCOMMD23

RI

Stabilisierung

FI

Next generation:Parallel-Entwicklung

zu Stabilisierungs-Phase

Entwicklung Patch-Release 12.0.1.0-42

R/O

Release 12.0.1.0-42

RI

RI

RI

FI FI

FI

IHSP_

FI RI

Stabilisierung

RTM1201HSP23

FertigstellungHSP Release 23

HSP Release 23

Reife für HSP Release 23 erreicht

Bran

ch

R/O

FI FI

Bran

ch

I1501_TCOMMU23

RTM1201S00U02

Bran

ch


Release 12.1.0.2

RI

R/O

RI

RI

FIFI

Jede Branchfärbung kann zu einer Kategorie von Repositories werden Schlankere Arbeitsmittel


© Zühlke 2010

28. Oktober 2010


Folie 20

Geografisch verteilte Entwicklung ist heute bei OS und der Industrie der Regelfall

Klassische Lösung:

• Proxies, um Latenzen beim Lesen zu reduzieren

• Schreibzugriffe in der Regel auf den zentralen Server

Dezentral: Entkoppelte Repositories

• Schneller lokaler Lese- und Schreibzugriff

• Expliziter Datenaustausch mit anderen Repositories als Prozesselemente der Zusammenarbeit


© Zühlke 2010

28. Oktober 2010


Folie 21

Skalierung: Am Linuxkernel arbeiten einige tausend Entwickler

Fakten aus dem Linux-Repository von Linus Torvalds (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git)

Clone-Kommando:

• Überträgt 360MB, Dauer: ca. 6 Minuten

Working-Copy:

• 370MB, 34.285 Dateien, 2.083 Ordner

Lokales Repository (.git-Verzeichnis):

• 409 MB, 23 Dateien, 13 Ordner

• 211.535 Commits, 7.076 Committer (seit 16.04.2005)

• Kompletter(!) Short-Log über alle Commits: 10sec


© Zühlke 2010

28. Oktober 2010


Folie 22

Wann kann man Dezentrales SCM einsetzen?

Bestehende SCM-Organisationen müssen ihre Prozesse und Organisation anpassen.

Je zentralistischer und regulierter die bisherigen Organisation, um so größer ist der Anpassungsaufwand (Tool vs. Organisation).

Zentrales SCM Dezentrales SCM

Command & Control Management-Stil

Team-orientierter Management-Stil


© Zühlke 2010

28. Oktober 2010


Folie 23

Achtung: Conway’s Law

“Organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations.”


© Zühlke 2010

28. Oktober 2010


Folie 25

Die Toolfrage – Das Runde muss in das Eckige… (1)

Unabhängig von der Versionsverwaltung

• Issue Tracking

• Requirements Management

• Test Management

Abhängig von der Versionsverwaltung

• Versionskontrolle

• (De-) Central Build

• Continuous Integration

• Release Management

Aber statt auf Branches jetzt auf den Repositories des DSCM


© Zühlke 2010

28. Oktober 2010


Folie 26

Die Toolfrage – Das Runde muss in das Eckige… (2)

Integration und Verknüpfung der Informationsquellen

• Wie hängen Issues, Checkins, Builds & Testläufe zusammen?

Prozess-spezifische Lösungen notwendig

• Eineindeutige Commit-IDs durch GUID (SHA1)

• Checkin-Kommentare und Commit-IDs werden über Repositories hinweg weitergereicht

Basis für kreative Lösungen ist vorhanden!


© Zühlke 2010

28. Oktober 2010


Folie 27

Zusammenfassung

In der Open-Source Szene tut sich viel Spannendes im Bereich dezentrales SCM durch git und andere.

Dezentrales SCM ist inzwischen soweit, dass man es professionell einsetzen kann.

Der Mehrwert ist:

• Die Entwickler können spürbar schneller arbeiten: Alle aufwändigen SCM-Operationen sind lokal

• Skalierung auch über segmentierte Netzwerkanbindung möglich (u.a. geogr. Verteilung)

• Flexible Topologien von streng hierarchisch bis massiv kollaborativ möglich


© Zühlke 2010

28. Oktober 2010


Folie 28

Fazit

Wenn dezentrales SCM zu Ihrer Organisation passt, nutzen Sie es – nicht nur Ihre Entwickler werden es Ihnen danken!

Vielen Dank! Und lassen Sie uns hier weiter diskutieren:

Torben Knerr

[email protected]

@tknerr_de

http://linkedin.com/in/tknerr

http://xing.to/tknerr

Dr. Klaus Alfert

[email protected]

@innovation_code

http://linkedin.com/in/KlausAlfert

http://xing.to/alfert

http://linkedin.com/in/tknerr

http://xing.to/tknerr

https://twitter.com/tknerr_de

mailto:[email protected]

http://linkedin.com/in/KlausAlfert



https://twitter.com/innovation_code

mailto:[email protected]

ALM und dezentrales SCM – Die Quadratur des Kreises?

Software

Transcript of ALM und dezentrales SCM – Die Quadratur des Kreises?