DevContentOps: Headless CMS Meets DevOps

In a live presentation given at DeveloperWeek in San Francisco, Russ Danner (Vice President of Product at CrafterCMS) spoke about:

1. The exponential growth and power of technology
2. The demand for digital innovation in user experience as a result and the importance of IT teams embracing agile
3. DevOps practices in order to keep up.

Nowhere is this discussion more needed than in the digital experience platform space, due simply to the rapid pace at which new channels and other opportunities to engage with customers are introduced. Because headless CMS platforms separate the front-end from the CMS, they enable a nearly infinite amount of flexibility in terms of development tools and DevOps practices. It sounds like a match made in heaven.

But there is a catch.

The Developer, Marketer, Operations Disconnect

DevOps is all about redefining roles and leveraging modern tools and process to create harmony and efficiency between developers and operations. With digital experience-based innovation there’s a third constituent with their own work product, namely, content authors and the content itself which are not covered in the DevOps equation. This creates friction that manifests itself in the form of code and content freezes and long difficult deployments that impact the efficiency of both content authors and software developers alike.

When developing applications and sites that consume content it should be obvious that in most cases, the content is just as important as the code. Further, there is a kind of relationship or contract between code and content. To think that software developers can work completely independent of the content authors is naive. Developers have multiple environments to support their process that needs to be updated with content from authors. Moreover, content authors are often involved in various stages of development to provide feedback and user acceptance sign off. Content authors need to be part of the Developers plus Operations mix to see the full agile benefits of DevOps applied to digital experience applications. This is where Crafter’s unique support for the DevContentOps process extends the basic benefits of a headless CMS into the realm of true enterprise innovation (see Figure 6).

Figure 1. DevContentOps® Drives True Enterprise Innovation

This is where both traditional CMS and even the newest headless CMS solutions fall short: they don’t integrate content into the DevOps process in a seamless fashion. In other words, they don’t support a DevContentOps process.

DevContentOps aligns the workflow, tools and process of developers, content authors and IT operations in a way that allows each to do their jobs collaboratively without friction. Content may move backwards from production to lower environments “at the push of a button” without interrupting content authoring. New functionality created by software developers may move up through the testing and certification environments with ease. Deployments are dramatically simplified. Developers and content authors do not have to deal with code and content freezes.

Most systems, whether traditional, headless or hybrid headless, do not (and cannot) support DevContentOps. Why? Because nearly all CMS platforms are constructed atop either SQL or NoSQL databases, or JCR repositories that have at best, simplistic versioning systems and no ability to sync. Updating environments with new content or code requires time consuming and cumbersome export/import processes that impact the business and developers with content freezes and outages. The underlying storage mechanism and fundamental architecture is to blame.

What’s the solution? Technical innovation is required to support a tighter workflow of content and code within the development process. Rather than rely on a traditional approach like a database, CrafterCMS incorporates technology that already has had a huge impact on DevOps.

Crafter uses Git as its repository, providing a truly distributed approach to code and content management. Moreover, CrafterCMS’s implementation of its Git-based repository uniquely supports DevContentOps. It has a time-machine like versioning system that enables sync that makes moving code forward from development and testing processes out to production simple. Content can easily be moved back. There are no content freezes or development work interruptions required to update an environment. Software developers, IT operations and content authors are finally able to collaborate with one another without stepping on each others toes. Furthermore the capability relies on simple, well known, well understood Git mechanics. It’s extremely powerful but what’s more is that it natively plugs in to your automation and monitoring frameworks and toolchain.

Figure 2. CrafterCMS’s Git-based Repository Enables DevContentOps®

DevOps Vs DevContentOps: What’s The Difference?

DevContentOps isn’t about rethinking the dynamics of DevOps—it’s about transforming the way content authors, developers, and operations collaborate.

DevOps addresses traditional software applications, with no mention or support for the content that fuels those applications. Typically, applications contain software and content, but the content is managed separately from the software source code (i.e. software applications integrated with a CMS for content). DevOps, therefore, doesn’t address any of the requirements or features needed to fuel applications with content.

To make matters worse, most CMSs provide no support for DevOps, so there’s silos between development, test, and production environments. The content application templates, scripts, and code is stored in a source code control system while the content is stored separately in a CMS. This leads to a longer process for merging and testing new code before pushing to the production environment. In most cases, IT operations teams will initiate a content and code freeze while they manually sync everything across environments. This could lead to double publishing in some cases, and at the very least slows down content velocity for content authors. That’s because with DevOps alone, content isn’t integrated with the CI/CD process.

In other words, the DevOps methodology does not address any needs of content managers to collaborate with IT. Dev and Ops may be unified, but those two teams don’t make up the entire equation.

The Attributes of a DevContentOps Environment

In summary, here’s what makes up a DevContentOps environment.

• Traditional DevOps Support: Firstly, a DevContentOps environment supports a traditional DevOps environment by enabling seamless integration of traditional DevOps tooling for building, testing, releasing, and orchestrating content managed apps. Plus, DevContentOps Allows for the continuous merging of source code and content changes to eliminate large merge conflicts and streamline the dev/test/release/publish cycles of content apps.
• Collaboration: Enable software developers, IT operations, and content managers to work seamlessly together. Enabling cultural changes that improve the collaboration among dev, ops, and content teams
• Shorter Life Cycles: Shorten the life cycle, and increase the throughput of, delivering features, fixes and updates of content apps to production.
• Standardization: Enable parallel and frictionless development and integration of content and software features through standard tools and approaches such as branching and other related SCM capabilities eliminating the need for undesirable impacts including code and content freezes and double publishing.
• Continuous Publishing: Allow continuous publishing of content without any interruptions due to software dev/test/release cycles. Manage content packages (including associated code as necessary) as transactional units for continuous publishing/delivery
• A Centralized Repository: Managing all code, content, and configuration data in a single (albeit distributed) repository allowing for packaging and releasing all related items in a single publishing cycle.
• Developer Freedom: Allowing developers to use their tools of choice on top of the single code/content repo (IDEs, frameworks, languages, etc); not requiring some artifacts to be managed in a CMS and others in a SCM; not dictating certain dev or DevOps technologies
• CI/CD: Enabling continuous movement of code forward from dev to production/operations, and continuous movement of content back from production/operations to lower dev environments, facilitating CI/CD and traditional DevOps for content managed apps.

Start Innovating with Headless and DevContentOps

Customer experience leads to loyalty and loyalty leads to companies that are healthy and growing in all the right ways. Today, technology is driving customer expectations. The demand for new, easier ways to connect and engage with products, services and other devices in a seamless, targeted fashion is only going to grow. Astute, customer-focused companies are leveraging innovation as a key competitive advantage. Those who innovate the fastest and in the most scalable fashion will win.

Traditional CMS platforms cannot support all the new digital apps and channels, and are quickly becoming obsolete. Furthermore, most traditional CMS platforms aren’t ready for DevContentOps because they’re usually monolithic systems sitting atop SQL databases. Headless CMS architecture solves the multi-channel issue and offers significant DevOps advantages, but leaves the content editor without proper tooling. Going one step beyond, headless+ CMS platforms blend the authoring tools that content editors had with traditional CMS with the flexibility of headless and they’re ready for DevContentOps.

DevContentOps is the next step. Many of the benefits of DevOps are wasted if there is friction between content authoring and software development personnel and process. DevContentOps support brings these teams together through modern processes and repository technology so that they can collaborate together without friction while maintaining optimal tooling and efficiency for their role-specific tasks.