I’ve been working as a ‘Platform Engineer‘ in my previous two roles, firstly at a market leading online bookmakers and currently at a leading Irish bank. Job title’s today tend to give little away about what the actual role entails and Platform Engineer is no exception. For me the role has been focused on building a continuous delivery (CD) and platform as a service (PaaS) capability.
How I came to be in my current role was by first getting involved with a small startup.Our application was built using Ruby on Rails and our concept of CD was me performing
git push from my laptop (please don't do this). Ever since that time I have had a special place in my heart for RoR and a curiosity around deployment practises. Over the last two years, working with CD daily I have come to one specific truth about RoR, it is not deployed well. Most of the time people using RoR will rely on some form of git based deployment model. For example, in order to deploy code using Capistrano, usually a
git checkout will be run. If you wanted to avoid the extra step of doing a git checkout you don't have to as Heroku uses
git push, so your code never needs to be checked out again. It has taken me quite a while to understand that it doesn't have to be like this. While this might be quick and easy, I believe it is a deeply flawed and highly risky way of managing any kind of deployment (test or production). It is usually done from a developers desktop and involves a trust mechanism when it comes to testing.
Even in larger companies where testing is automated before deployments, it is usually little more than Continuous Integration. While this is absolutely a necessary practise, it is not enough to ensure the integrity of the software being deployed. The only way to reduce the risk involved with production releases is to release often using a Gated Continuous Delivery Pipeline. This concept will be expanded upon later on in this blog series.
This is a brief introduction to a series of upcoming blog posts on Continuous Delivery with a Ruby on Rails application.
Continuous Delivery aims to make releases boring, so we can deliver frequently and get fast feedback on what users care about.
Source : Thoughtworks
Continuous Delivery should be a key process used by every company, from small startups to large enterprises. It is not as difficult as it sounds and is worth the time it takes to implement.
But what about 'Move fast and break things'?
Please see below:
Moving quickly and breaking things is perfectly fine in a controlled manner. What you break needs to be measured and compared with previous iterations in order to ascertain value. The best way to do this is using repeatable and regular deployments into multiple environments time and time again.
Over the next few weeks I'll be covering the following topics in order to demonstrate the value of Continuous Delivery in a Ruby on Rails environment.
Part 1: Continuous Integration
- Style and Syntax.
- Static Analysis.
- Security Scanning.
- Brief Introduction to Testing.
Part 2: Testing and why it's important
- Unit Tests.
- Acceptance Tests.
- Performance Trend Testing.
- Smoke Tests.
Part 3: Immutable Artefacts
- The Song Remains The Same.
- Build Once, Deploy Everywhere.
Part 4: Immutable Environments
- Why all servers should be equal.
- Configuration Management.
- What about local development?
Part 5: Delivery Pipeline
- How to tie everything together.
- Visualise your workflow.
- Automate everywhere.
Part 6: Monitor & Measure
You will gain a number of key understandings by reading this blog series.
- Reducing risk in deployments.
- Know how to deploy more regularly and more often in a safe manner.
- How to build an immutable artefact.
- Concepts of immutable infrastructure.
Hopefully you can take what this blog series offers and make your workflow more reliable, repeatable and safe.
More to follow...