DevOps

In a previous article I wrote about Getting Started with Github Actions . In it, I talk about the basics of Actions, how they work, what the language looks like and how you can get started. If you’ve never used Actions before, I highly recommend you have a quick read of that before reading this, as I build on some of the ideas presented there. Continuous Integration (CI) versus Continues Deployment (CD) versus Continuous Delivery (unhelpfully, also CD) Put simply, continuous integration is the act of continually moving your changeset into the wider codebase, as frequently as it makes sense for your use case. CI is an essential practice because it drives us as engineers to produce smaller changes more often, and these small changes tend to be less risky individually. Those small changes also lead us to deliver value to our users more rapidly, and more often. ...

Continuous Delivery is a foundational skill that your organisation needs to be good at if it is to remain responsive and ’lowercase a’ agile. A full solution for continuous delivery tends to include (but isn’t limited to): The ability to create artefacts that we can release to production, across many products, teams, branches, environments and repositories. The ability to quickly validate an artefact as a candidate for release (through applying the testing triangle - unit, integration, acceptance, smoke and so on). The ability to release code to production without necessarily activating it for users (typically through feature flags, canary built and graduated rollouts). The ability to rapidly respond if a release candidate we later find to be problematic (again through canary builds, graduated rollouts, and by quickly rolling back software found to be problematic). The ability to audit or understand what code is where, what state that code is in, and why that code is where it is. More concretely, a decent CI/CD solution will: ...

My team at Healthlink have just finished a proof of concept around Continuous Delivery. Here’s the writeup, sanitised for the internet. Context We’re a Health IT company based out of New Zealand, and run an set of products that provide messaging integrations between Healthcare organisations across New Zealand and Australia. Our applications are a mixture of desktop and web service based, and we’re currently undergoing a massive change process from Waterfall to Agile and from a bespoke services company to a truly product focused company. ...

On Friday 30th September, a colleague and I spoke at Devops Days 2016 in Wellington. It was an awesome experience, and the first time I’ve spoken on technical and non-technical topics at an industry conference. The talk I gave is available on Speakerdeck . I’ve also embedded it below: I think that the one thing that I took away from Devops Days NZ 2016 was this. ...

The work that I’ve been doing for the past few months has been pretty interesting. At the moment it takes developers working on one of our ventures about an hour and a half to two hours to deploy code to a test or prod machine. It used to take a second venture a similar amount of time to do the same task, but the process we’ve implemented for them has reduced that significantly. Once the process is completed across both ventures, our team will have reduced that deployment time enough, that the product owners for those ventures will effectively gain 20% more points for work per sprint. ...