In dieser Artikelserie möchte ich aufzeigen, was man benötigt um eine (meiner Meinung nach) professionelle Entwicklungsinfrastruktur aufzusetzen. Nun, wahrscheinlich hat jeder so seine eigenen Vorstellungen davon, was unter professionell zu verstehen ist. Gut möglich auch, dass einiges was der eine als professionell auffasst, der andere als unnötig oder übetrieben erachtet. Nichtsdestotrotz gibt es wohl den einen oder anderen Stützpfeiler in der Software-Entwicklung, der sich etabliert und eine gewisse Daseinsberechtigung erarbeitet hat.
Was ist also eine professionelle Entwicklungsinfrastruktur bzw. welche Ziele sollten bei der Einrichtung einer solchen verfolgt werden?
- Geht es einfach darum dem Entwickler Freude zu bereiten, ihm ein "gutes Gefühl" zu vermitteln?
- Dem Projektleiter und Kunden ein Gefühl von Sicherheit zu vermitteln?
- Oder einfach nur das Projekt rechtzeitig und gemäss Anforderungen abzuschliessen?
Richtig - idealerweise werden alle diese Punkte (und noch einige weitere) erreicht.
Eine gut funktionierende und unterstützende Infrastruktur ist zwar nicht die Garantie für all das, aber zumindest bietet sie einem das Werkzeug und die Hilfsmittel, diese Ziele zu erreichen.
Ich werde in diesem Artikel einen Überblick über die Komponenten aufzeigen, die aus meiner Sicht in eine Entwicklungsinfrastruktur gehören - also nicht "wäre noch nett"-Komponenten, sondern "ohne die mach ich keinen Fingerzeig"-Komponenten. Die nächsten Artikel werden dann jeweils detaillierter auf die einzelnen Komponenten eingehen. Die vorgestellten Tools habe ich dabei rein subjektiv ausgewählt. Wer bessere oder einfach andere Altnernativen bzw. Ergänzungen hat, ist angehalten diese per Kommentar mitzuteilen.
Die IDE
"An integrated development environment (IDE), also known as integrated design environment and integrated debugging environment, is a type of computer software that assists computer programmers in developing software." (Wikipedia)
Die IDE (=Integrated Development Environment) ist wohl das Tool, womit die meisten von uns am meisten Zeit verbringen. Und doch ist es für die Erreichung unserer Ziele wahrscheinlich das unkritischste von allen. Ob der Entwickler nun mit einer "echten" IDE wie VS 2005 oder einfach nur mit einem simplen Texteditor wie Notepad arbeitet, ist letztendlich seinen Angewohnheiten und Vorlieben überlassen. Für das Projektresultat ist die Wahl der IDE bzw. des Editors also insofern wichtig, dass der Entwickler mit seiner IDE quasi harmoniert und sie auch handhaben kann.
Vertreter dieser Kategorie: Visual Studio, SharpDevelop, Eclipse, IntelliJ, JBoss, etc.
In dieser Serie werde ich Visual Studio 2005 TS einsetzen.
Der Artikel zur IDE wird sich auf die Entwicklung von UnitTests mit VS 2005 beschränken.
Versionskontrolle
"Revision control (also known as version control (system) (VCS), source control or (source) code management (SCM)) is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code, art resources such as blueprints or electronic models and other critical information that may be worked on by a team of people." (Wikipedia)
Die SCC ist ein absolutes Muss für jeden der auch nur halbwegs professionell Software entwickelt. Erfreulicherweise ist der Einsatz eines entsprechenden Systems auch die Regel - aber leider bestätigen natürlich auch hier die Ausnahmen selbige. Eine gute SCC bietet neben des impliziten BackUps der lokalen Kopie, vorallem auch den Vorteil der Versionierung. Weiter sollte es möglich sein, Source Code auf verschiedenen Zweigen (= Branches) voranzutreiben bzw. Tags oder Labels vom Code zu erstellen. Was das genau ist und wie man damit umgeht, wird in Teil 3 dieser Serie besprochen.
SCC-Systeme werden meist mit Diff- und Merging-Tools ergänzt, da dies natürlich Funktionalitäten sind, die sich bei der täglichen Arbeit mit einer SCC notwendigerweise ergeben.
Die Wahl der SCC ist auch hier eher unbedeutend und sollte halt einfach die jeweiligen Bedürfnisse und Vorlieben abdecken.
Auch hier, einige Vertreter dieser Kategorie: CVS, Subversion, Visual SourceSafe, Sourcegear Vault
In der Serie wird Subversion eingesetzt.
Build-Script
Build automation is the act of scripting or automating the process of compiling computer source code into binary code. This automated build is in contrast to a manual build process where a person has to perform multiple, often tedious and error prone tasks. (Wikipedia)
Ein Build-Script ist keine eigentliche Software-Komponente, sondern halt nur ein Script. Was das Script dann schlussendlich tun soll, ist abhängig von den Wünschen und Anforderungen der Projektteilnehmer. Was es aber grundsätzlich natürlich immer kann bzw. können sollte, ist das schlichte kompilieren des Codes. Als erweiterte Möglichkeiten wären zum Beispiel folgende Punkte denkbar:
- Erstellung der Datenbank
- IIS Automatisierung (virt. Directories erstellen, Konfigurationen vornehmen etc.)
- Umgebungsabhängige Konfigurations-Dateien erstellen (Stichwort: ConnectionString)
- Automatisierte Test-Durchführung (z.B. UnitTests)
- SCC-Operationen
- und und und...
Seit .NET 2.0 haben .NET Entwickler die grosse Erleichterung, dass jedes Solution- bzw. Projektfile von Visual Studio 2005 selbst bereits ein MSBuild-Skript darstellt, welches zumindest mal die Solution oder das Projekt durch einen simplen Kommandozeilen-Aufruf von "msbuild mysolution.sln" kompilieren kann. Damit ist bereits die wichtigste Funktion eines BuildScripts abgedeckt, mit der auch schon einiges erreicht werden kann (z.B. automatische Kompilierung über Scheduled Tasks).
Vertreter dieser Kategorie sind zum Beispiel das eben genannte MSBuild, (n)ant oder auch die klassischen make-Files.
In dieser Serie werden wir auf MSBuild setzen.
Build-Server / Continuous Integration Server
"Continuous integration is the name that emerged in the Extreme Programming community for the software engineering practice of immediately committing every change, no matter how small, to a revision control system. Other developers should always work with the latest version of the codebase." (Wikipedia)
Build-Server im eigentlichen Sinne sind eigentlich heutzutage recht out.In aller Munde hingegen ist Continuous Integration oder kurz CI. Wo genau die Unterschiede sind, wird im entsprechenden Artikel behandelt - wobei der Schwerpunkt klar auf CI-Servern gelegt wird.
Vertreter dieser Kategorie sind Cruise Control (.NET), Team Foundation Server, TeamCity, Bamboo
Wir werden uns mit Cruise Control .NET beschäftigen.
Dies war mal so ein kleiner Überblick über die Themen dieser Serie. Jeder der folgenden Artikel wird dann ein einzelnes dieser Themengebiete genauer beleuchten.
Um nochmals auf die eingangs erwähnten Fragestellungen zurückzukommen:
- Geht es einfach darum dem Entwickler Freude zu bereiten, ihm ein "gutes Gefühl" zu vermitteln?
Der Entwickler wird automatisch ein gutes Gefühl erhalten. Automatisch ausgeführte Builds, Tests etc. werden ihm stets das Gefühl verleihen, dass das Programm auf gutem Weg ist. Allein schon die morgendliche Nachricht, dass der Nightlybuild ohne Fehler durchgelaufen ist, wirkt hier Wunder. Im Artikel über CI werden wir aber noch einiges weiter gehen (Nightlybuilds != CI) - Dem Projektleiter und Kunden ein Gefühl von Sicherheit zu vermitteln?
Durch den Einsatz von CI können wir ein stets lauffähiges System vorweisen (das heisst nicht das alle Funktionen bereits vollständig implementiert sind etc.). Es gibt doch nichts Schlimmeres, als wenn der Kunde etwas sehen möchte und der Entwickler ihn mit lauter kryptischen (aber im Entwicklungsprozess) normalen Fehlermeldungen konfrontiert. - Oder einfach nur das Projekt rechtzeitig und gemäss Anforderungen abzuschliessen?
Hierfür brauchts natürlich noch einiges mehr, als eine gute Infrastruktur - aber ein erster Schritt ist damit getan.
Alle verwendeten Komponenten bis auf Visual Studio sind frei erhältlich, der Kostenpunkt sollte also zumindest was die Lizenzkosten anbelangt keinen Grund darstellen, auf diese wichtigen Komponenten zu verzichten - wie es mit dem Aufwand aussieht, werden die nächsten Artikel zeigen.