Keep your production moving with parallel activities

Don’t let your development block production

Unquestionably, Platform.sh’s biggest feature is its environments. Whatever your application, framework, or runtime, your project is supported from the start with Git. Branch off of production and get the same image on a development environment, complete with production data. Make changes and merge back into production, and the same image carries over there too, eliminating merge downtime.

Each one of these events—branch, commit, merge commit—as well as those Platform.sh events not tied to repository actions—redeploys, backups, access, and variables—make up activities on your projects. For some time, however, activities interacted in ways that caused unexpected delays across environments; an activity on a non-production environment would not begin until the preceding activity on production had completed. Unfortunately, the opposite was also true, resulting at times in delayed deployments for your production sites.

We’re happy to announce a new feature (which you may have already noticed on your projects) that puts an end to these delays: parallel activities.

Simultaneous activities and easier crons

Parallel activities allow for two activities across all of your environments to occur simultaneously. A very simple example of this is shown below, where a production redeployment and a backup creation on a development environment are both shown in the project’s Activity section.

Parallel activities especially come in handy when it comes to crons. A production cron job no longer limits when a non-production environment can be deployed, and commits in progress do not delay that cron job.

How it works and what it means for you

Before the update, the Platform.sh activity queue was replaced with separate queues: those that handle integration activities, backups, crons, and our default project activities. Those queues could all occur independently and simultaneously, with activities serialized per queue. That meant that while activities between environments were unblocked, there could still only be one activity per environment at the same time.

With the update, production activities come with a priority level over the other environments when they enter a queue. It’s still possible for a development activity to block changes to production, but far less likely than before. As soon as that production activity enters, it jumps to the top of the queue automatically.

As the feature rolls out, there will be no major changes to your projects. You'll just notice even less influence between environments than there already was. Hopefully your development speed continues to improve as a result.