We're DevOps, now what?

The short answer is that DevOps isn’t a destination or a target state but a journey i.e. we’re never done!

Let me provide a bit more background on the current team structures and the environment in which they operate:

The development teams are product focussed, use an agile approach to deliver value to the client and the current deployment cycle is monthly. Code is worked on in branches and merged back to the trunk prior to the release. The teams commit code regularly and merges from the trunk are also performed frequently to reduce any merge conflicts from interim bug fixes, etc. Everyone knows what they’re doing and it works well. The code commits trigger the CI process and fire the automated tests. Static code analysis is performed nightly and the team proactively resolve any newly added code smells or bugs.

The Ops team’s skills set is similar if not the same as the Development team; they perform maintenance releases on the application code, create the formation templates for the cloud infrastructure and develop the automation for the build and deployment pipeline. They keep the software infrastructure up to date, ensuring security patches and the latest versions are applied.

Large monitors exist on the wall for all to see, cycling through sets of statistics from Kibana logs and cloud watch metrics through to the build and deployment status for each environment.

On the face of it things seem pretty hunky-dory and to be fair it works very well. But can we do better? Of course we can!

I was leading the DevOps transformation for a global technology division of a large investment bank prior to recently emigrating to Australia. Over the course of the next 12 months I’d like to share both my past experience mixed with the ideas and experiments of my current role to see if we can improve on what we do. Hopefully I’ll be able to show the improvements with some empirical evidence.