Continuous Deployment in Rails

The introduction of a continuous integration server makes our life a lot simpler as we can configure deployments once and have the CI do the rest. This allows front-end developers who maybe aren't as comfortable running deployment scripts get their code up to production without having to ask a backend developer to do it for them. Also, a properly configured CI will not deploy if your suite fails, which can save you and your users from dealing with bugs on your production instance. Another overlooked benefit of using a CI to handle deployments is that junior developers on your team can safely deploy code up to remote instances and (assuming you have a robust test suite) not have that lingering fear that their code will bring the house down.

The Rails Hosting survey results show an increase of 7% of developers deploying their application code on a daily basis from 2014 (27%) to 2016 (34%). I know from experience from working at Planet Argon that having these often complex deployment processes handled by a CI not only saves me time but the headache of having to remember the step by step process.

Lastly, but one that really rings true for me is not needing to add all your team members SSH keys to the various remote instances they are expected to deploy to. The application I work on has three remote instances, and the production instance is divided up into 6 different entities (2 app instances, 2 database instances, 1 admin instance and 1 utility instance). That means whenever we bring a new member if we weren't using a CI for deployments a team member would have to add the new member's SSH key to 8 different .ssh/authorized_keys files!

Continuous deployment allows developers to get back to what we want to do quicker, which is writing awesome code.