If I’m satisfied with how my Dev bundle is running, and I’ve dutifly uploaded zipped addons etc., and I’d like to try it again in Staging.
It appears copying settings from my Dev bundle to the Staging bundle isn’t enough, as Staging still has the same addon versions it had before.
What’s the right thing to do? Do I duplicate and edit the Dev bundle, set that new bundle to the new Staging, and keep creating new Staging / Production bundles for each release?
If so, is that so I always have locked in untouched bundles which were previously in Production so I can easily revert if I’ve done something wrong? Rather than replacing addon versions / settings without easily being able to get them back? Is that the idea?
I think coming up with such workflow is considered personal preference.
It seems you are looking for a workflow for pushing changes made during development to a staging bundle where selected users in your studio can test things before pushing to production.
Key important concept to keep in mind is making releases.
When working with dev bundles you may have some local change in your local repo, and
it’d be great if you can commit your changes in a dedicated branch so that you keep your changes saved.
or maybe fork the addon you want to customize, commit and push your changes to it. but you may discuss forking with your studio because the fork will be public and opensource as the official repo is public. so your customization can be available for others.
When finished with coding, committing your changes, you can change the addon version in the package.py file to be something like 1.0.0+yourstudio.1 more info here.
then you may create a new tag in your clone so that you can quickly switch to that state of the code.
Then finally, run python create_package.py to create a zip package and upload it to your server.
You may simplify this process based on your preference, but the main point is to differentiate between code in progress and the code that reached a dedicate milestone. and, to create a clean package for your studio to use.
Once you build and update your package, you can create a staging bundle and start experimenting/testing. If things go well, you can re-use this package for production.
Another important thing to keep in mind so that you don’t get confused when you create a bundle and find out that an addon has some studio or project overrides.
Let me quote from How are settings organized? | AYON Help Center.
Addon settings are stored for each addon version and variant (not per bundle), that’s why the same addon retains its production and staging values when added to other bundles marked as production or staging.
You may also automate process in your dev environment e.g. here’s my dev environment setup AYON-Development-Workbench.
From Step 9. onward you can also undev the bundle and the set it to staging and later set it to production too… no need to create new bundles… but once it is staging it is immutable…
From Step 9. onward you can also undev the bundle and the set it to staging and later set it to production too… no need to create new bundles… but once it is staging it is immutable…
There is one downside to this I think, because settings are not stored on a bundle, but on a variant: production, staging or per dev variant. As soon as you unset dev, then set staging just be aware that likely you’re losing your dev setting overrides. (Which may or may not be what you want.)
Also, to speed up dev time definitely look into Mustafa’s Dev Workbench he mentioned here. Similar to him I e.g. have a quick shortcut in my IDE that essentially builds the package, uploads it to my server, restarts the server and sets it in my dev bundle. This saves so much time, especially if you’re dealing with testing server setting changes while developing.