Programmierung
Versionen
Es soll noch Teams von Software-Entwicklern geben, die ohne ein Versionsverwaltungssystem auskommen und die Versionsverwaltung ihrer Projekte ganz von Hand durchführen. Dabei lohnt sich der Einsatz eines Systems für die Versionsverwaltung (en. version control system, VCS), auch Quellenverwaltung (en. source control management, SCM) genannt, immer, auch wenn die Projekte von geringem Umfang sind. Und bereits für einen einzelnen Entwickler bietet es unverzichtbare Funktionalität. Und auch für die Verwaltung der Versionen von Dateien in einem Kontext außerhalb der Entwicklung von Software, z.B. von Entwurfsquellen für Design- oder Architekturprojekte, ja sogar bei der Erstellung von umfangreichen strukturierten Texten, kann ein solches System sehr hilfreich sein. Natürlich gibt es einen Anfangsaufwand bei der Einführung und eine Lernkurve bezüglich des Umgangs mit dem Werkzeug – aber der Einsatz wird sicher bald mit einer Vereinfachung der Abläufe, Nachvollziehbarkeit von Ständen und geringerer Wahrscheinlichkeit von Fehlern belohnt.
Eine Versionsverwaltung protokolliert alle Änderungen, archiviert diese, ermöglicht die Kennzeichnung eines bestimmten Standes (einer auslieferbaren Version oder auch eines Zwischenstandes), die Wiederherstellung eines alten Standes einzelner Dateien oder eines ganzen Projektes, es koordiniert den gemeinsamen Zugriff von mehreren Mitarbeitern auf die Dateien eines Projektes und es unterstützt die gleichzeitige Entwicklung mehrerer Entwicklungszweige. Darüberhinaus bauen viele Werkzeuge auf einem Versionsverwaltungssystem auf, die wiederkehrende Arbeitsschritte bei der Software-Entwicklung durch Automatisierung erleichtern und Qualität und Reproduzierbarkeit der ausgelieferten Software verbessern sollen, wie z.B. Werkzeuge für die Ausführung von Tests, die Übersetzung, Herstellung und Verwaltung von Artefakten (Builds), sowie kontinuierliche Integration, also die automatische Durchführung dieser Abläufe in regelmäßigen Abständen (täglich oder mehrmals am Tag).
Dabei ist grundsätzlich zwischen Versionsverwaltungssystemen, bei denen das Versionsarchiv (en. repository) auf einem zentralen Server liegt, und verteilten Systemen zu unterscheiden. Die beiden verbreitesten quelloffenen Systeme, das 1990 erstmals erschienene CVS (Concurrent Versions System) und Subversion (abgekürzt Svn), das zehn Jahre später mit einigen Verbesserungen gegenüber CVS auf den Plan trat, gehören zur ersten Kategorie. Die ersten verteilten Versionsverwaltungen entstanden um 2000 herum. Die dezentrale Verwaltung der Versionen passt besser zur quelloffenen Entwicklung, bei der häufig Entwickler zusammenarbeiten, die sich an verschiedenen Standorten befinden, und besser zum Prinzip gleichberechtigter Knoten im Internet. Die beiden am häufigsten eingesetzten verteilten Versionsverwaltungen sind Git und Mercurial (die beide 2005 erstmals vorgestellt wurden). Der erste Schritt zu einem Versionsverwaltungssystem ist also herauszufinden, welches am besten zu den eigenen Anforderungen passt. Bei einem zentralen System muss ein dedizierter Server aufgesetzt werden, was bei einem verteilten Systeme entfallen kann – allerdings wird auch hier meistens ein allgemein zugängliches Archiv wünschenswert sein. Anleitungen und Tutorien im Internet erleichtern den Einstieg, sodass man schon bald einfach „loslegen” kann. Allerdings wird das neue Werkzeug, sowenig wie andere Software, von selbst kein Chaos beseitigen oder vermeiden. Es ist notwendig, sich auf grundlegende Strukturen zu einigen, den Aufbau des Verzeichnisbaums eines Projektes, in welchem die verschiedenen Dateien abgelegt werden. Und nichtzuletzt muss das System organisatorisch integriert werden, es sollten also zumindest grobe Abläufe vereinbart werden.