In November 2017, a rail company in Japan issued a public apology after one of its trains departed 20 seconds earlier than planned. What might sound like a PR stunt to outsiders is a matter of concern for Japan, where the average train arrives no later than 42 seconds behind schedule. A paper on the punctuality of Shinkansen trains attributes this phenomenal record to three factors:

• Trains run on dedicated tracks and are monitored by modern signalling systems

• Operational routes and departure times are managed by computerized systems

• Staff is trained to follow standard procedures under normal conditions but make quick decisions when things get dicey.

Add these things together, and you suddenly have a recipe for an engineering miracle — whisking huge numbers of passengers across great distances while running a solvent business.

Japanese trains are a good metaphor for the software development process. Just like railway companies need isolated tracks, automated signaling systems and trained operators to make trains arrive on time, development teams need robust infrastructure, automated integration suits and engineers trained in the principles of DevOps to deliver high-quality features on time and within the budget. A recent study found that teams adopting modern deployment practices see dramatic improvements across four key metrics: lead time, deployment frequency, mean time to restore (MTTR) and change fail percentage. This leads to superior software performance and, by extension, a lasting competitive advantage. The puzzling question is, if DevOps principles are so effective, why don’t more teams adopt them?

Legacy CMSes hold back adoption of DevOps practices

Traditional CMSes, especially the high-end ones, offer editors an easy way to create, preview and stage their content before merging it to production.But when it comes to updating content structure or introducing new features, developers are left to fend for themselves.

Engineers tend to respond to the problem by setting up a copy of the website to be used for QA and staging purposes. It does the job in the short run, but it buries the team in the long run. There are the obvious costs: server bills and extra licenses eat into the team's budget while manual data migrations consume working hours. These pale in comparison with the psychological toll of shipping changes to a monolith application powering a multi-million-dollar business. Think grueling multi-day deployments preceded by month-long code freezes. And heaven forbid anything goes wrong when deploying changes. It can take a whole day to restore the old version of the website.

The more recent crop of content management platforms take developer productivity much more seriously. They offer powerful APIs and boast cloud-first architecture. Yet with respect to building new features and deploying changes, developers are still left to figure things out for themselves. For example, some vendors allow content entries to be grouped and published to environments serving different purposes. This way, developers can preview and test code without running a parallel instance of the website. But deploying new features still forces developers to go through the nerve-wracking task of applying changes to a production backend and requires them to define elaborate mitigation strategies for dealing with deploys gone sour.

Building DevOps pipelines with environments and migration tooling

Having seen how other content platforms handle software deployments, we felt like we had to go back to core principles and put ourselves into the shoes of engineers tasked with delivering new features. A lot of that thinking was captured in the CMS as Code whitepaper we published a few years ago. To turn that vision into the right tools for our users, we articulated a set of assumptions to guide our product efforts:

• Developers want to build new features in isolation

• Developers want to test new features against the production data

• Developers want to automate the migration process

• Developers want an easy way to recover from bad deploys

• Developers want their changes to happen instantaneously

With our eyes firmly set on these constraints, over the last two years, we enabled our users to make instant copies of their production data with environments and made it easier to apply content model changes programmatically with the Migrations DSL. Today, we are introducing the missing piece of the puzzle: a way to seamlessly promote content and feature changes to production with environment aliases. Development teams can create a master alias and swap the environment powering their production website with a single click.

While it might sound like a small feature, its impact is huge: Contentful customers now have a safe way to roll out changes, initiate instant rollbacks and fully embrace DevOps workflows.

Working with deployment pipelines in Contentful

Here’s how we envision the process of deploying changes using a master alias:

1. Developer clones the master environment and uses this development environment sandbox to develop and test a new feature with actual production data.

2. When the feature is ready to be deployed, the developer prepares a migration script that will modify the existing content model to support the new feature.

3. The developer clones the master environment again and runs the migration script against the new development environment release.

4. The continuous integration (CI) suite runs a set of tests to verify the changes inrelease and, if all of them pass, marks it as ready for a release.

5. The developer (or the CI suite) updates the master alias of their space to point to release, making the new feature appear on the website.

6. (Optional) If for some reason the changes have to be rolled back, the developer can update the space master alias to point to sandbox again.

Find out more on deploying changes using environment aliases, rollbacks and more in this tutorial.

It's easy to see how this new set up enables developers to deliver new features more productively than before. Sandbox environments make developing new features a breeze. Migration scripts create a paper trail and automate the process of applying changes. And the master alias offers an instantaneous swap (less than 250 ms) between the current and new branch of your content.

How to get started

The great news is that environment aliases are available free of charge on all space types. And if you’re wondering where to start, our developer evangelist, Shy Ruparel, put together a tutorial video to get you started as well as a step-by-step guide explaining how to use environments, migrations and aliases to create a continuous delivery pipeline with CircleCI.

Adopting DevOps principles is a sure-fire way to level up the quality of your digital projects in 2020. Ready to try it out? Give environment aliases a spin!

Subscribe for updates

Build better digital experiences with Contentful updates direct to your inbox.