Six best practices for DevOps
When planning for DevOps I always first think about “What is the best I can achieve?” Comparing the ideal with the reality then helps me to define the roadmap of changes I have to apply.
Robb Wiedrich talked in his recent blog post about DevOps best practices in the area of principles to adopt. I want to focus more on the workflow view here. Sorting out what to do in which step helps us to define the overall process and the roles involved.
So let's have a look at a very simplified flow from requirement to delivery, consisting of six steps: requirement management, design and architecture, coding, build, deploy and test.
I will not get into much detail about things that are already covered in most environments but will point out the stuff to be done in addition when living in a DevOps world.
And, to be honest, it's not exactly six best practices but six areas for you to consider in any DevOps workflow.
Besides collecting all the functional requirements, put a special focus on all the nonfunctional requirements. That includes requirements that reflect the operations department's point of view, like:
The point is that you gather not only everything that's important to build the application but also everything required to run the application and the environment the application is operated in.
Design and architecture
Of course the application design required for coding is defined here. But the application should also be designed for automated testing (if not done already). Also, all the architecture specifications of the staging environment and production should be done now, aligned with the corporate infrastructure standards. And this is also a good opportunity for collaborating with your Ops guys, because they will know about how the infrastructure should look in the production environment.
The more standard architectural patterns you use (either developed according your own standards or provided by a middleware vendor), the easier it is to achieve a high level of standardization in the deployment procedures and management environment later.
That the actual source code has to be written is self-evident. That the test scripts and infrastructure code are developed at the same time is not. For the following process steps it is a prerequisite that for every piece of source code a corresponding test code is developed at this point in time. Also, you should cover everything that is required to build and deploy the application in this step. If you rely on architectural patterns for the infrastructure and middleware platform you mainly have to address the application deployment and configuration steps. I would recommend that you code the test tool deployment and test environment configuration as well, as this is needed later to achieve a comprehensive automation.
A remark before we continue
As you can see, the most work is done in the first three steps. This is the so-called left-shift experienced when introducing DevOps, as I described in a past blog post.
It is helpful to use a collaboration platform that's capable of linking requirements to work items and test cases. Otherwise it is very hard to keep track of who's done what and implement governance on the process. Tools like the IBM
All of that input is now used to automate the delivery pipeline. By now you should have defined everything that is needed to completely automate the remaining three steps in my workflow. For the previous three steps I talked more about task-related recommendations (what to do). For the next three steps my best practices are more of a technological nature (how to do it).
Everybody has build automation. And normally it is tightly integrated with the source code management so that the build process is reproducible and accountable. If you have an asset management system, use it to store the builds along with all the infrastructure code in the same place. That makes it easier to reproduce a specific version (for example, N-1) in a test environment later.
There should be no manual tasks left for you during deployment. Based on the architectural patterns (for example, by utilizing a cloud capable of providing these) and the configuration automation, the whole application environment can be deployed automatically. If you need to change something, like a configuration value, change it in the deployment description and not manually in the environment.
Also, I consider it a good practice to do a full stack deployment every time. This gives you the maximum on control over changes and the environment.
To avoid any discrepancies between the different staging environments and production, the same technologies should be used for the whole release process and every environment (and that is an area where you will probably have the most discussions with the operating team).
To put it simply: test everything. Although that sounds like common sense, keep in mind that requirements now also include all the operational aspects. From my experience these are normally not covered by tests as well as they should be.
In addition there are two capabilities necessary that could help you to achieve a higher degree of automation and test quality:
Of course there is much detail that we could add to each step. I only wanted to point out some of my main thoughts on the topic that can help you to structure the process and work items in a better way.
The next steps are looking at how specific processes like change and release operate along that workflow and having a more detailed look at a role model covering both development and operations. I will look into these topics in future blog posts, so please stay tuned.
If you could take away some of the best practices for your DevOps journey or want to look into more detail on a specific point, just leave a comment. (Also leave a comment if you have different point of view; I also can learn something new.)