DevOps is not “one size fits all”
In a previous blog post, I highlighted 3 key benefits of DevOps in your organization. This post goes deeper uncovering some common misconceptions when implementing DevOps.
When it comes to DevOps, many have approached me asking what the level of effort would be to “implement DevOps” for a project. It’s as if the expectation is to pull something off the shelf and *bam*, all this DevOps goodness and best practices will be implemented. Not so easy. Each project has its own considerations that need to be addressed in order to apply the right policies and governance. There is no “one size fits all” approach to DevOps.
Tailoring your DevOps implementation
A project will have different considerations depending on the project type and the technologies involved. For example, a website project will have different considerations than a Windows application, which will be different from machine learning projects, database projects, IoT projects, etc. Similarly, different considerations come into play depending on whether the solution is expected to run on-premises, at the edge, in the cloud, as well as which cloud providers are used. The point is that DevOps focuses on a common set of principles that can be applied to projects in a uniform way, but the pipelines will need to be tailored to each project.
Common and custom elements of DevOps implementation
This is not to say that every project is a unique snowflake requiring bespoke DevOps to be built. Many of the core components and are shared across all projects, but we must take care to tailor the governance to the solution being built. There are common elements and custom elements that come into play for any software project. Common elements tend to be the overall project governance practices that are followed (ex. Agile project management, source control policies and governance, code reviews, etc.). Custom elements are those that must be tailored based on the technologies being used.
Design choices and considerations
Different programming languages and computing platforms will have different considerations and steps that need to happen to maintain the environment, and perform Continuous Integration and Continuous Deployment (CI/CD) in a robust manner. Additionally, a project can apply several frameworks.
For example, an edge AI project could have a C# component, Python components, and Azure IoT Edge components. Each of these will have its own build templates that need to be configured to run as part of the continuous integration (CI) process. To help speed up the process, a library of build templates can be maintained. This library will then contain the building blocks to help connect the individual components which make up the entire solution.
The continuous deployment (CD) process also has its own considerations. For example, it probably isn’t a great idea to apply automated CD every time a machine learning model is updated. It is in everyone’s best interest to require manual intervention prior to releasing to the production environment, so the data scientist and business stakeholders get an opportunity to validate the models prior to release.
This can be combined with other approaches like canary deployments and champion/challenger testing to make sure the solution is well maintained. Treating the project as something that requires care and attention allows us to make better design choices for developing and maintaining it throughout its lifecycle.
Hopefully, this helps to illustrate some of the considerations that come into play when designing a DevOps strategy at an individual project level. Neal Analytics specializes in helping our customers through the process of implementing DevOps, no matter what their current maturity level is. Neal Analytics can provide strategic planning, technology assessments, proof of concepts, as well as the technical resources to get you started on your DevOps journey.
Interested in learning more about how Neal Analytics approaches DevOps? Please inquire with email@example.com for additional information from our experts.
This article was also published on LinkedIn.