DVCS steht für Distributed Version Control System. DVCS ist nicht neu, aber es ist seit einigen Jahren noch stärker in Mode gekommen. Die beiden gängigsten Vertreter sind Mercurial (HG) und GIT. Zurzeit nutze ich für meine “Spiel”-Projekte Mercurial, da es unter Windows etwas angenehmer ist und BitBucket unbegrenzte (private) Repos zur Verfügung stellt.
Das Gute an DVCS ist, dass man sämtliche Informationen lokal hat und auch alle Interaktionen mit dem Repository lokal durchführt. Nur ab und an muss man sich mit dem “source” Repo verbinden und die Informationen updaten. Andere haben die Möglichkeit vom eigenen Repo eine komplett arbeitsfähige Kopie zu ziehen. Ich nutze am meisten lokale Branches und Commits (Reverts). Ich hatte leider einige mal Dateien vergessen einzuchecken (genau wie bei zentralen Repos). Ohne Continuous Integration (CI) Build merkt man das vermutlich erst, wenn man mal einen anderen Rechner nutzt. Bei zentralen Repos nutze ich eigentlich immer CI, bisher bei DVCS eher weniger. Nach vergessenen Dateien und der Frage, wie ich das abstellen kann, habe ich mich entschieden lokal zu integrieren.
Ich habe mein lokales DVCS Repo in einem Build-Server konfiguriert, so dass dieser einen Clone erzeugt und anschließend gegen die Version kompiliert. Später habe ich auch noch die Ausführung von Tests hinzugefügt. Mir ist dabei erst wieder aufgefallen, wie viel man beachtet, wenn man ein weiteres Feedback der Kompilierung erhält. Denn im Studio geht doch fast immer alles. Man kann das lokale CI noch verbessern, in dem man einen Remote-Build-Agent benutzt, so dass auch ggf. Abhängigkeiten zu VS.NET Installation oder anderer Software erkannt werden können. Seit einiger Zeit habe ich mir auch angewöhnt Unit-Tests zu schreiben, es wird immer leichter einen Test zu schreiben, leider vergesse ich aber öfters die Tests vor dem Checkin laufen zu lassen. Mein Build-Server nimmt mir diese Arbeit ebenfalls ab, so dass ich schnell merke, dass etwas nicht passt. Normalerweise sind die heutigen Rechner leistungsfähig genug und eine Software zügig zu kompilieren ohne, dass die Arbeit maßgeblich leidet. Ich werde in Zukunft, sofern ich mit DVCS arbeite, meinen lokalen Build Server nutzen. Aber noch ein weiterer Vorteil entsteht, Reproduzierbarkeit. Ich kann, sofern ich mal eine Version meines Codes zur Verfügung stelle, diese leicht noch einmal bereitstellen. Es ist nicht notwendig Dateien von Hand zusammen zu sammeln und an die richtigen Stellen für meine Auslieferung zu kopieren.
Ich bin ein riesiger Fan von CCNet und finde den Server für .NET einfach sehr schön. Allerdings gibt es einige Dinge, die mich (vermutlich eher andere) stören. So ist die Konfiguration nicht sehr intuitiv und erfordert schon etwas wissen. Zum Anpassen der Konfiguration muss man eigentlich immer das XML manipulieren und auf dem Server aktualisieren. Das war der Grund mich mal wieder umzuschauen und eine sehr schnell aufkommende alternative war TeamCity. Es ist für kleinere Build-Umgebungen, die man vermutlich lokal auch nur hat, kostenlos und ermöglicht in der Website relativ leicht die Konfiguration und Statusabfrage. Ich finde die Webseite des lokalen Build-Servers schick und übersichtlich, es wird viel Ajax genutzt um Informationen bereitzustellen.
In TeamCity kann man dem Build-Agent Bedingungen zuweisen die dieser Erfüllt und einer Build-Konfiguration Bedingungen, die erfüllt sein müssen um eine Integration auszuführen. Man kann sich auch einfach mittels verschiedener Kommunikationskanäle über den Status informieren lassen.
Keine Kommentare:
Kommentar veröffentlichen