It's "funny" that for a deployment system, its own deployment follows all this crappy standards people have been running by lately.
Config in $HOME, startup with a random shell script, install is a compilation of python/bash/etc scripts that do magic, ... I mean look at this: https://github.com/spinnaker/spinnaker/blob/master/gradlew#L... (or actually, read the whole script, be scared)
Software nowadays.. a bunch of shell scripts with hacks all over which few actually knows how to write :/ (writing bash scripts well does take quite a bit of knowledge)
/rant over, send me your downvotes.
The linked script is just a standard bootstrap script, used by Gradle - I won't defend the logic behind it (they have a page for that themselves: https://docs.gradle.org/current/userguide/gradle_wrapper.htm...), but you can see the same thing in just about any project's Autotools files (see https://github.com/ruby/ruby/blob/trunk/aclocal.m4)
I'm increasingly frustrated by the discovery of major projects where this sort of "spaghetti code" is considered acceptable. Few of them deem it a priority to remediate or even just document the mess. Of particular note is the lineage of build system scripts used by first Gentoo then mutated by the chromeos team, finally used by and dramatically simplified by the coreos team who forked off from the chromeos fully and are cleaning up the mess left by the chromeos team hacking away on these bash scripts. There are dozens of places where simple hash bang python scripts would have cleaned up hundreds of lines of bash boilerplate.
I'm incredibly frustrated by the lack of willingness to decide that the outcome is key and the build scripts should be a testable part of the release process and a growing number of places I find have wound up considering the build scripts part of their release tests therefore they should change as infrequently as possible.
Not even going to start talking about programs that don't have stand alone build/install instructions because they always generate builds inside some kind of harness like a Debian or RPM source package.
(disclaimer: I am arguing about this specific case, not about such code smells in general)
UPDATE: ...and if I missed something besides that the code is repeated, please correct me. Bash is not my strong point.
http://spinnaker.io/documentation/getting_started.html
install the thing that's going to manage your whole deployment pipeline by curling a bash script from the 'net?
that said, and maybe i can answer my own question... OpsWorks has been a grand pain in the ass, so new options even built on AWS come welcome.
You can basically do all of this in Jenkins today, but you don't have the fancy GUI, that's my impression so far.
It now makes sense why they stepped away from the Job DSL Jenkins plugin that they helped create a while back (though there's still support for Jenkins steps in there which'll be a great help with porting existing pipelines).
Jenkins is also a first class stage type - it is the way we run the build and test side of our deployments
Also largely written in Groovy / Spring Boot. http://www.groovy-lang.org
Our deployments were already using ELBs and we wanted to stay with that.
Does anyone know if this has changed with Spinnaker?
I would not be surprised if Spinnaker's canary/etc. features require finer-grained control over the traffic than an ELB with just course-grained "add/remove instance" gives you, so it probably makes sense.
