Treating DevOps and Automation as a project is destined to fail. Now that I've made the big scary intro, let me clarify. A DevOps project works if the project is to implement a new operational strategy, not if treated as a traditional project with a finite end date.
In the context of this article, infrastructure could be either hardware or software or both.
Typically, projects start with upfront funding, deliverables, and an end date. Once completed the operations team manage the deployed infrastructure to allow the solution to keep running. However, there is no funding for life cycle management or continual development, in opposition to the fundamental principles of DevOps.
(Image: Kalakruthi/Shutterstock)
First attempts to implement an automated approach face difficulty as code and infrastructure are part of the same project. Logically this makes sense, but it comes with the traditional project concepts of end dates and operational handover that limit or prevent ongoing workflow development.
The infrastructure component of initial automation projects is straightforward, much like a regular infrastructure deployment. However, a strategy to handle the frequent update cadence of automation tools is crucial to the ongoing longevity. The traditional approach of infrequently updating production systems does not align with automation.
Challenges are frequently faced when it comes to the workflows. There is a mentality shift required to understand that the workflow is never ‘complete’ and that the operational tasks include debugging and development.
A common expectation that workflows can be handed over to operations as a package and that the workflow should be complete and virtually bug-free, potentially needing no internal code updates. In my experience, this has never been the case and impacts project closure; setting these expectations earlier increases the likelihood of successful adoption.
The new operational strategy comes into the picture and conflicts between the current and new appear. DevOps projects fall into the domain of infrastructure management but need to be treated as internal application development, which has a different funding and support model.
A new operational strategy
With adequate planning and training, workflow code can be updated rapidly and as part of an operational role. Change control processes are still required albeit adapted and streamlined so that they do not negate the benefits of the new strategy.
The new operational strategy should aim to remove as many steps between workflow consumers and those who maintain the code. The goal is to enable those writing code to get first-hand bug reports and ship updates efficiently. This is not an argument for removal of change control, but to incorporate rigorous testing and deployment practices.
Feedback from managers I've spoken to aligns with the view that workflow functionality changes are a project. Therefore, a new project is required to add functionality. This view comes from organizational structures where development and operations are separate processes.
A side effect of this view is that bug fixes are difficult to implement because operations do not understand the code, but the current strategy doesn’t allow for developers to push code to production, even with pipeline tools.
Overcoming these issues is a difficult battle and the process to do some depends on your organization. Where I've seen success is the implementation of a DevOps strategy in moderately autonomous business unit, which then shares the results throughout the company.
The people running the project understand DevOps strategies, and they have operational tasks which are internal to the business unit; allowing the business unit to change the process from manual tasks to code-based tasks without significant interference. Successful adoption guides other areas of the business to adopt an automation strategy.
