I’ve read numerous discussions on branching, and understand that proper branching support is coming in the next version, however I’d like to make sure new projects are setup in a compatible way.
We are using a slightly modified feature branching methodology, whereby feature branches are pushed to a QA environment for testing, but those features are not necessarily the ones that will then be deployed into production. As such, our master/develop line up, but our qa branch does not.
What I’m trying to ascertain, is should I just set these up as two separate projects for now, or, what I’ve attempted to do is:
In my test scenario, master and develop contains different feature merges:
- In TeamCity, I have a build/package step, where the VCS root is monitoring all branches
- This step gets the branch, and sets the package name accordingly, e.g. 1.0.0-master, 1.0.0-develop
- The package is pushed to internal Octo repo
- Last step is to create a release based on the package id
So, I have a new release for each build I do, which automatically selects the correct package to deploy.
The big caveat to this, is that we “could” promotoe/deploy the develop package into production which is not good (which is what I believe the new branching feature will fix), but it provides us a clean way of seeing one project deployment(s).
Thoughts?
I can see that for now you might want a second project just for QA for now. Going forward, we should be able to handle it with a single project.