DevOps has captured the imagination of an entire generation of tech professionals with its irresistible allure and promises of hyper-efficiency and highly. But what is Devops exactly?
We love the definition that Alessandro Diaferia shared in a recent blog and his Twitter account:
Practically speaking, DevOps is a term that exists to describe the acceleration of the development workflow by increasing communication and collaboration between the Engineering (Development) team and the Operations (IT) team.
It should be fairly obvious that just by hastily merging these two teams into a single department alone won’t yield any operational improvements. The approach requires a more thoughtful approach to produce desirable results.
It turns out, that a meaningful part of planning that merger should involve the exact thing that these teams will be communicating and collaborating on: internal knowledge. In order to reach the goal of higher operational and developmental efficiency, these team members will need to be able to capture, access and share knowledge in a way that may be different from the way they would have individually done it in the past. Knowledge will certainly be the key to success.
Knowledge is the key
Access to knowledge is absolutely mission critical to the DevOps workflow. When a technical team is constantly iterating on product and frequently shipping updates, the value of comprehensive, verified and timely information cannot be underestimated.
In the ideal situation, all of this knowledge is self-served from both static knowledge bases and silos that track issues.
Consider how common DevOps strategies can be improved by bringing knowledge into the flow of work.
A continuous integration strategy places a high degree of importance on testing and QA. This is most easily facilitated by enabling the team to spin up containers or VMs using their own discretion without having to involve IT. In order to achieve this, the entire testing cycle should be documented in the knowledge base so that the developer can self-serve the knowledge required to complete testing and validate that the code does not have to back through development.
Continuous delivery involves ensuring that deployed code goes to the staging environments that accurately mimic production so that the code is always production-ready. This way, there is assurance that when the code arrives on the production environment it will have been tested the proper environment. Self-serve documentation should include:
- Configuration details, variables and settings for production environments
- Processes for testing, ideally automated
Continuous deployment, unlike continuous delivery, will require changes to be implemented in a fully automated fashion, including testing. Ultimately, this will be done without human intervention. To accelerate these flows, documented knowledge should include:
- Instructions on how to build automated unit tests
- Details on how limit development to more distinct manageable chunks that are better suited for automated testing
Much to the chagrin of every proud developer, bugs come up more often than not. For those that are less obvious than others, such as those that do not come up as error codes, need to be tracked and communicated. Before filing issues, the individual who identified the issue should cross reference the bug to confirm whether others are already working to fix it or it is one that needs to be assigned for resolution.
QA, Provisioning and Configuration
One could write volumes about how to properly test code.
- Instructions on how to create or run automated testing
- Definition of quality metrics
- Definition of quality standards
Spinning up containers or VMs for testing purposes requires access to knowledge on how to provision machines such that they can run the desired code. Documentation can be created to aid in provisioning by establishing:
- Defining the requirements to build a working state server including operating system, applications, middleware and storage and more
- Defining requirements for database servers
Imagine trying to develop code without knowledge of how to configure environments. Configuration, which is different from provisioning, must carefully. Opportunities to establish self-serve knowledge that will accelerate configuration in the DevOps scope is to document:
- Runtime configuration requirements
- Automation for creating or applying configuration without manual intervention
To conclude, the are nearly limitless opportunities to create documentation that will facilitate more independent DevOps workflows by creating access to reliable self-serve knowledge.