I am really enjoying the multi instance release functionality in the new beta, but had one question / idea come up.
I have one instance (an external app) that has just one app in it. I want to source control this instance, but this has lead to all my protected apps being deployed in this instance. Its not a huge deal as I will just use permissions to make sure nobody can access them but it leads to a messy dashboard for me.
Ideally I would be able to mark an app as not deployed in a certain instance using the multi instance deployment config. This would allow me to keep only the relevant apps in each instance!
Unfortunately the manifests doesn't allow you to exclude apps, only specify versions to include in the release.
In this case a separate source code repo for your external app instance might be more appropriate?
I can imagine some use cases where the include/exclude from a deployment would be useful, but I can also see where it could become confusing too, where instances fall out of sync. How would you imagine this working, from a UI perspective?
I don't want to use a separate repo as I want to be able to edit all apps in one instance. It makes it much easier to handle permissions for others editing apps if all editing is done in one instance.
How would instances fall out of sync? They would be pointing at the same repo / branch, just would show different apps in each environment.
I can see this happening if we allow users to toggle the relevant switch for a given app on and off without also removing it from the instance. There are definitely some things that would need to be hashed out, but I think it's a conversation worth having!
I'll document this request internally and provide an update here as soon as I have news to share.
I might be misunderstanding your concern, but I don't understand how this could lead to it falling out of sync? The current release options are stored in the manifest which is tracked in git. Any changes to the manifest would result in all instances pointing at that branch to redeploy.
There are definitely some things that would need to be hashed out, but I think it's a conversation worth having!