Using promotion environments with different rules in same application

Guest

Hi,

I have a question regarding Workflows and Environments. But first, let me explain my situation.
We have an application we'll call ImportantApp for this example. This ImportantApp just now has release of 1.7 (Build 3). However, when still in version 1.3 (build whatever it was), management decided some features that will only be available in version 2.0. However, version 1.x must still be improved and maintained whilst development of version 2.0.

Hence, my Subversion directory looks something like this:
branches/development
branches/development_stable
trunk
tags

So basically, a trunk contains currently stable version. Development_stable branch also contains currently stable version, but all patches and new features for v1.x is developed there. Development branch is where v2.0 development is going on.

Versioning up until this point was done manually, however, now, we are migrating the process to BuildMaster.

How to go about it?

I thought I could do it with one single application and using different workflows. Unfortunately, I am not sure if actions can be different for same environment in different workflows or not.

Guest

Hi Vlad,

Firstly, I'd suggest checking out Release Management Done Right: http://www.inedo.com/whitepapers/release-management-done-right

This scenario (branching by release) is best handled through variables and/or workflows.

The way that we have it set-up is to have a release-level variable called RELTYPE that deterimes whether the release type is a branched release (like your 2.0) or a trunk release (like 1.x)

If RELTYPE = "BRANCHED"...

Get Latest from /branches/%RELNO%

If RELTYPE = "TRUNK"

Tag /trunk to /tags/%RELNO%.%BLDNO%
Get Latest from /tags/%RELNO%.%BLDNO%

We are unable (via Promotion Requirements) to ship a BRANCHED release. For us, BRANCHED releases are really just for internal or beta testing. But this is just our own policy, and there are lots of ways you could handle this.

Guest

Hi Alex.

This is exactly how we have it sort it out. Branched release will become a stable one at the moment it hits production. For now, all we need is for v2.0 to get deployed to our v2.0 integration environment.

Thank you.

Guest

Ah, great -- was this information I wrote-out helpful?

We're thinking of doing a series of videos/tutorials to show some of these patterns in action.

Guest

It was very helpful.