How DevOps principles make Contentful a flexible tool (and not a wrench in your works)
I’m sure you’ve heard of Conway’s law — it’s the idea that organizations are fated to replicate their internal structures in the software systems they build, for better or for worse. Common wisdom would suggest that the inverse is true too: The systems we use have an undeniable effect on our processes and how we interact with each other.
It’s like the old saying, “when all you have is a hammer, every problem is a nail,” taken to its logical conclusion. Our effectiveness is limited or enabled by constraints that are built into the tools we have available.
Companies that build software used by teams and organizations need to be aware of this. Especially in my team — Developer Workflows — we think a lot about how the features we build affect how our customers’ teams can work together. We don’t want to impose processes; we recognize that there’s no one right way of using Contentful. So we’ve tried to keep the platform as flexible and rooted in agile methodologies as possible, creating out-of-the-box tooling that’s easy to integrate into different workflows and stacks. Our goal is to make it a tool that adapts with you, not a wrench in the works.
No software is agnostic (but DevOps is a safe bet)
Recognizing that no software is completely neutral, we of course had to make some bets. Still, supporting DevOps principles is a safe bet if there has ever been one. The annual State of DevOps report consistently shows that companies with higher adoption of DevOps practices get better results across four key metrics. In the 2019 report comparing top DevOps performers to lowest performers, top performers saw 208 times more frequent code deployments, 106 times faster lead time from commit to deploy, 2604 times faster recovery from incidents and 7 times lower change failure rate.
How does this translate into designing a content platform?
The faster the pace of development, the more it becomes critical to have an easy way to iterate on content models. One of our customers, Loblaw Digital, went from building nine digital experiences in the span of seven years, to planning for 150 in the following two years. With this rate of change, it’s impossible to know what you’ll need from a content model in a month or two, let alone a year. This is where the “DevOps infinity loop” comes in. To maintain your content model, you need to integrate it in a structured, controlled way into your applications. And why should deploying these changes work differently than any other best-practice deployment?
This argument goes double for larger organizations. Most of our users aren’t solo developers; they’re working within a development team, maybe as one of several teams that collaborate with each other. The more complexity is introduced into the system, the heavier the demands on deployment orchestration — on speed, on recovery times, and on reducing the risk of human error.
Space environments let you develop and test in isolation
Space environments are a major feature designed specifically to translate DevOps principles into content model deployment. They are entities within a space that let you create and maintain multiple sandbox environments. Not only do they contain the exact same content model as you have on your master, but real content as well.
With it, you can develop features in isolation on an exact replica of your production environment. No wasted hours setting up and maintaining local instances of your CMS just to fix a bug, or creating local databases to shuffle production content to and from instances.
And it’s not just the production environment you can replicate; you can clone any environment. This can be incredibly helpful for QA testing because you can test different content variations with a reliable, stable set of content maintained in dedicated environments.
CLI tooling makes content model changes repeatable
Another core principle we adhere to is treating content models as code, or quite similar to a database. Just like in evolutionary database design, the system needs flexibility and automation in order to stay adaptable.
For this purpose, we built CLI tooling. With the contentful-cli, you can manage spaces, environments, content types, generate initial migration scripts, and run imports and exports if you need to create and restore backups. But the real magic happens when you use it to automate testing and deployment. When each step of your deployment pipeline is codified and tested, it leads to less human error, faster deploys, and (hopefully) no more pager duty alerts at 2 a.m.
This gets us into new territory: agile content modeling. When you can code changes to your content model and use the CLI tooling to run scripted migrations, you make them repeatable and automatable. This lets you iterate and evolve your content model as your business and content requirements change. You don’t need to have the perfect design for your content model, because when plans inevitably shift, “perfect” won’t mean the same thing anyways.
Environment aliases takes automation to the next level
We recently released environment aliases, the missing link to pull our DevOps chain together. An alias is a static identifier that you can target at any environment. The master environment “floats” on top of your space environments, letting you quickly promote any environment to production, or roll back in case of emergency.
The implications are huge for such a seemingly small feature: It lets you use space environments and scripted migrations together to build a streamlined, automated deployment pipeline, complete with CI/CD. You can read more on how to implement different use cases for environment aliases here, or how to build them into a CI/CD pipeline here.
Deploy faster at scale
Consumers are getting used to seeing more novel, streamlined digital experiences, meaning development teams are under pressure to deliver faster. The last thing you need is a CMS that forces more manual steps, complicates workflows between teams, and makes for slow, risky deployments. The software in your stack has a significant effect on what your teams are capable of delivering in a given amount of time.
This is why we built DevOps principles into our platform. We hope what we’re building gives you the tools to deploy faster, cleaner, and maybe even with less stress — no matter how ambitious your products are. Expect even more from our team in the future, especially to help with bigger, multi-team setups.
In the meantime, give environment aliases a try — and rest easier when you deploy!
