Feature branches - "release paths"

Legacy Uncategorised
1

Hi people,

How would you go about having feature branches that deploy to two environments (development and test).

I’d like to avoid creating “Dev-feature1”, “Test-feature1”, “Dev-feature2”, “Test-feature2” environments since promote will get seriously cluttered from this…

Started to think about target machine roles to achieve this instead, maybe that’s the way to go?
like “web-server-feature1”, “app-server-feature1” and so on …

Or, you could define release paths for a project. Saying that it consists of these environments, and promote-order.
That way the promote-step wouldn’t get cluttered with irrelevant environments, also wouldn’t suggest promoting from test to dev.

Strictly speaking, the dev environment for one branch is another environment from the dev of another feature branch.
Feels correct creating environments for the different branches.

Thanks in advance for taking the time to read this and try to help out

2

Hi Ivar,

We don’t have a clean way to manage this as you’ve found. The most common solution is to create separate projects - if you base your installation paths on the project name, or target different roles, then it’s pretty easy to keep the dashboard looking nice while partitioning the application.

However I’m aware that we could do more to help this scenario and I’d like to find a better solution. How would you like this to work?

Paul

3

Oh god, think completely fell between the chairs. Here comes a late reply :slight_smile:

Now that project groups have environments you can limit it too, this “environment clutter” is no longer an issue.