This document explains how to apply migrations to the primary/main environment:
The requirement to create a forked environment, apply the migrations, and promote the environment to primary/main is a real impediment to how we work.
By the time we’re ready to apply one or more migrations to the primary environment, we’ve already applied them to our “development”, “test”, and “uat” environments. So we know they work, and we know our application works with them.
We can’t promote any of those environments to primary because they will contain non-production content.
So we’d like to be able to apply our migrations directly to the primary environment. The CLI can issue a warning or require a special argument to indicate we know what we’re doing. But this would make our lives a lot easier.
We just discovered a more serious issue with the “fork - apply migrations - promote” approach to applying migrations to the primary environment.
The name of the new environment will be different than the previous/original primary environment. And that means the environment name we pass in the X-Environment header to the API has to be updated every time we need to get migrations into the primary environment.
This isn’t a scalable process. It really needs an alternative approach.
We worked around the X-Environment issue to not pass this header when we’re deploying to production. If the header is not set it always uses to primary environment.
We have the same issue! Even if it’s possible to work around it, I think it should be possible to have a way to target the primary environment without having to take into account that it can change name
