(...) 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:
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
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 (...)
