DevOps Hack: Use a DevOps-Ready CMS

The efficiency DevOps brings to organizations is enormous. According to BCG, DevOps leads to a 15-25% overall reduction in IT costs. This is no doubt due to the core tenets of DevOps like automation, CI/CD, and flexible tooling. For most software projects, the DevOps approach leads to a faster time to market and reduced IT and development costs. The problem is that not all software is built with DevOps in mind.

CMSs have been notoriously difficult for IT operations teams to manage because they’re built for developers and marketers first. The majority of CMSs - even modern ones - fail to enable DevOps best practices, and IT operations teams bear the burden. Let’s look at the main challenges DevOps teams face, and how a comprehensive “DevContentOps” approach with a DevOps-ready CMS can ease the burden.

The Challenges DevOps Teams Face Today

When it comes to CMSs, both traditional and headless CMS options were built for particular stakeholders. Traditional CMSs focused on the need for content authors to build websites without coding. Headless CMSs, on the other hand, were built for developers to easily integrate with a variety of frontend frameworks and backend systems. Neither of these solutions considered IT operations as an equal stakeholder. These are some of the ways most CMSs prevent DevOps best practices.

No Continuous Integration

Continuous integration (CI) - or merging code frequently - is key to avoiding significant conflicts during the development process. With CMSs, however, code and configurations are developed entirely separate from the content that is authored by business users. This means everything related to a content-driven application is merged infrequently, and this creates complicated processes that can slow down development dramatically. Traditional CMSs fail to support continuous integration.

No Support for Multiple Environments and Continuous Delivery

IT operations set up multiple environments to increase productivity and reduce downtime during software development and deployments. Most CMSs, however, are built on top of either SQL or NoSQL databases that are hard to keep in sync across environments. In many cases, data syncs require development and content authoring to stop while IT operations does a database dump and load procedure. A CMS isn't DevOps ready if it affects developer workflows and leads to content authoring downtime. CMSs, therefore, prevent continuous delivery (CD) - the deployment of code, configuration, and content quickly and efficiently.

No Freedom of Tooling

CMSs usually come with a repository (ie. a SQL database) that's specifically for content, and a variety of proprietary tooling. This means the CMS dictates the technologies that developers must use to build content-driven apps. Developers would need to work with whichever data storage technology the CMS uses to access content, and integrating with the CMS could require proprietary technologies that have a steep learning curve. Traditional CMSs, therefore, stifle innovation by preventing developers from using the latest IDEs, frameworks, tools, and languages.

Use a DevOps-ready CMS to Reduce the IT Burden

The DevOps hack for maintaining a CMS is readily apparent - use a CMS that's built for DevOps. But most modern CMS vendors aren't providing a DevOps-ready solution. Reducing the burden on IT teams, however, can have an enormous impact on the total cost of ownership for your CMS platform.

CrafterCMS is built for all stakeholders - from development and IT operations to content authors. That's why we call it the DevContentOps approach. Here's what we mean:

• Keep Environments Synced: Crafter is built on top of a Git-based repository, eliminating the need for database dump and load scenarios. IT operations can easily keep environments in sync. Even better, developers can keep all environments in sync with a push of a button, without any support from IT ops needed. This makes the packaging and release of content-driven apps with CI/CD practices much easier.
• Technologically Agnostic: Crafter is language and framework agnostic, so developers are free to use whichever technologies can get the job done best. Its API-driven architecture means the platform can integrate with a multitude of frontend frameworks and backend systems. Leveraging Git -- and Git-based services like Github, Gitlab, and Bitbucket -- and other standard tooling makes development even more frictionless because it eliminates the learning curve of proprietary technologies for development teams.
• Centralized Repository: Crafter has a centralized Git-based repository for code, configuration, and content. This means merging is straightforward, and the platform is CI/CD ready by default. IT teams can implement automated processes using whichever tools they choose, such as Jenkins or Bamboo. And that process can include both code and content. Moreover, developers have the flexibility to choose what code to put into Crafter’s git-based repository. One distributed git-based repository for everything shortens the development lifecycle of content-driven apps.

DevOps revolutionized the way software is developed, but left content management out of the equation. No more! With the Crafter’s unique support for the DevContentOps process, companies can take an innovative approach to creating great digital experiences for their customers. Developers, IT operations, and content authors can work together to produce cutting-edge content-driven applications that drive real business results.

Don’t let traditional CMSs hold your tech team back, and hack your digital transformation with a DevOps-ready CMS. For more on CrafterCMS and a headless CMS, check out The World of Headless CMS: Everything You Need to Know About Headless Content Management.