best practice for versioning
Hello all!
I am looking for a best practice for versioning management for below senario:
Provide we have a a ruleset version abc:01-01-20 at the end of the development. then skimming to abc:01-02-01, and release to the production environment.
next created abc:01-02-02 for new feature development.
then a bug is found in the production environment, and need to fix as soon as possible.
How should I manage versions for bug fix(comes later but go live fist) and new feature development?
thank you!
***Edited by Moderator Rupashree S. to add Capability tags***
Accepted Solution
Updated: 14 Apr 2024 20:55 EDT
Maantic Inc
IN
- Work in branches
- Assign a user the role of a release manager, who determines the application version and release strategy. This user should be familiar with concepts and features such as rulesets, ruleset versioning, application records, and application migration strategies
- The release manager selects a development ruleset version number that includes a patch version number
- Developers merge into the highest available ruleset version
- Frequently increment ruleset versions to easily track updates to your application over time
- Maintain an application record that is capped at major and minor versions of its component rulesets
Its always better to have separate pipelines for separate applications. While merging rulesets, the developers need to be aware of merge conflicts and have them rectified. Frequently rebase your applications.
Bits in Glass
IN
@chend1 for production bug fixes, you can keep a new version-> 01-01-21 and for deploying the fixes you can deploy this version. For further production fixes you can deploy same version. We can say for example, it's Release 1.1 . Whatever production bugs come under this release will be going as part of 01-01-21.
Pegasystems Inc.
JP
@Anoop Krishna thank you for the reply. I understand that create a new ruleset 01-01-21 for bug fix.
but for the development side, 01-02-02, does not have the bug fix part. so ruleset merge from 01-01-21 to 01-02-02 is necessary. am I right?
Bits in Glass
IN
@chend1 01-02-02 will have the fix part. Because it is on top of 01-01-21. Whatever fix you are doing as part of release 1.1 will be available for 1.2 development.
01-02 is on top of 01-01. We are doing version management as per the releases.
Bits in Glass
IN
@chend1 in an enterprise application what happens is there will be 2 teams, development team and support team who fix bugs. Development team will be working on release 1.2 and supp team on 1.1.
So there will be 2 applications. 1 application pointing till 1-1-21,
Another to 1-2- .
Because support team doesn't want newly developed code to be coming between there testing.
Pegasystems Inc.
JP
Thanks for you reply. I understand and agree with you.
I have a further question for the statement : "Whatever fix you are doing as part of release 1.1 will be available for 1.2 development." If I created 01-02-01 by skimming from 01-01-01 to 01-01-21. then fix (not create) a rule (A) on new patch version 01-01-22. there would be a old A rule in 01-02-01 , and new edited A rule in 01-01-21. and I think application which are using 01-02, would take the old A rule in 01-02-01 as result for rule resolution. so need to merge the new edited A rule from 01-01-21 to 01-02. please tell me if i mis-understood.
Maantic Inc
IN
In many applications we have seen that a ruleset is kept in between the last active and the newer above for future development. In your case keep version 01-02-02 for production bugs so that it can be merged and deployed whenever required without affecting future development code which will be present in 01-02-03.
You can refer the below link for more best practices info:
WOJRC
US
What are the best practices for managing different versions of an enterprise application in a DevOps pipeline, particularly when there are separate development and support teams working on different releases?
Accepted Solution
Updated: 14 Apr 2024 20:55 EDT
Maantic Inc
IN
- Work in branches
- Assign a user the role of a release manager, who determines the application version and release strategy. This user should be familiar with concepts and features such as rulesets, ruleset versioning, application records, and application migration strategies
- The release manager selects a development ruleset version number that includes a patch version number
- Developers merge into the highest available ruleset version
- Frequently increment ruleset versions to easily track updates to your application over time
- Maintain an application record that is capped at major and minor versions of its component rulesets
Its always better to have separate pipelines for separate applications. While merging rulesets, the developers need to be aware of merge conflicts and have them rectified. Frequently rebase your applications.
Pegasystems Inc.
US
@chend1 In our project, after each go live, we increment a 'minor' version to start a new feature development. In your example, we would create abc:01-03-xx for new feature development for the next release. Meanwhile, all the maintenance including bug fixes are done using abc:01-02-xx.