Save incomplete changes when synchronizing in ALM
Imagine this scenario:
You are in the middle of making changes in your development model and have been doing so for the last few weeks. The changes are not complete and are not ready to synchronize. However, you just received a request for an urgent fix from the user community that is critical for the forthcoming monthly submission. What do you do?
What you don’t want to do is take the model out of deployed mode. You also don’t want to lose all the development work you have been doing.
Following the procedure below will ensure you can apply the hotfix quickly and keep your development work.
The following diagram illustrates the procedure:
It’s a two-stage process:
Roll the development model back to a version that doesn’t contain any changes (is the same as production), and apply the hotfix to that version.
- Add a new revision tag to the development model as a temporary placeholder. (Note the History ID of the last structural change as you'll need it later.)
- On the development model, use History to restore to a point where development and production were identical (before any changes were made in development).
- Apply the hotfix.
- Save a new revision of the development model.
- Sync the development model with the production model.
Production now has its hotfix.
Restore the changes to development and apply the hotfix.
- On the development model, use the History ID from Stage 1 – Step 1 to restore to the version containing all of the development work (minus the hotfix).
- Reapply the hotfix to this version of development.
- Create a new revision of the development model.
Development is now back to where it was, with the hotfix now applied.
When your development work is complete, you can promote the new version to production using ALM best practice.
The procedure is documented in the Fixing Production Issues Anapedia article.
Nice explanation, David. The diagram alone is worth 1,000 words.4
The link above says the Content is no longer available. Where can I get the documentation?0
I think it is here
However, ensure that before you start the process, set a temporary revision tag to preserve the development changes
The link is now fixed btw0
I have just tried the process and was wondering how do I do second lot of "hot fixes". Specifically, when is the last time that the dev and prod model were the same? Is it before the first lot of hot fixes as the uncompleted changes were restored as part of Stage 2-Step 2 before Stage 2-Step 3 reapplying the hot fix?
@DavidSmith Should this be the Step 1 of Stage 2. I think this should be the heading of Stage 2.0
Correct, I'll get that changed0
Nice explanation, Really easy to understand.👏0
Nothing quite like a bit of back to the future!
As said to me by @James Dougan0
If you have intention on re-doing bug fix on 13, it is important to understand that the structural data (such as module and version) added at 8 and 13 is different. Improper handling will lead to data loss.
Lets say you add module at 8.
At 11, this module will be removed.
On 13, admin redoes addition of module with same name and dimensions.
Despite having same name and dimensions, module created on 8 and 13 is not the same. They internally have different ID.
Any cell changes to the module made between 9 and 13 will be lost as soon as sync at 14 completes.4
@LethargicAnalyst I think This Article will be helpful for you..1
Thanks a lot @DavidSmith for providing this content. Not shure I could implement this withouth the diagram!0
@BrittoMJ thanks britto San😎, good article0