Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Using promotion environments with different rules in same application
-
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
tagsSo 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.
-
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.
-
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.
-
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.
-
It was very helpful.