Each build in appveyor increments the build version and automatically creates a release in Octopus with a release version that matches the build version.
The problem is, when we build in develop it creates a release, we deploy it to UAT
Then when we merge develop into stage, it creates a new release, but we cannot push it to stage w/o first pushing it to UAT, which we dont want to do b/c by this point there are likely other features that have already been merged into UAT.
Then when we merge into master for a production push, it creates a new release, but we cant deploy to production until we deploy to UAT and then STAGE, which again, are still under active development and we dont want to update them with the production bits.
I figured this is a common thing and I’m just missing the solution in the documentation.
The hurdle you are running into is because Octopus has been designed for the flow of the same binaries through environments. A common pattern is to merge to a main branch, build the binaries, and then deploy the binaries to UAT, STAGE and PRODUCTION. That way you ensure you are testing the exact same bits against your different (but hopefully production duplicated) environments.
If you are keen to maintain branches that map to your environments you can do so in Octopus by configuring your lifecycle so that it does not require the promotion of releases through environments. There is documentation on lifecycles here: https://octopus.com/docs/deployment-process/lifecycles. You will want either all of your environments in the same phase, or separate phases where UAT and STAGE are optional.
A safer alternative to opening up the lifecycle would be to use channels. Documentation is here: https://octopus.com/docs/deployment-process/channels. You could create a channel for for UAT, STAGE and PRODUCTION each with a lifecycle that allows deployments only to that environment. That way you prevent UAT releases from being deployment to the PRODUCTION environment. You can provide version constraints on channels to ensure that your branch builds end up in the correct channel.
I hope this helps, please let me know if you have any questions.