Open Source im professionellen Einsatz

Darüber hinaus?

Bei allen hier vorgestellten Produkten steht letztlich der Kern des Software-Entwicklungsprozess im Mittelpunkt. Aber das reicht meist nicht. Ein Bugtracker etwa hat mit einem Buildsystem nur am Rande zu tun, ist aber gleichwohl ein unverzichtbarer Bestandteil des Software-Bauens. Ebenso sieht es aus mit dem Freigabeprozess, mit Anforderungsanalyse, Dokumentation und mit dem Auditing, zum Beispiel bezüglich Security oder Softwarestandards. Enterprise-Lösungen wie IBMs Jazz [18] versuchen hier die sprichwörtliche Eier legende Wollmilchsau zu bieten. Die Infrastrukturanforderungen für ein solches System sind immens, der Supportaufwand auch. So ein großes System rechnet sich – wenn überhaupt – nur langfristig.

Angesichts der Tatsache, dass die Verfahren und Tools der Software-Entwicklung immer einem regen Wandel unterworfen waren und sind, stellt sich die Frage, ob man überhaupt auf ein so hoch integriertes System setzen soll. Bis sich alle an der Entwicklung Beteiligten auf die neuen Werkzeuge eingestellt haben und die Prozesse sauber und effizient laufen, hat sich die Welt schon weitergedreht. Besser erscheinen kleinere, gut anpassbare Tools, die sich dank offener Schnittstellen an etablierte Systeme wie Mail, Bugtracker und so weiter einer Firma anschließen lassen.

Fazit

Buildtools und Buildsysteme gibt es passend zu jeder Projektgröße. Wer auf der grünen Wiese anfängt, sollte ein System wählen, das der absehbaren Komplexität und dem Umfang seines Projekts entspricht. Wer seine aktuelle Buildumgebung eher als Hemmschuh, nicht als produktivitätssteigernd empfindet, sollte umsteigen. Projektverantwortliche kommen dabei um Evaluierung und Abgleich an eigene Bedürfnisse nicht herum, da die Webseiten der hier vorgestellten Tools alle ein sehr gutes Marketing betreiben und jeweils Einfachheit, Flexibilität und Skalierung versprechen.

Wichtiger als ein möglichst großer Funktionsumfang oder ein möglichst kleines Makefile sind Offenheit, Schnittstellen, Stabilität und Verbreitung. Bei aller Tool-Unterstützung sollte klar sein, dass ein gutes Buildsystem kein Selbstläufer ist, sondern immer dedizierte Unterstützung von Fachleuten benötigt.

Infos

  1. Cmake: http://www.Cmake.org/
  2. Qmake: http://doc.trolltech.com/3.0/Qmake.html
  3. Maketools im Softwareverzeichnis der Free Software Foundation: http://directory.fsf.org/category/make/
  4. Open-Directory-Projekt: Buildtools http://www.dmoz.org/Computers/Software/Build_Management/Make_Tools/
  5. Scons: http://www.scons.org
  6. Cons: http://www.dsmit.com/cons/
  7. Maven: http://maven.apache.org
  8. Buildr: http://buildr.apache.org
  9. Ivy: http://ant.apache.org/ivy/
  10. Gradle: http://www.gradle.org
  11. Carsten Zerbst, "Am Ball bleiben": Linux-Magazin 07/10, S. 106
  12. Distcc: http://code.google.com/p/distcc/
  13. Buildbot: http://buildbot.net/trac
  14. Alternativen zu Buildbot: http://ci.apache.org
  15. Apaches Buildbot-Service: http://ci.apache.org/buildbot.html
  16. Open Suse Build Service: https://build.opensuse.org
  17. KDE GHNS: http://newstuff.kde.org
  18. IBMs Jazz-Projekt: http://www-01.ibm.com/software/de/rational/jazz/

Der Autor

Bernhard Bablok betreut bei der Allianz Shared Infrastructure Services ein großes Datawarehouse mit Performance-Messdaten von Mainframes bis zu Servern. Wenn er nicht Musik hört, mit dem Rad oder zu Fuß unterwegs ist, beschäftigt er sich mit Linux und Objektorientierung.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 7 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook