Releasing code is not a big deal

21 June 2019

Written by

Shaun Parsons
Senior Software Developer

What’s the worst that could happen?

The importance of releasing code early

As a developer, I think it’s great to be able to see the real world impact of my work, so when I started at Talis I was very keen to get something into production as quick as possible. Etsy have previously spoken about how they try to get new engineers to deploy to production on their first day. Within my first few days I had already conducted a bug investigation for a member of the product team, and shortly after made my first production release. Not only is releasing code in the first few days of a new job a great morale boost, but it also removes the fear associated with releasing code. After all, if a new starter can be trusted to release code in the first few days, how scary can it be?

In order to be able to enable new starters to release in their first few days, we have to provide appropriate tooling and resources to make this possible.

Ramp up

New developers at Talis are given a series of ramp up stories. These are generally small bugs or improvements that don’t require a great deal of code change, but do require the set up of a local environment, going through our code review process, using our chat ops to release to an on demand environment before finally releasing to production. The main purpose of these ramp up stories is to get new starters comfortable with releasing code to production. In fact, over the last year, we made 54 releases to our main product in just 117 working days. This doesn’t include the numerous releases we made to the microservices that support our core product.

Specifying the work

Every team at Talis works in 2 week sprints, with the work broken down into multiple stories. The aim is that at the completion of each story we are able to release the work done for that story. In its simplest form, a story consists of a description of the bug or feature along with a proposed solution or desired outcomes. In the fortnightly sprint planning meetings, the team will go through each upcoming story to provide estimates and talk through the proposed solutions or outcomes. Even in my very first planning meeting, I was encouraged to ask questions and make suggestions about the stories we were discussing. Developers can then pick up stories for the current sprint and have all the details needed to complete the story.

Story

The fun stuff

Now that we have a well-defined story with clear outcomes, we’re ready to get on with writing some code. Everyone is free to use the IDE of their choosing (as well as operating system), and we have pretty much every major IDE being used by someone in the office. All that matters is that you have a development environment that you are comfortable with. Pair Programming is commonplace within Talis and is encouraged. This is particularly useful whenever you start work on a project or area of the code you’ve not worked on before.

Peer review

Once I had self reviewed my own work and got a green build on our CI server, it was time to ask for a peer review. I feel like this first review is always daunting for developers - after all, it’s the first time your new colleagues will see your work and you want to make a good impression. Thankfully any fears I had were soon alleviated when I received an approval, and got asked to release it…

Don’t worry about it

At Talis releasing is not a big deal. After all, by the time we get to releasing our code has already been reviewed by another member of the team and automated testing has been performed on our CI server. The first step in our release is to deploy our code to an on-demand environment which mimics our production environment. Creating an on-demand environment is made simple with our chat ops:

<service name> create ondemand <code version>

On our staging environment, we will perform some automated testing using New Relic Synthetics. Once everyone is satisfied that everything is working as expected, then we can deploy to production. This time the process is slightly different and another developer will be required to approve the request (this approval means that a second developer is available should any problems occur during or after the release):

<service name> deploy <code version>

Once this has been approved by a second developer, your code will be deployed to production. At this point, we monitor our throughput and error rates for any anomalies, and if we detect any at this point we can check the logs for more detail and, if required, we can rollback to the previous version by deploying that version using the same command. All this means that even if there is an issue with a release, we can return our systems to a stable state.