I’ve seen the question come up a few times around how to test configuration changes and push them to production when using a distributed config setup.
My personal recommendation would be to do the following:
Assuming your project already has a “primary”
PipelineConfigurationentity with an uploaded config, I would create a second one called
Set a dev descriptor to define a location to your config on disk. (If you haven’t got a config on disk you can download the primary config and unzip it somewhere convenient where you can work on it and make changes.)
Make sure you restrict the
PipelineConfigurationentity to your self:
Here is what the config looks like on disk.
Note that I have mine tracked in git (you can see the hidden
.gitfolder in the image) so I can pull down changes and switch branches within this location on disk when testing and developing. I prefer using a dev descriptor rather than using the git or git branch descriptors as it doesn’t require me to change the descriptor each time I want to switch branch or if I make a new commit.
Once you’ve done that you can start making changes to the dev config stored on disk and test them on your project. You can test the config by switching to it in Shotgun Desktop:
Using a dev descriptor also gives the added benefit of being able to access the Check for config updates… option.
Once you’re happy with your changes to the config, it’s a case of zipping it up and reuploading the config to the “primary” configuration’s
Uploaded Configfield. Then when your user’s open the project in Shotgun Desktop, it will download the latest version of your config automatically for them.
[optional] Instead of zipping it up and uploading it straight to your primary config, I think it’s a good idea to track the config in a version control software such as git, so that you can see what changed and revert back more easily if something goes wrong.
- I would personally recommend using something like Github and push your dev configuration changes to the remote configuration on Git.
- Create a release of your config in Github, as we do with our
- Download the zipped release and upload it to your
Uploaded Configfield on your primary configuration.
It’s more steps doing this, but now you have the added knowledge of knowing which version of the config you’re using in production and you can more easily roll back to a previous version or check out what’s changed.
Other people may have other suggestions please feel free to share your thoughts.