An upcoming release of Remote Config will update Environments to improve functionality between Unity Game Services. These changes focus on the Environment Name. Environment IDs will remain unchanged and unaffected, as will all delivery of your Remote Config settings. You do not need to update the remote config package(s) in your existing projects or make changes to any existing builds after these changes have been made.
What do I need to know?
Remote Config allowed the Environment Name field to contain the UTF-8 Character set and allowed for users to choose the default environment. Going forward the Environment Name field will be restricted to only allow lower case alphanumeric characters, hyphens, and underscores.
For Legacy Packageversion users 1.0.x we will continue to support the Release and Development environment model; however, Release will be renamed to production.
What do I need to do?
For all Remote Config Customers that have environment names that do not meet the new constraints we will be modifying Environment Name to the limited character set after Friday, July 30 2021.
If your names are not updated, our team will adjust Environment Names that do not conform to the new standards as follows:
The Environment that is marked as default will be renamed to production (all lower case characters).
Any existing environment named production that is not the default will have _migrated appended to the name, e.g. production_migrated
Any environments with a space character in the name will have that space replaced with an underscore â_â.
Any environments with non alphanumeric characters will be converted to migrated_env#.
For multiple environment names numbering will start at 1 and increment in order of EnvironmentID for the Project.
You are able to make these changes yourself to accommodate the new environment name scheme; if you would like to yourself. Please make the changes by Friday, July 30 2021.
These changes will allow for greater interoperability between Environments functionality that is already available, and planned in other Unity solutions. . We appreciate your understanding, and going forward to provide a more unified experience across our platform.
If you have any questions or require assistance please reach out through the forums to the Remote Config Team.
[UPDATE: Changed date from TBD to Friday July 30 2021]
Our setup is built on the assumption that the default environment is not production. This is specifically to avoid mistakes during development affecting our production environment. If I understand this right, the ability to default to a non-production environment is going away completely.
While I understand there must be a good reason for this internally, from the outside perspective this just seems like features (that we relied on) being cut, causing breaking changes, with one weekâs notice during the summer vacation season no less.
I hope there was a very good reason for the rushed schedule on this.
Hi at_, thanks for your reply. We hear your concern, and Iâd like to offer a bit of context for this change.
First, I should emphasize that this change will not break or alter your existing Remote Config settings delivery to your users. If you have a game build in the wild that requests settings from the default Environment, they will continue to retrieve the exact same settings after this change. If you have a game build that explicitly targets a non-default Environment ID, they will continue to retrieve the settings from that non-default Environment.
What is changing is that we are conforming Environment names so that the default environment is called âproductionâ going forward, and also that any additional custom Environments conform to an alpha-numeric syntax naming scheme.
We are making this change so that Remote Config can take advantage of a Unity-wide Environments initiative that will be rolled out later this summer. Instead of managing Environments that only impact a single Unity cloud service, this will allow you to control Environments that span services. In order to coordinate with multiple Unity services (some of which have not yet integrated with this Environments initiative), we needed to standardize how we treat the âdefaultâ, so that all Unity services can expect the same thing for this user flow.
I hope this context helps - if you have more questions or concerns, please reply here or you can DM me and I can try and work out how we might be able to help with any particular challenges you have.
We also want to continue with our default environment not being production to avoid issues in development and staging from affecting live production.
Our environments used to be setup like:
dev (default)
staging
prod
Ahead of this change our workaround is to now have a true production environment called âprodâ and avoid using the âproductionâ environment.
production (default, donât use this)
dev
staging
prod (this is real production)
Pretty confusing. Maybe âdefaultâ would be a better name for the default environment?
We are locked in with using production as the default environment name going forward.
Based on the environments you listed this is what the migration would look like:
Your Current Environments | Environments Post Migration
dev (default) -> production (default)
staging -> staging
prod -> prod
If you would like to keep the name dev, and have builds point to that environment you can reference it by the EnvironmentID, as it would not be the âdefaultâ environment served to builds that do not specify an EnvironmentID.
Thank you for the response, I see now that while the environments certainly get renamed in a potentially confusing manner, this shouldnât break anything. However, Iâd like to ask a question about a different affected use case.
Previously, the EnvironmentID-less configuration fetch call directed you to the current default. This enabled changing the entire environment of the built and released application simply by moving the default environment tag to a different environment.
This no longer seems possible, so what is the suggested replacement workflow? My first idea was applying a rule that changes all of these parameters based on a condition, but that condition would have to be a remote config setting in itself and that doesnât seem to be possible. Is there an alternative workaround Iâve missed?
Copy config settings from a non-default environment to the default production environment. This can be done manually, or we also support an API to automate the transfer of config settings between environments.
Re-create any rules needed in that new environment manually - or using our APIs to automate the creation of these rules in the default production environment.
Our near term roadmap includes adding functionality to copy the contents of Environments between each other which will make transferring Settings, Rules, Campaigns to and from the default much easier.
@JeffDUnity3D , thereâs no code to refer to other than a basic FetchConfigs call without an environmentID set. The âconditionâ in the previous workflow wouldâve been the default tag, switching which config the game fetches with no environmentID set.
I suppose it could be possible to fetch a new environmentID as a setting from the default config and then refetch with the new environmentID. This would certainly allow retargeting a published game to different environments in production.
As for @tagh 's suggestion, If I understood this right, your idea would be to build tooling around the API to, rather than switch the environment the game points to, instead keep the environment static but replace all of its settings with the configs from other environments acting as templates.
This definitely sounds like it would work but does add management and tooling overhead compared to simply being able to point a live game at a different environment with a single click. Itâs comforting to hear that functionality to improve this process is on the roadmap.
I understand that this is probably not a common use case so thank you for your patience in discussing these concerns.
We expect environment creation be restored tomorrow, or this Friday at the latest. We apologize for the inconvenience - we will update this thread when service is fully restored.