Spinnaker: Global Continuous Delivery by Netflix
spinnaker.io
spinnaker.io
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.
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?
(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.
Also largely written in Groovy / Spring Boot. http://www.groovy-lang.org
I didn't say that.
I just think it's unlikely they would have chosen the name if they were aware of Manchester's project, which means they didn't know about it, which means they don't read much about CS research.
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.
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).
This feels like a Jenkins replacement rather than a Jenkins plugin replacement or at least something that sits atop Jenkins in driving your build and deployment activities (it's got support to call and watch Jenkins jobs so it's sensible to assume they use both).
I'm interested to hear that JobDSL is painful for Jenkins masters do you know what the pain points are?
In a multi-tenant environment that we run using Enterprise Jenkins from CloudBees, the default option for JobDSL is to create jobs at the root level which is problematic if you don't allow teams at that level. We've also had issues with jobs just getting "stuck" which even after a restart of the master doesn't clear it out. Plus the fact that it encourages bad behavior among teams by allowing them to create thousands of jobs that never get cleaned up is just another reason we've banned it from other installations we've setup. Jenkins itself is pretty terrible and even the proposed 2.0 changes don't appear to do anything to change things for the better. If Spinnaker can replace Jenkins, more power to them. But I don't think that's the initial aim.
Regarding your other comment about "something that sits atop Jenkins in driving your build and deployment activities" that's just about exactly what the Workflow plugin ecosystem does. However you're still stuck with Jenkins and its baggage.
Jenkins is also a first class stage type - it is the way we run the build and test side of our deployments