DevOps is about working smarter! When automating existing processes, people will likely open up entire new opportunities for working smarter. This is why an important cornerstone of a DevOps initiative is to automate what can in fact be automated. Automation frees time for innovation and development, whilst manual routines often are error prone and time consuming.
Looking at the full cycle from business requirements through development to deploy and later potential issue tracing and restores, there are surprisingly many activities that can be automated. Automation also often improves quality, since man caused errors are reduced, compared to manual routines. Automated processes are also easier to perform, which decreases the dependency to a specific competence or person (who may not be around when needed). When routines are automated – the right resources can be used for the right things and you avoid creating competence bottlenecks in your ”Software Development Plant”. All of the above are arguments for why the A for Automation is a part of the CAMS model.
A for Automation
Looking at a development process from an above perspective makes you realize that many activities in the process can actually be automated. Especially if you use modern tools available today for:
- version control,
- code quality coverage,
- continiuous delivery/integration,
- documentation
- and other development or operations related activities.
Even if you don’t choose to fully automate deploy processes, these can be heavily improved with the support of modern Open Source based tooling. Automating processes means that you take a fresh look at what developers, testers and operations staff are really doing when they deploy new software versions and try to get these functions to cooperate to automate where possible.
The Redpill Linpro DevOps Ready model through CAMS comes with a suggested set of activities that can normally be automated, performed and supported with modern tooling. To shorten the implementation process, decrease tooling evaluation times and get a quick start into the DevOps way of thinking, the model comes with a suggested reference architecture. The reference architecture is based on the currently best available (in our opinion) Open Source based tools for the specific purposes involved. Since all products are Open Source based, they can be implemented and tested at a low cost as the organisation learns about a DevOps style of work.
As the DevOps initiative grows and more processes and features are added, it is possible to acquire professional support with SLA and in some cases add functionality is required for the specific tooling. The reference architecture can be deployed both in the cloud, on premise and in a hybrid environment depending on your specific requirements. Through ready made training sessions and best practices through the DevOps Ready model, we help you getting started quickly and in the right way.
Some of the products/tools included in the reference architecture are presented below:
- OpenShift – For container management and managing your dev, test and prod environments.
- Git – For version control and source code management.
- Sonarcube – For automated code quality checks.
- Jenkins – For continous integration and delivery.
- Puppet – For configuration management, orchestration, provisioning and visualization.
Methodology equally important to tooling
Even if you have all the right tools it would not guarantee success for your DevOps initiative. No tools are better than its usage and the people using it. This is why it is important to establish a methodology and routines for the processes you want to support. Once the processes, pipelines and routines have been described and established you can start automating them. My recommendation is to start by picking som ”low hanging fruits.” A ”low hanging fruit” in this context is a process or pipeline you can automate that will have an impact on as many people as possible and improve their daily work. If you can successfully automate a couple of such processes you will have established a number of good examples that you can use as guides and motivation when you move on to more complex processes.
With good examples and support from your dev and ops staff you are ready to move on to automate more complex processes, achieve self service capabilities and an efficient total process from development to deploy – the ultimate objective of the most DevOps initiatives.
Measurement
That brings us to the next important part of the DevOps Ready Model. How to measure if you are successful and if your DevOps initiative really adds something to your business? This is where the M in the CAMS model comes into play. DevOps is also a lot about measuring. Measure to make sure that your initiative adds something to your organisation, measure what it adds, what can be improved etc…
More on measurement and the why and hows in coming blog posts on the DevOps Ready Model.
DID YOU LIKE THIS? THERE IS MUCH MORE TO LEARN
- Are you DevOps Ready? Part 1
- Are you DevOps Ready? Part 2
- Are you DevOps Ready? Part 4
- Are you DevOps Ready? Part 5
