Launch fast, iterate faster: How to evolve your digital products with environments

One of the things we regularly do at Contentful is study our most successful customers to understand how they differ from the rest. As we were going through this exercise back in the winter of 2016, we were running into a lot of blind alleys. We had analyzed many variables - from number of API calls and published entries to traffic volume and team size - but none of these metrics could predict with certainty whether a new signup would turn into a successful customer.

Just when we were almost at the end of our wits, we’ve noticed there was one metric which correlated closely with the success of our customers—that metric was the number of spaces. Not the number of projects, mind you, but actual spaces. Companies that were more innovative or had more experienced development teams tended to have a bigger appetite for spaces. So we set out to investigate what feeds this appetite.

Treating your content like code

Talking to customers was eye opening—many of them said that migrating to Contentful has changed the way they think about digital projects. Suddenly, they found themselves capable of using latest web technologies, launching new projects ahead of time, and directing their efforts at customer-facing features rather than spending their budgets on backend maintenance.

So where did spaces come into the play, we asked? Turns out that launching a new project is just part of the equation. Every successful project begets a steady stream of requests: companies need to react to changes in customer preferences, work on seasonal promotions, and look for ways to to alleviate the load of the editorial team. The challenge that development teams face is how to satisfy these requests quickly while reducing the risks of accidental errors or production downtime to a minimum.

One solution to this problem, explained the developers we interviewed, was to mimic their tried-and-tested approach of working with software changes. Continuous delivery (CD) / continuous integration (CI) workflow specifies that any software changes, to be introduced to the customer-facing application, must first go through a series of steps where they are developed, tested, and previewed in isolated environments which look like carbon copies of the live application. Once the development team is certain that the changes are safe, they are released into the live application.

The multiple spaces provisioned by our successful customers was an ingenious way in recreating the CD/CI workflow in the context of the Contentful platform.

One space, many environments

We were impressed with the creativity of our customers—they were taking the concept of the content infrastructure to its logical conclusion faster than we've anticipated. When we realized this, we kicked off an internal project to help them get there faster and more comfortably.

The early adopters made us aware of several points of friction:

• Copying content from one space to another on a developer’s computer was time-consuming and, with a lot of data, could trigger API rate-limits

• Proliferation of spaces within the organization made it more difficult to enforce access privileges

• Swapping an existing production space with a new space risked introducing changes that broke the customer-facing application.

The introduction of environments and Migration DSL addresses all the points above, offering businesses that use Contentful a fast, reliable, and transparent way to work on changes to their content structure. A carbon copy of your live content can now be provisioned in less than a minute, while migration scripts offer a clearly documented, step-by-step methodology to apply changes to your content model and populate thousands of entry fields with the right data. Once the changes are integrated into master environments, development environments can be deleted without any risk to your live data. And when teams collaborate within the same space, it’s easier to set and enforce access permissions.

The workflow for updating the website at the Nordic Choice Hotels (NCH) shows how this process works in practice. The development team at the NCH manages a portfolio of digital properties that includes a booking website, partner portal, and a mobile app for guests. Even a minor hiccup can throw a spanner into day-to-day business operations, so the team runs a barrage of automated tests on every website update. These are designed to flag potential bugs, missing content, and longer-than-usual response times.

The process consists of four steps:

• Creating a carbon copy of the live website, which acts as a staging environment to run tests

• Running the migration script, which updates the content model within the staging environment to reflect the necessary changes

• Now it’s time for running automated tests. If all of them pass, the changes are safe to deploy and developers run the same migration script on the master environment that powers the live website

• If the tests flag any problems, they can be addressed by modifying the migration script and verified by repeating the whole procedure

Migration scripts, used to update the content model, also provide a natural audit trail; since every change is documented and stored in the project repository. If the team needs to revert them at some later point, they can easily do so by examining the script that introduced the stray update.

Define your workflow with webhooks and permissions

While space environments are available since mid-May, there are two important additions we are introducing today. You told us that limiting access to environments to space administrators is unnecessarily restrictive. So from now on, space administrators can bestow access to environments to any role within the space; though, as the CMS as Code article makes it clear, we do not recommend letting editors, authors, or translators author content within environments.

Secondly, we worked to add more granular filtering options to space webooks. This enables development teams to send notifications to third-party services and trigger desired responses based on the actions happening within the space environments. For example, you can configure content model changes to be automatically promoted to a staging environment if they pass automated tests.

Our developer evangelist team has put together a handy tutorial on how to integrate environments into a CD/CI pipeline, in case you are curious to get started with it right away.

Faster deployments, fewer mistakes

Since the launch of space environments two months ago, they were adopted by more than a third of our enterprise customers and six of ten most-invested organizations. We asked customers what convinced them to add this feature to their toolbox and the answers ran a gamut:

• Developers mentioned that space environments allowed them to prototype new features without risking accidentally breaking the website or wasting hours to setup a new environment

• Team leads mentioned the predictability of working with environments and ease of pinpointing changes introduced with each revision

• For managers, the key advantage lied in the reduced overhead: with the entire team working in the same space, they could be certain the editorial team would continue working in the right place and development teams could avoid mistakes.

It’s not difficult to see how these benefits ultimately produce a faster, more reliable, and scalable way of evolving your content. We hope the introduction of this feature will help more development teams out there become quick at shipping digital projects and good at avoiding downtime.

How can I start using space environments?

Space environments are automatically included in your space for all new customers. If you are on the legacy plan, contact our support team to check the availability of space environments.