The most interesting thing for me was the link to <a href="http://continuousdelivery.com/" rel="nofollow">http://continuousdelivery.com/</a> and the diagrams summarizing some of the concepts in the book (they're CC licensed):<p><a href="http://continuousdelivery.com/wp-content/uploads/2014/02/01_CD_the_idea_low-res.jpg" rel="nofollow">http://continuousdelivery.com/wp-content/uploads/2014/02/01_...</a><p><a href="http://continuousdelivery.com/wp-content/uploads/2014/02/02_CD_test_strategy_low-res.jpg" rel="nofollow">http://continuousdelivery.com/wp-content/uploads/2014/02/02_...</a><p><a href="http://continuousdelivery.com/wp-content/uploads/2014/02/03_CD_automated_acceptance_test_low-res.jpg" rel="nofollow">http://continuousdelivery.com/wp-content/uploads/2014/02/03_...</a><p><a href="http://continuousdelivery.com/wp-content/uploads/2014/02/04_CD_managing_data_low-res.jpg" rel="nofollow">http://continuousdelivery.com/wp-content/uploads/2014/02/04_...</a>
I work at a big 3-letter multinational corporation, and we still compile and deploy manually. No continuous integration or, at least, automated testing. No build tool whatsoever, or a repo to store artifacts. Everything is compiled on the dev's workstation and sent by email.<p>We do have a disaster recovery server, but it sits outdated for weeks after a deployment in production. When something goes wrong, the switch is not automatic and transparent to the user, we have to email EVERYONE in the user's list to please use the DR server's address. There is no router or load balancer.<p>Crazy.
I had the pleasure of working on a three node blue-green system at a Fortune 100 company (yes, enterprise can do some things right). Each cluster could be in either of two production modes or a staging mode, all switched with a simple command line request. The request created touchfiles that managed the load balancer behavior. Instantaneous switching, yeah!<p>On the other hand, the database was more or less a cache. It was very much availability over consistency, in CAP terms. If we had to keep transactional data, it would have been harder.<p>edit: When I started there and they described the architecture to me, I said "Cool, you're doing blue green deployment!", and the response was "What's blue green deployment?"
BlueGreen deployments are easy to achieve using something like AWS ElasticBeanstalk (and they also force you to have your entire env setup in code so its quickly duplicatable for each deploy) with how easy it is to create a new stack and its 'Swap CNAME' feature.<p>However, now that Elastic Beanstalk supports incremental rollouts I don't see as much value in the approach.<p>We use Blue/Green deployments (with AWS EB) at Mi9 to deploy all our high traffic websites
Betterment just posted an interesting set of slides from their #AnsibleFest presentation yesterday on 'Cyan' deployments powered by Ansible; kind of an evolution of the traditional 'Blue/Green' style described in Fowler's post: <a href="http://www.slideshare.net/AlanNorton1/cyansible" rel="nofollow">http://www.slideshare.net/AlanNorton1/cyansible</a>
The way I do it is to rsync my code to a path such as "app-v1.0.0"<p>I then create symlinks such as "live" & "beta":<p>"live" -> "app-v1.0.0"<p>I rsync the code from a CI server or local host, after running bower/composer & testing, this way I deploy a "snapshot" of the entire codebase.<p>I find a lot of people just casually deploy their code with git, and subsequently run "bower install", tolerating downtime in between, with no solid rollback mechanism in place. I hear Capistrano works in a similar way but is git based instead of rsync. To me its really important that the updates happen atomically & roll back atomically, and as a result of running a single command.<p>Simple example of a "deploy.sh" I would use in a new project:<p>gulp production && rsync --update-after --delay-updates --exclude-from="rsync_exclude.txt" -avr ./ server-www:/var/www/html/
Netflix does it with two auto scaling groups: <a href="http://techblog.netflix.com/2013/08/deploying-netflix-api.html" rel="nofollow">http://techblog.netflix.com/2013/08/deploying-netflix-api.ht...</a>
This can be implemented easy using Ansible
<a href="http://docs.ansible.com/guide_rolling_upgrade.html" rel="nofollow">http://docs.ansible.com/guide_rolling_upgrade.html</a><p>btw article is 4 years old
Some companies will also activate the new path only a small percentage of traffic and monitor the logs to be able to detect errors that were missed in testing.
We use this at the (very large) corp that I work at, with very large, complex, high-traffic/revenue sites. Each component in the architecture has it's own "light/dark" deployment (in each environment), so any piece can be staged/tested/deployed/rolled-back with zero downtime. It has worked fairly well, with the majority of hiccups occuring during the ramp-up on the process.
We've used this technique at Respondly for the past year and a half with a Meteor stack. It's saved a lot of headaches and has greatly minimized downtime. It does have some gotcha's though when pushing certain types of changes. Mostly things around message formatting changes in shared queueing systems.
(looking for comments)<p>after reading that articles (some months ago) I've decided to implement that in our company , we're mostly using symfony2 and postgresql, and I came up with that <a href="https://github.com/allan-simon/ansible-docker-symfony2-vagrant/" rel="nofollow">https://github.com/allan-simon/ansible-docker-symfony2-vagra...</a><p>basically I have<p><pre><code> ______nginx__phpfpm+code (blue)
/ \
front nginx database
\______nginx__phpfpm+code/ (green)
</code></pre>
The front nginx play the role of "switch" between blue and green , and the database is shared<p>so basically for the database problem I solve by telling our dev to be aware of it, which translate into a two step process for database upgrade. (we use Dotrine's ORM with doctrine migrations for migrations, so when i talk about getter /setters I talk about the entities' )<p><pre><code> * if we add a column which must be "not null" , we add it with a default value first , so the few second the old code is still online , but the database is already updated , if an insert happen it will not fail . Then second time we drop that default value and put in the migration the SQL statement that handle previous data.
* if we drop a column, we first commit a version of our application which remove the code using this column , or make them return default value. and then the second deployement drop the column, so that the version N-1 is already made to not care about it.
</code></pre>
etc. the base logic is "the database version N+1 should still work with version N of the code" , I like to image that with a "crossing a small river by always keeping a feet on earth rather than jumping the two feet at once "<p>after I have to admit that fortunately 99% of our deployment are not about database changes so this "need to do it carefully" only happen once in a while and it does not affect our productivity (especially with the gain of being able to do CI)<p>last thing, is that I've used this technique only on small to medium websites, nothing with HUGE traffic, so I don't know if it's 100% no downtime, my test (running several `while true; curl WEBSITE ; done ` ) shown no traffic lost.<p>I just wanted to say that to get opinion from more experienced people, while telling to "normal company" fellows that it's possible to achieve that without "the cloud" and old-school server hosted in a DC or at customer's office.<p>Edit: of course we still have a dev and staging environment on which we validate code before deploying in production.
That's from 5 years ago.<p>Also: Your database changes should be entirely backwards compatible and should happen in one location (not on its own slice).