Quellcode-Verwaltung

Es hat lange gedauert. Bisher habe ich keinen Grund gesehen mit einem eigenen Account / Profil bei Github vertreten zu sein. Meine bisherigen Projekte habe ich lieber in meinem eigenen (Subversion) Repository verwaltet. Ansonsten gab es keinen Grund Quellcode zu teilen.

In anderen Beiträgen habe ich das Projekt-Managementsystem Redmine bereits kurz vorgestellt und auf die Möglichkeit zur Integration von Redmine in eclipse mittels des Redmine-Mylyn Connectors hingewiesen. Jetzt ist es an der Zeit die praktische Arbeit mit dem System zu beschreiben.

Wer jetzt eine umfangreiche Einführung in Redmine erwartet, wird enttäuscht werden. Für eine grundlegende Einführung in die Nutzung von Redmine möchte ich auf den Remine guide verweisen. Eine gute Einführung gibt auch das Kapitel 6 des Buches „Konfigurationsmanagement mit Subversion, Maven und Redmine“ von Gunther Popp.

Ich werde im Folgenden Hinweise auf die Nutzung von Redmine aus meiner eigenen Praxis geben. Daher wird dieser Artikel in Zukunft auch laufend ergänzt und aktualisiert werden.

Der Einsatz einer Quellcode-Verwaltung (cvs, Subversion, etc.) ist für uns bereits seit Jahren selbstverständlich. Änderungen können über mehrere Versionen hinweg nachvollzogen und bei Bedarf wieder rückgängig gemacht werden. Nicht mehr benötigter Code wird nicht auskommentiert sondern wirklich gelöscht. In der Quellcode-Verwaltung ist der "alte" Code ja immer noch vorhanden.

Wie aber verwaltet man die ToDos, die während der Entwicklung einer Software für jeden Entwickler entstehen? Notizzettel? Text-Datei? Wiki? Alles Lösungen, die wir genutzt haben, von denen aber keine wirklich gut funktioniert hat. Mit den ersten Testversionen kommen noch Bug-Reports von den Testern hinzu. Und dann gibt es weitere Informationen, die jedem Entwickler schell zur Verfügung stehen sollten: fachliche und technische Richtlinien, Spezifikationen, Besprechungs-Protokolle, HowTos, etc.