VSTS im Einsatz: Sourcen im Griff - JAXenter

VSTS im Einsatz: Sourcen im Griff

(…) Bis zum Check-In werden alle Änderungen
als Pending Change, also als noch
ausstehende Veränderung behandelt. Dies
hat einen sehr angenehmen Effekt: Das Ergebnis
jeder Aktion kann in Ruhe bewertet
werden, es können Solutions gebaut oder
Unit Tests durchgeführt werden. Erst wenn
man sich sicher ist, dass alles so funktioniert,
wie man es sich wünscht, checkt man
die Änderungen ein und aus einer Pending
Change wird eine neue Version innerhalb
der Source Control. Mit Undo Pending
Changes
kann man alle noch nicht eingecheckten
Änderungen wieder rückgängig
machen.

Um immer alles im Auge zu behalten,
wurde den Pending Changes ein eigenes
Fenster gewidmet, dass immer die aktuelle
Liste aller bereits veränderten Dateien anzeigt.
Anders als bei Visual Source Safe sind
Check-Ins bei Team System atomare Operationen.
Dies stellt sicher, dass bei einem
Check-In auch tatsächlich alle Dateien
zeitgleich eingecheckt werden können. Da
der Check-In innerhalb einer Transaktion
stattfindet, wird bei einem Fehler automatisch
ein Rollback durchgeführt und somit
keine einzige Datei eingecheckt. Nach der
Behebung des Fehlers kann man es dann
erneut versuchen. Inkonsistente Stände in
der Quelltextverwaltung werden so vermieden.

Die Rolle der Changesets

Alle Dateien, die innerhalb einer Transaktion
eingecheckt werden, fasst Source
Control zu einem sog. Changeset zusammen.
Changesets sind ein neuer Ansatz,
um ein besseres Verständnis für die ständigen
Veränderungen von Software zu
schaffen. Durch ihre Einführung kann
effizient nachvollzogen werden, welche
gleichzeitigen Änderungen am Code stattgefunden
haben. Durch einen Kommentar
und durch das Verknüpfen von Work
Items mit einem Changeset, wird aus ihm
eine logische Einheit, die den Zusammenhang
von Arbeitsauftrag und Ergebnis verbindet.
Hierzu ein Beispiel: Während eines
Tests werden mehrere Fehler in der aktuellen
Version einer Software entdeckt. Für
jeden der gefundenen Fehler wird ein Bug
Work Item in Team System erzeugt. Diese
werden anschließend einzelnen Entwicklern
zugewiesen, die sie anhand der mitgelieferten
Beschreibung beheben sollen.
Nachdem ein Entwickler die Fehlerquelle
eines Bugs lokalisiert und den Fehler behoben
hat, checkt er seine hiefür gemachten
Codeänderungen ein. Mit dem so erzeugten
Changeset verlinkt er das ihm zugewiesene
Work Item und weist dieses anschließend
einem andern Kollegen zum Test
zu. Über den Bug und seine Verlinkung mit
dem Changeset kennt der Kollege alle Dateien,
die vom Entwickler verändert wurden
und kann mit dieser Information testen,
ob der Fehler erfolgreich behoben wurde
und ob eventuell neue Fehler eingebaut
wurden.

Changesets verfügen über eine eindeutige
ID, eine Liste aller beteiligten Dateien,
das Datum des Check-Ins, den Namen des
Anwenders, der den Check-In durchgeführt
hat, einen Kommentar, zusätzliche Notizen
und die bereits erwähnten Verlinkungen zu
Work Items, wie es auch in Abbildung 4 zu
sehen ist:

Abb. 4: Ein Changeset mit allen darin enthaltenen Informationen
Check-In-Policies

