Harvest packages and life cycle

[Jarus Bosman]

Hi,

I'd like some advice on the usage of packages for change management of source code.

We used to use Endevor Workstation to do source code control, where a CCID (Change Control ID) was attached to each source code module in a change. If I understand it correctly, CCID's in Endevor are analogous to Packages in Harvest. Once the source code modules linked to that CCID was moved to the production stage (Release or Production State in Harvest), more changes could be made to the same or other source code modules using the same CCID without affecting the code in production, and moved through the life cycle.

My problem is this: I would like to achieve the same in Harvest with packages, but it seems once your package has been promoted to the Release state, the only way to link that package to more changes, is to demote it, which would remove the changes from the Release state. I would like to be able to make more changes without affecting what has already been promoted.

Is there something wrong with the way I'm trying to implement this, or is there something I'm not understanding because of the way we used to work? I'm trying to shift my whole way of thinking, but I can't get my head around this way of working.

Any advice or assistance will be much appreciated!

Kind regards,
Jarus

[Balakrishna Shantamurthy]

Hi Bosman,

We have reviewed the question and responded to you.
You may continue the discussion there
OR reply to the below mail id.
[e-mail]


Regards,
Balakrishna.

[Jarus Bosman]

Hi,

Thank you for the response.

When we make more changes, they must not be made directly to the Release State. The change has to be unit tested and must go through QA before reaching the release environment.

[Balakrishna Shantamurthy]

Hi Jarus,

We have  reviewed your answer.
We agree with the approach that changes must not be made directly to the Release state
We continue to review and will provide an update.

Regards,
Balakrishna.

[Jarus Bosman]

Hi Balakrishna, all the best for 2021.

Any progress on this matter?

[Jarus Bosman]

I'm still thinking about this problem. I have now come across a similar problem - What if I find out I need to change another item after I've promoted the package to the Production state, and I would like to use the same package to change this item? The package is not available to me in the Development state!

Edit:

Another challenge: After the Merge State, the changes get promoted to Test. What happens if the Tester picks up bugs? Does the developer have to use a new package to fix those?

[Sridhar Gooni]

Hello Jarus,
As discussed earlier in the thread, Package is a unit of change in Harvest.
Once you promote any package(changes) and want to add /modify the changes, two ways we can think of:
1) Demote the package and modify, but again it will not show the versions associated to the package (which got created while merging) until it is promoted back to the state.
2) Create a new package and add the changes to the newly created package. But to maintain a relation between earlier package and newly created package, we can create a package group and add these packages. This way we can group all the required changes.

Thanks,
Sridhar

[Jarus Bosman]

Hi Sridhar,

Thank you, it makes sense to apply it like this. Like I said earlier, we need to look at things differently and adjust our processes ever so slightly.

Thanks for the advice!
Jarus

[Jarus Bosman]

Just to confirm then: If I'm using the Production Model, I would have to add an additional "Demote Package" process to the "Merge" state in order to use the first solution you've posted (Demote the package and modify)?

[Sridhar Gooni]

Yes. But we need to delete the merged version in Merge State before demoting the package.