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:
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?
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.
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:
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.
Here’s how we envision the process of deploying changes using a master alias:
masterenvironment and uses this development environment
sandboxto develop and test a new feature with actual production data.
releaseand, if all of them pass, marks it as ready for a release.
release, making the new feature appear on the website.
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.
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!