Live data from Hacker News

BlueGreenDeployment (2010)

martinfowler.com

31–38 of 38 posts

Re: BlueGreenDeployment (2010)

#31
post #19

(looking for comments) 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 https://github.com/allan-simon/ansible-docker-symfony2-vagra... basically I have ______nginx__phpfpm+code (blue) / \ front nginx database \______nginx__phpfpm+code/ (green) The front nginx play the role of "switch" between blue and gre…

Yeah, that's the way to do it. Provided nginx is working properly it should be zero downtime.

Re: BlueGreenDeployment (2010)

#32
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!

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.

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?"

Re: BlueGreenDeployment (2010)

#34
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.

Re: BlueGreenDeployment (2010)

#35

The way I do it is to rsync my code to a path such as "app-v1.0.0" I then create symlinks such as "live" & "beta": "live" -> "app-v1.0.0" 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. I find a lot of people just casually deploy their code with git, and subsequently run "bower install", tolerating downtime in between, wit…

I do this almost exact process with the symlink swapping, it's amazing. I use bamboo however, so we're literally in a state of 'Commit code, push button to deploy to one of three environments', no other steps are needed or involved.

Re: BlueGreenDeployment (2010)

#37
post #24
post #20

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. 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…

In a big 3-letter multinational corporation your experience with the build process might not be representative of the corporation at large.

You're right. But I've asked around and I haven't found any projects that use an automated build and test process.

Re: BlueGreenDeployment (2010)

#38

Database is the sticky part of this strategy. If Blue is in production and Green is on deck, how are updates to the Blue database pushed to Green?

Copy DB from live [blue] to staging [green], then run migrations and test. Do this several times. This should give you confidence that the migrations behave as intended before you flip from blue to green for production & run the migrations for real. If you have "big data" you can use schemaless migrations, for example never rename a column, instead add a new column, update the app to deal with both columns, then in a…

[deleted]
Post reply on HN