(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…
BlueGreenDeployment (2010)
31–38 of 38 posts
Re: BlueGreenDeployment (2010)
#32On 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)
#33Re: BlueGreenDeployment (2010)
#34Re: BlueGreenDeployment (2010)
#35The 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…
Re: BlueGreenDeployment (2010)
#36Re: BlueGreenDeployment (2010)
#37I 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.
Re: BlueGreenDeployment (2010)
#38Database 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…