In my dev team we work on branch per feature, and promote binaries generated from the feature branch to a single UAT environment.
How can we model this in Octopus Deploy?
Note: we are also using a different model for some projects which is working nicely in Octopus Deploy. There, we have a single master branch, we merge features into the master branch which get built by TeamCity and pushed to Octopus Deploy and Deployed to a single shared DEV environment, then if we’re happy, we click and deploy to UAT.
So, the difference between the old scenario and new scenario is that old scenario is:
DEV->UAT->PROD.
Whereas the new scenario is
[One of FEATURE1,FEATURE2,FEATUREn]->UAT->PROD.
[Note: of course, once FEATURE1 is pushed to UAT, we need to be sure to that anyone working on FEATURE2… merges in FEATURE1. but once they have done that, then again …
[One of FEATURE2,FEATUREn]->UAT->PROD.
Note also that the feature deployment environment supports multiple feature packages running side by side on same host. So, we dont’ have lots of hosts, just one “feature host”.
I guess what I would need to do is:
a) create environments programmatically in Octopus deploy (or I guess devs could manually create one environment per feature, not a huge overhead)
b) for the project in question, programmatically (or manually?) edit the lifecycle so that the lifecycle goes FEATURE1->UAT->PROD (or FEATURE2/3/n->UAT->PROD depending on what we are focused on
But I feel like that is clunky and requires quite a lot of programming.
Is it possible to have multiple “feature branch environments” all pointing at one UAT environment, conceptually I imagine in like this:
COMMIT in FEATURE1->DEPLOY TO FEATURE 1 ENV }
COMMIT in FEATURE2->DEPLOY TO FEATURE 2 ENV } Then manual choice whether 1,2,3 deployment gets promoted to UAT env.
COMMIT in FEATURE3->DEPLOY TO FEATURE 3 ENV }