Deployment

software-development

https://github.com/etsy/deployinator

https://codeascraft.com/2010/05/20/quantum-of-deployment/ - done reading
http://electric-cloud.com/lp/electricflow-devops-platform/
https://medium.com/@kevinsimper/why-you-should-not-use-git-for-deployment-e0590bcb185c
http://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-day
https://codeascraft.com/2011/04/20/divide-and-concur/
https://groups.google.com/forum/#!topic/continuousdelivery/9_5xpiHJZUc
http://programmers.stackexchange.com/questions/114056/agile-development-deployment-process-where-do-qa-and-business-owners-test
http://blog.mattcallanan.net/2014/02/how-etsy-do-code-reviews-with.html
https://www.quora.com/Why-does-Etsy-care-so-much-about-automated-software-testing
http://scrumology.com/splittin-up-test-suites-at-etsy/

Web based
Logged (When, What and Who)
Adaptable to our network
Run from a central location
Announced in our IRC and email
Transparent in regards to its actions
Integrated with our graphing/monitoring tools

For anyone deploying code (engineers, designers… anyone really), it’s an easy process. Once your code is ready to go, you go to Deployinator and push the button to get it on QA. From there it visits Princess (see the sidebar). Then, when it’s ready to go live, you hit the “Prod” button and soon your code is live, and everyone in IRC knows who pushed what code, complete with a link to the diff. For anyone not on IRC, there’s the email that everyone gets with the same information.

When we first brought Deployinator online, it was just a web frontend to the shell scripts that moved everything in the right place. What we gained by putting a screen in front of it was the ability to iterate the backend without changing the experience for people deploying. Deployinator currently uses svn to update the code, then rsync to move it between environments.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License