Parallel Development
search cancel

Parallel Development

book

Article ID: 204043

calendar_today

Updated On:

Products

CA Harvest Software Change Manager CA Harvest Software Change Manager - OpenMake Meister

Issue/Introduction

We have a Production Project with following states (Dev, Merge, Test, QA and Production”, when ever development team inform us they are getting ready for the upgrade we create cross-merge project for the parallel development and Go-live we disable the Production Facets and make cross-merges project as active Facets Project.

This time Team asking us to create different solution, they wants to avoid back and forth between parallel development project. They sends us requirement to create additional state “UPGRADE” so developers can move the code which is related to upgrade to UPGRADE state from Merge, and regular development code will move as usual from Dev, Merge, Test, QA and Production.

When Go-live time come they want to promote all the packages from Upgrade state to Test, QA and Production.

I would like to know what difficulties we will have in term of version control ? I think there will be issue during go-live when we will move packages from upgrade state to test, QA and Production if there is already higher version exists in production or any state it will not allow us.

Please if you can review our propose project and let me know any other concerns.

Environment

Release : 13.0

Component : CA Harvest Software Change Manager

Resolution

The difficulty with inserting a new Upgrade state into an existing project is the data view. Remember that any package is not visible in a state until it has been promoted to that state. So when the new state and data view are first added, none of the packages have been promoted to that state yet so they are not visible there. If you’re wanting to just “park” packages in the new Upgrade state for a time and don’t ever need to test anything from that state, then this would be ok. If you needed to populate the data view for the new state with all the versions you want to be visible there you will need to promote the packages from their current location to the new state and back to their current location again.

Your developers are using concurrent development (branching and merging) and this actually makes the idea easier because I can imagine the versions you want to “park” in the new Upgrade state and incorporate later can be unmerged branches. You would incorporate them by merging them back to the trunk.