# Distributed config management workflow **URL:** \ **Category:** Pipeline Integrations\ **Created:** [July 25, 2019, 3:12pm UTC](https://community.shotgridsoftware.com/t/distributed-config-management-workflow/232 "2019-07-25T15:12:38Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![philip.scadding](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/philip.scadding/32/30_2.png) [@philip.scadding](https://community.shotgridsoftware.com/u/philip.scadding)\ **Post date:** [July 25, 2019, 3:12pm UTC](https://community.shotgridsoftware.com/t/distributed-config-management-workflow/232/1 "2019-07-25T15:12:38Z")
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](https://developer.shotgunsoftware.com/tk-core/initializing.html#distributed-configurations) setup. My personal recommendation would be to do the following: 1. Assuming your project already has a “primary” `PipelineConfiguration` entity with an uploaded config, I would create a second one called `dev`. Set a [dev descriptor](https://developer.shotgunsoftware.com/tk-core/descriptor.html#pointing-to-a-path-on-disk) 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 `PipelineConfiguration` entity to your self: 2. 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: ![Change_configuration](https://global.discourse-cdn.com/shotgunsoftware/original/1X/f70c5b9b54d46ca3cf3cf1c312de707ce5b257bc.png) Using a dev descriptor also gives the added benefit of being able to access the **Check for config updates…** option. 3. 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 Config` field. Then when your user’s open the project in Shotgun Desktop, it will download the latest version of your config automatically for them. 4. **[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. Other people may have other suggestions please feel free to share your thoughts. ---
**Author:** ![philip.scadding](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/philip.scadding/32/30_2.png) [@philip.scadding](https://community.shotgridsoftware.com/u/philip.scadding)\ **Post date:** [August 1, 2019, 9:34am UTC](https://community.shotgridsoftware.com/t/distributed-config-management-workflow/232/7 "2019-08-01T09:34:54Z")
Split this topic on August 1, 2019, 9:34am UTC 3 posts were split to a new topic: [Multi platform Git descriptor paths](https://community.shotgridsoftware.com/t/multi-platform-git-descriptor-paths/400) ---
**Author:** ![Ricardo\_Musch](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/ricardo_musch/32/405_2.png) [@Ricardo\_Musch](https://community.shotgridsoftware.com/u/Ricardo_Musch)\ **Post date:** [August 7, 2019, 2:26pm UTC](https://community.shotgridsoftware.com/t/distributed-config-management-workflow/232/10 "2019-08-07T14:26:26Z")
What folder do we zip up though? the config folder? – core – env – hooks Or the more root folder? – config – install – cache ---
**Author:** ![philip.scadding](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/philip.scadding/32/30_2.png) [@philip.scadding](https://community.shotgridsoftware.com/u/philip.scadding)\ **Post date:** [August 7, 2019, 2:37pm UTC](https://community.shotgridsoftware.com/t/distributed-config-management-workflow/232/11 "2019-08-07T14:37:42Z")
Hi Ricardo Welcome to the forums, and thanks for the question! In my example, I was assuming you already had an uploaded config, in which case you would be downloading that and then zipping it back up again once you had made your changes. If you were starting with an already existing centralized config then you would have something that looks like this: ![paint_drying](https://global.discourse-cdn.com/shotgunsoftware/original/1X/ae59677067cb77d044e4e200b51620904a64ba90.png) In which you would zip up the highlighted “config” folder, but this is a bit different there would be a few extra steps to take to convert a centralized config to a distributed one. I’ll update the post above with a few more screenshots to make it clearer, about what you should expect at each stage. It might be good to have a different topic about going from a centralized config to a distributed one. Cheers Phil ---
**Author:** ![nedwilson](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/nedwilson/32/679_2.png) [@nedwilson](https://community.shotgridsoftware.com/u/nedwilson)\ **Post date:** [March 18, 2022, 2:40pm UTC](https://community.shotgridsoftware.com/t/distributed-config-management-workflow/232/12 "2022-03-18T14:40:54Z")
In this type of workflow, is it still possible to use the “tank push\_configuration” command? I used the “New config sandbox…” option inside the SG Desktop app. This creates a local copy of the Primary config on disk, but does not localize the core. When I run the tank command, I can only access it by going into the Terminal and doing the following: ```auto cd ~/Library/Caches/Shotgun/_SITE_/pXXXcYYY.basic.shotgun/cfg ./tank ``` If I run tank with the push\_configuration option, I get a Python TypeError: expected str, bytes, or os.PathLike object, not NoneType Do I need to run ./tank localize first? Change my PYTHONPATH environment variable? Both? I should mention - zipping up the dev config sandbox and replacing the uploaded primary config works as expected. Just wondering if we should still be using the tank command. ---
**Author:** ![Ricardo\_Musch](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/ricardo_musch/32/405_2.png) [@Ricardo\_Musch](https://community.shotgridsoftware.com/u/Ricardo_Musch)\ **Post date:** [March 23, 2022, 11:22am UTC](https://community.shotgridsoftware.com/t/distributed-config-management-workflow/232/13 "2022-03-23T11:22:56Z")
I think only a few tank commands still work in a distributed workflow. I would recommend setting up your configs as git repos so you can just push/merge/pull that way. ---
**Author:** ![nedwilson](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/nedwilson/32/679_2.png) [@nedwilson](https://community.shotgridsoftware.com/u/nedwilson)\ **Post date:** [March 23, 2022, 9:14pm UTC](https://community.shotgridsoftware.com/t/distributed-config-management-workflow/232/14 "2022-03-23T21:14:56Z")
I’ve done this in the past, but now with most users working from home, this can get real tricky. You either have to require the user to be connected with VPN in order to access a private GIT repository, or you have to give them credentials to a public repository. Far easier to manually zip up a config directory and upload it to the PipelineConfiguration in the web UI. Thanks for the clarification about tank commands, I will proceed accordingly. ---
**Author:** ![Ricardo\_Musch](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/ricardo_musch/32/405_2.png) [@Ricardo\_Musch](https://community.shotgridsoftware.com/u/Ricardo_Musch)\ **Post date:** [March 24, 2022, 7:56pm UTC](https://community.shotgridsoftware.com/t/distributed-config-management-workflow/232/15 "2022-03-24T19:56:27Z")
You can still do that with my suggestion. You would do the push/merge/pul etc in a dev pipeline config pointing to a local git folder. Once you have a new stable release you localize all the apps/frameworks with the `tk-core/developer/bake_config.py` script and have it zip up a new release for you. Even better, build a webhook so you can have this all be done automagically from a github release or a push to a specific branch.