Mit Team System soll das Bearbeiten von
Quellcode nicht nur effizienter werden,
auch an eine Verbesserung der Qualität des
entstehenden Codes wurde gedacht. Durch
das Aktivieren sog. Check-In-Policies ist es
möglich, bestimmte Kriterien an die Qualität
des entstehenden Codes zu stellen. Out
of the box stehen drei Policies zur Auswahl:
Code Analysis, Testing und Work Item Policy.
Mit dem Aktivieren der Code Analysis
Policy
werden vor jedem Check-In zwei
Dinge sichergestellt. Zum einen, dass sich
der Code mit den neuen Änderungen noch
übersetzen lässt, zum anderen wird geprüft,
ob der Code nicht gegen definierte Regeln
verstößt. Der zu Grunde liegende Regelsatz
entstammt den Microsoft Design Guidelines
für .NET und besteht aus einer Vielzahl
an Best Practices. Für jede einzelne,
aber auch ganze Gruppen, dieser Regeln
kann entschieden werden, ob ein Verstoß
eine Warnung oder sogar einen Fehler nach
sich zieht.

Hinter der statischen Codeanalyse steht
die Überzeugung, dass regelkonformer
Code auch weniger Fehler enthält. Neben
Namensvereinbarungen können
auch Performance und Sicherheitsrisiken
überprüft werden. Zu jedem gefundenen
Fehler gibt es eine Erklärung, die nicht nur
verdeutlicht, was falsch gemacht wurde,
sondern auch Tipps gibt, wie man es
besser machen kann. Sollte eine Stelle im
Code fälschlicher Weise bemängelt werden,
ist es durch einen einzigen Klick möglich,
an dieser Stelle die Warnungen bei
zukünftigen Analysen zu unterdrücken.

Mit der Unit Test Policy lässt sich erreichen,
dass vor jedem Check-In eine bestimmte
Auswahl an Unit Tests ausgeführt
wird. Voraussetzung ist in diesem Fall natürlich,
es gibt solche. Diese Policy verringert
das Risiko, dass gemachte Änderungen
bereits existierende Funktionalität
wieder zerstören. Falls ein Test hier fehlschlägt,
wird das Hinzufügen des Codes in
die Quelltextverwaltung verwehrt. Es ist
jedoch darauf zu achten, dass die verwendeten
Testlisten nicht zu lange dauernde
Unit Tests enthalten, da es sonst zu lästigen
Verzögerungen beim Check-In kommt.
Eine Beschränkung auf das Wesentliche
bringt hier den klaren Vorteil.

Was sich hinter der dritten Policy verbirgt,
wurde bereits am Beispiel der Changesets
erläutert. Ab einem bestimmten Zeitpunkt im Projekt, vor allem gegen Ende,
möchte man sicherstellen, dass keine unkontrollierten
Veränderungen am Code
vorgenommen werden können. Für jeden
Check-In wird die Verknüpfung mit mindestes
einem Work Item verlangt. Besonders
wenn in dieser Phase des Projektes ein
Build fehlschlägt, ist es hilfreich, wenn man
nicht nur weiß, welcher Code verändert
wurde, sondern auch die Absichten, die dahinter
standen. Für dringende Notfälle ist
ebenfalls gesorgt. In Ausnahmesituationen
können die Check-In-Policies nach Eingabe
eines Kommentars übergangen werden.

Check-Out und Lock-Types

Da es meist nicht bei einem Check-In am
Tag bleibt, soll es danach sofort wieder
weitergehen. Doch was, wenn ein Kollege
mal wieder schneller war und die am
dringendsten benötigte Datei bereits ausgecheckt
ist? Mit Team System kein Problem,
da das mehrfache Auschecken von
Dateien unterstützt wird. Wie Abbildung
5 zeigt, stehen beim Check-Out insgesamt
drei sog. Lock Types zur Auswahl:

  • None – andere dürfen die Datei ebenfalls
    nach belieben ein- und auschecken
  • Check Out – kein anderer darf die Datei
    auschecken
  • Check In – die Datei darf ausgecheckt,
    jedoch erst nach dem eigenen Check-In
    von anderen Benutzern wieder eingecheckt
    werden

Abb. 5 Beim Check-Out kann ein Lock Type den gemeinsamen Zugriff einschränken

Kommt es beim Hinzufügen von Quelltext
zu Konflikten, weil ein anderer Anwender
die gleiche Datei bearbeitet hat,
wird dies angezeigt. Die Behebung dieses
Konflikts wird durch Visual Studio unterstützt.
Wer sich nicht mit dem Gedanken
des parallelen (…)

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.