4

For a software project I am working on, we have a 'dev => QA => production' methodology. That is, we create a release candidate (deployed to Artifactory), give it to QA (deploy to QA systems and a QA backend/application server) who takes a week or so to look at it, and if they it's ok, we make a production release.

Now, I come from an embedded/native app background, not as much Java/systems/CI. And I am accustomed to revision control organized with all releases tagged (in this case, the production release tags are always just copies of an RC tag).

 branches/1.2 branches/1.3 tags/1.2.0-rc tags/1.2.0 tags/1.3.0-rc tags/1.3.1-rc tags/1.3.1

However, several team members state that this doesn't work well with Maven (and maybe Jenkins too). Instead, they suggest:

 branches/1.2.0-rc branches/1.3.0-rc branches/1.3.1-rc tags/1.2.0 tags/1.3.1

I am arguing that a release candidate should not be a branch, as we need to deliver a known entity to QA (as opposed to a continuous integration/deployment situation where we might cut the production release directly from our development line without waiting for QA). The fact that several developers are checking code into the RC branch, and there is little control around it, has caused issues.

Could somebody please explain if there's something about Maven or Jenkins that would make the second way "better"? Is there anything that makes the first way more difficult to implement?

Improve this question
3
  • 1
    Given that SVN doesn't have real (immutable) tags and tags/X is just a convention with special branch names, I can't imagine what the difference between tags/1.2.0-rc and branches/1.2.0-rc would be for Maven and/or Jenkins Commented Apr 21, 2015 at 16:58
  • Perhaps those that don't want to use tagged versions need to be able to make changes at any time? For Maven/Jenkins I don't see an advantage to use branches. Commented Apr 21, 2015 at 17:31
  • Understood that the names "tags" and "branches" are just a naming convention in SVN. The conventions, however, speak to how they are being used. In the first case, we would do development on a branch, then cut a release from branches and call it an RC. If it goes through QA, we re-release it to production. I think it's the "re-release" that is causing the hang up... In the second case, we checkin directly to the thing called an RC (essentially doing development there), then when it's ready, we do nothing in terms of cutting a release - just deploy it to QA servers. If it passes, we release. Commented Apr 21, 2015 at 17:38

1 Answer 1

Reset to default
3

I don't quite see how Maven or Jenkins would relate to this! But I'd like to give a general distinction to this. (Even if this is a pretty old question...)

A branch is something that you work on.

A tag is only a name.

So in case your work is an RC, you could still be in need of fixes or improvements, that's why you keep working on it and having a branch for it.

Once you're done and your work is released, you keep a permanent pointer to that version (the tag).

So I'd favor version 2 also! I'd call this the typical way. And maybe that's why it integrates with Jenkins better, too - because as long as it's still work in progress and you might have to redeploy, it's better to have a branch (as a deployment source - at least we work this way with Bamboo).

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.