In Teams, die dem "Collective-Code-Ownership"-Prinzip (http://c2.com/cgi/wiki?CollectiveCodeOwnership) folgen, soll es keinen Code geben, den nur eine Person versteht und somit de-facto nur er verändern oder verstehen kann. Jeder soll in der Lage sein, Code zu lesen und zu erweitern, und zwar ohne, dass sich jemand auf den Schlips getreten fühlt. Das ist natürlich eine Kulturfrage, aber auch eine Frage der benutzten Skript- oder Programmier-Sprachen. "Agile" und "Agilität" beginnt also womöglich schon bei der Wahl der Mittel. Darüber sollte man also auch mal nachdenken.
Deployment mit einem Java-Programm?
Eine Skriptsprache für Automatisierung ist wahrscheinlich immer besser geeignet als eine explizit kompilierte Sprache. Wiederkehrende Aufgaben wie Deployment, mit Skriptsprachen geschrieben, sind schneller anzupassen und einfach lesbarer als streng typisierte Sprachen.
Würde ein Binary aus dem Vorgang entstehen müsste auch der Build-Prozess für das Programm, das etwas automatisieren soll, erneut automatisiert werden. Es hätte einen größeren Entwicklungszyklus (http://www.tutorialspoint.com/softwareengineering/softwaredevelopmentlifecycle.htm).
Aber, auch Sprachen wie "Go" (https://golang.org) oder "Groovy" (http://www.groovy-lang.org), die Vorteile von Skriptsprachen in sich vereinen und dennoch ein Kompilat herausgeben, sind alleine wegen der Lesbarkeit besser für Automatisierung geeignet.
Als Beispiel: Gradle (http://gradle.org), als bekanntes Java-Buildsystem, muss auch nicht erst in ein Java-Projekt eingebaut und kompiliert werden. Gradle-Skripte werden in Groovy geschrieben, in-place angepasst, just-in-time gebaut und ausgeführt. Und das, obwohl Groovy ja Quasi-Java ist.
Reine Java-Programme, die einen Vorgang automatisieren, halte ich für sehr befremdlich.
