DevOps. It’s the trend that many companies are moving towards or adopting to improve the speed of their software delivery and align their design with the actual usage and needs of customers and production. It’s a natural progression of our software development processes that brings a better and more maintainable software design. So naturally, while teams adopt some form of microservice or cloud-centric approach to achieve this, DevOps is actually a whole lot more and so its important that team think beyond these architectural concepts to evaluate if they are ready for it.
It’s a progression that is not without serious challenges and risks though and before you decide to embark on this challenge, it’s important that you prepare your teams and company for it. And so below is a list of things I recommend that you work on to ensure that you are ready for it, both from a technical perspective but also a cultural and people perspective, starting with the latter first because these are the ones I actually feel are often least understood.
Cultural Aspects:
Understanding your customer
At the heart of DevOps is the ability to be able to meet the needs of your customers quicker, while also being able to support those needs more directly, so naturally, before you even consider bringing your technical teams into the DevOps space, you need to ensure that you bring them closer to the customers. Whether it be through engaging existing support teams, speaking to them directly or surveys, you want your development team to start thinking and designing for customers specifically, being aware of their support needs and ultimate start working towards these goals collaboratively.
Attitude to risk
Something not often considered in the DevOps space, is the attitude to risk. Not that DevOps is riskier – quite the opposite in fact, as smaller, more frequent releases are less risky than larger less-frequent release. However, the ability to support production directly or release updates at speed requires certain amount of tolerance for risk. While many teams can embrace the DevOps philosophy, teams that are involved with aspects like money or security, will probably not want to jump onto the DevOps chain too enthusiastically. Not saying this can’t be done, but there is a lot that needs to be put in place first – most of which can be found below.
Ownership
When teams start to support their code in production, an important culture to bring in is that of accountability. No longer can their code be deployed to production and left in the hands of some support team or throw their code over the fence and not need to deal with the repercussions. Introducing an environment of ownership where teams are prepared to not just be available to support software at many different hours, but also own up to mistakes when their code push causes issues elsewhere and take the responsibility of addressing it. It also requires teams to take great ownership of ensuring their app is sufficiently tested beforehand and has taken into consideration all the external dependencies.
Strict Exit Criteria
Which leads to the need for strict exit criteria. While most DevOps teams try and avoid restrictive processes for the sake of improving efficiency, there is a need for strict guidelines to be put in place that determine when a piece of software can be deployed into production. If the architecture and automation testing is done right, this doesn’t need to slow down a team at all ,but teams shouldn’t be in the habit of skipping process for the sake of it and ensure that they allow the different testing and audit mechanisms to do their job. Having a team full of cowboys is not what you want in a DevOps team.
Technical Aspects:
Automation Competence
It probably doesn’t need to be saying but if you don’t have extensive automation and a robust framework in place you probably shouldn’t even b considering the DevOps route. Test automation is at the centre of quicker delivery, support and uptime and so if your automation coverage is not great or a little too unreliable, fix that first. Having testers who can also get involved at unit test or component leave automation and are technically component enough to debug issues and quickly script automated tests to cover them are critical to the success of your project.
Code Coverage
Along with the automation piece comes the ability to measure your code and functional coverage and specifically understand where your gaps are. While 100% code coverage doesn’t mean it works, it does provide a strong sense of comfort in your regression efforts and so before teams look into getting into a DevOps capacity, they should address their code coverage.
Monitoring and Alerting
Monitoring is at the crux of understanding how a system operates in production and being able to respond to failures. As such, your development teams should invest in tools that can regular identify when services might go down, assess system performances and even hardware resources to ensure service capacity and application performance is kept optimal. These things should essentially form part of your definition of done to ensure that any code you put into production can be correctly maintained. Code that cannot be monitored should never go live and its important teams develop this habit and develop this capability if they want to embrace DevOps.
Load and Performance
The monitoring mentioned above speaks a lot to the ability to measure a system’s load and performance and allow a team to respond proactively. However, we shouldn’t rely on our monitoring or ability to scale to address this ,because at time, (and especially if you’re using a cloud service provider) this can end up quite expensive and so what you want to do is before code is even delivered, that you have been able to optimise this. Having a good performance and load test framework in place that can identify the optimisation of your systems, frontend, backend, network and databases daily reduces the risk of performance issues getting introduced into production.
Ability to Recover
No matter how good your testing efforts, at some point in time things may go wrong and teams will miss something. Being able to identify and recover form failure though is critical and as such your deployment systems need to allow for easy and effective rollback with the code designed in as modular a fashion as possible to limit subsequent risk on dependencies.
Pipeline Stability
The pipeline is essentially the lifeblood of your development framework, taking your code to various stages and testing it there. Your pipeline though is only as stable as the underlying code and container infrastructure it runs on and so its important that you as a team ensure that your pipelines run reliably. This allows you to be able to put in urgent fixes without needing to spend time addressing pipeline issues that prevent you from doing so.
DevOps is more a philosophy than a methodology. A lifestyle that teams need to align to and be comfortable with more than just a development approach and as a result, its important that you look at your teams as a whole, the software and how it is tested to evaluate if this really is the correct approach for your company/team or perhaps give you a roadmap on things that you need to work on to get there.