We just realized that the requirement to fork the Primary environment in order to apply migrations means that the new Primary environment, after the fork has been promoted, will have a different name than the original Primary environment.
In our case, the Primary environment was named “main”. Now it’s named “primary-2023-10-19”.
This implies that we have to change the value we’re passing in the X-Environment header every time we go through one of these “fork - apply migrations - promote” cycles.
Further, it looks like there’s no way to rename an environment so that we can preserve the name we pass in the X-Environment header. Are we missing something? Is there a way to rename an environment?
The value we pass for X-Environment is a config setting in our deployed (to Azure) application. We can’t be required to change that every time we make content changes that don’t correspondingly require application changes.
+1 on this request, we have to change config settings every time we update environments and its a huge bottleneck.
Our alternative for this is to not provide a X-Environment header in production, since it defaults to primary. In staging and uat, we usually fork the current staging to staging-backup, delete staging, fork new staging to staging and so on. It creates downtime in staging/uat but thats what sacrifice.
Hey @roger, given the following scenario - is there a way to avoid downtime?
We have an SSR website that uses Dato CMS as the content layer. The Dato environment name to fetch the data is hardcoded as “main” in an environment variable that is set in the build pipeline.
To update a Dato schema, we do the following:
Create fork “my-fork” of primary environment “main”
In “my-fork”, make the schema update
Promote “my-fork” to primary
Rename old primary “main” to “main-snapshot-old”
Rename primary “my-fork” to 'main"
Between steps 4 and 5, there is no environment called “main” and therefore the website fetch to Dato has the potential to break because it is still hardcoded to look for “main”.
So after step 3, my-fork should immediately become the new primary, regardless of its name, with no downtime.
Does that help?
Separately, though, may I suggest that having some sort of caching layer (even if SSR), like ISR or a CDN cache, might be a good idea? Not just for the purposes of new schema versions, but also for intermittent network outages or accidentally hitting the rate limit, etc. The cache could keep serving the “last known good” version up to some reasonable TTL — even a minute would be fine. It would also save you some API calls. If that sounds interesting and it’s not something you’ve already considered, feel free to email us at support@datocms.com (or just start a new thread) to discuss that!
