chris - Fotolia
Shifts in how IT work is done will change the shape of DevOps' evolution as it enters its second decade of existence. Two primary factors will influence this DevOps evolution: the move toward continuous development, deployment and integration; and increased interest in application event management.
Rapid application development (RAD) poses challenges to DevOps. If development and testing take place in different hosting, deployment and integration environments than the one used in production, it reduces the value of early testing and increases the number of different hosting environments. That disconnects testing and production, which, in rapid development, will surely affect the pace of releases.
Amalgamate your tools
You won't find a single DevOps tool that can become a do-everything suite for all your needs, so you must integrate all of your RAD tools. RAD needs integration from development through production, which means DevOps tools must integrate with version control systems and development tools -- and even deployment and orchestration tools.
IT calls this process GitOps, and it is the most significant trend in the DevOps evolution. The term comes from Git, the near-universal repository technology used for source code version control. With GitOps, teams use a repository to unify code configuration, parameters and more, all in a single place. GitOps pioneers call that repository a single source of truth, which means, by design and under the control of development, testing and deployment practices, the repository holds everything about an application.
GitOps uses Git to store software versions plus all the configuration data, orchestration parameterization and control, and even test data associated with each version of an application -- all likely in YAML form. The Git repository and its tools ensure that everything related to a software version, not just the code, synchronizes and conforms to governance or security requirements.
However, this GitOps approach means IT must commit all of its work on an application to the repository, including test data or YAML-authored test data generation policies. The quality of the repository data is the linchpin of the integration, a means of making all the RAD tools compatible with a common vision of the app dev process -- even though the tools will likely not fully integrate at the API level. GitOps, in fact, makes evolved RAD practices more modular.
This common data structure must drive DevOps, and developers must author it during early development and testing phases. Many DevOps and RAD tools support YAML, which makes the language an important component of these evolved development practices.
Enterprises aim to manage applications throughout their production lifecycles, not just until deployment. For that to work, DevOps tools must include the ability to recognize and generate events, alerts or triggers, which signal conditions that require operations work; this can include tasks like redeployment or scaling. Event handling worked its way into the DevOps process over the last five years, but that doesn't go far enough.
Production lifecycle management carries such critical importance that testers must evaluate it to the same extent that they do with code. Event handling in DevOps should roll back into early development and testing and follow the code through the whole development cycle. The needs of the production lifecycle accelerate organizations' shift to GitOps.
GitOps is especially important to DevOps evolution because Git repositories easily adapt to declarative DevOps parameters. This approach aligns with alert events that DevOps tools typically generate when there's a divergence between the goal state and the current state. Align the declaratives in the repository with the version being run to receive alerts and address these discrepancies. Obviously, this means that GitOps more easily adapts to declarative models of DevOps than imperative models.
Ultimately, the main benefit of a repository-based, GitOps-like model is that it makes everything declarative. Consequently, that means fixed assets, fixed resources and fixed requirements are all unnecessary and, in fact, counterproductive. This is why GitOps is a natural fit for RAD and also facilitates things like low- or no-code and self-serve computing models.
DevOps must evolve, especially as containers and orchestration transform to better handle RAD. DevOps and container orchestration are largely mutually exclusive practices. When you add CI/CD to the container mix, as CloudBees Core for Kubernetes Continuous Delivery attempts to provide, you can create a more efficient and sustainable deployment model than traditional DevOps. GitOps could reposition DevOps as a union of containers, virtual machines and bare metal in one virtual future.