I'm interested in seeing how tight security requirements fit in with this almost continuous deployment strategy.
: http://www.etsy.com, the world's marketplace for handmade and vintage goods.
We also have regular audits with external security firms.
It's written in Node and is trivial to install/use in any Github project.
Feedback on anything, including pricing, very welcome.
Straight up git push with ssh git key support - yes, but might be slightly beta.
- they focus on open source, we focus on web apps.
- you can set Circle up in one click
- Circle is much much faster
- Circle allows you to parallelize your tests across multiple machines
- Circle supports deployment
That is my biased opinion of course.
Both TravisCI and Circle are new technologies in a new market, so I would expect this to change over time, but that's the way it is now.
Roll back in 30 seconds, cool but how do you manage data / schema migrations ?
You have a snapshot also to rollback any data corruption the last hacking session could have introduced ?
Purely out of intellectual interest, I wonder if a company the size of Google or Facebook could also ship in this way, or if the whole release manager/team is essential.
(I will complain though: the law says developers shouldn't have control over production systems. If that's a requirement, who's going to write the software?)
Here is the legislation if you want to read through it or use it to challenge someone's assumptions about the Sarbanes-Oxley; http://www.sec.gov/about/laws/soa2002.pdf
In my experience, SOX usually ends up meaning that developers don't have access to production systems, or significantly limited access. However, a continuous deployment system should generally be very much in the spirit of SOX, in that it's pretty hard to do without well-defined, highly-repeatable, automated and auditable processes.
I can't find it right now, but I know someone gave a talk on Apollo, which is how Amazon does deployments.
I did find 'flippers' from Flickr which sounds like a very similar "keep it all in master and turn stuff on and off" methodology.
My impression is that the different scale and technology mix at FB would make it difficult for them to deploy as frequently as github.
Also, Janky and Heaven are both tiny apps that don't necessarily have access to the file servers.
Not having access to the file system is a fair excuse...
I'm sure it could be "more efficient" when having code explicitely for this purpose, but then again you have to maintain to different code bases which do the same.
We do have days where multiple people will be waiting in line waiting for their chance to deploy their tweak.
That particular day consisted of staff deploys on multiple in-progress branches, some performance tuning, bug fixes, etc. Nothing crazy.
I'm also quite sure the number counts deploys across all of our applications. For instance, deploying a change to github-services counts as two, since I have to deploy changes to GitHub.com also.
> I'm also quite sure the number counts deploys across all of our applications. For instance, deploying a change to github-services counts as two, since I have to deploy changes to GitHub.com also.
That might explain a lot. Still a lot of deploys, but a more sane count :-)
I am hoping that Github could shed more light on the how they ship an enterprise version along with the SAASy web version that we all know and love.
We always keep the version of github synchronized with master for development/testing, although we only release master directly in major releases. For minor releases we avoid to include major features from github to keep it as much stable as possible.