ALM setup for parallel release: Spring development and HotFix
I am a newbie and looking for suggestions , ALM best practices for implementing the below scenario. Please advice.
Release process being followed in our org.:
Sprint Development:
Sprint Development Model >>>> QA Testing Model >>>> UAT >>> Production
Hot fix:
Hot Fix Model >>>> QA Testing Model >>>> UAT >>> Production
Wondering how to configure ALM so
1. Both sprint development and Hot Fix can go in parallel
2. Sync production hot fix changes with ongoing sprint development model
3. Production sync should have only UAT approved changes in both the cases sprint development / Hot Fix
Please advice..Thanks in advance
Answers
-
Hi @RajeshPrabhu you need can achieve this by the following way.
- Capture the latest "Revision Tag" and "History ID" of previous Sprint/Release before you start the build of next sprint/release.
- If there is hot fix required and you are in middle of next sprint build then you need to send a email notification to your team to inform that the DEV model is going to be roll back to past for a hot fix. This is to avoid any changes during roll back.
- Capture(on going Build) the latest "Revision Tag" and "History ID" of the on going build and Roll back the model to the state where previous sprint/release latest RT is in using the history ID captured.
- After roll back do the hot fix and then create a revision tag sync it with your UAT model.
- Capture(Hot fix) the "Revision Tag" and "History ID" for the future use if there might be any hot fix later.
- Roll back the model to the state of current(on going build) using the history ID captured for it.
In this with out moving the on going build to UAT and PROD models you can do the hot fix.
2 -
Thank you Anil. Few follow on clarifications
"If there is hot fix required and you are in middle of next sprint build then you need to send a email notification to your team to inform that the DEV model is going to be roll back to past for a hot fix. This is to avoid any changes during roll back."
>> We are essentially holding ongoing sprint development until prod issue hot fix patch is released. Will it not impact sprint timeline given we never know how long it would take for a hot fix change to close. Is it advisable ?
- After roll back do the hot fix and then create a revision tag sync it with your UAT model.
>>If there is an ongoing spring UAT then we have to hold that as well. Follow the same process as development. Is that a right understanding?
- Roll back the model to the state of current(on going build) using the history ID captured for it.
>> Would it not override hot fix changes when we put back ongoing sprint build ?
0 -
Hi @RajeshPrabhu below are my comments.
>> We are essentially holding ongoing sprint development until prod issue hot fix patch is released. Will it not impact sprint timeline given we never know how long it would take for a hot fix change to close. Is it advisable ?
Yes, with this approach the current sprint build activity will be hold. If assumed that hot fix is going to take more time then better take the hot fix for next release if possible. Else after each sprint you need to take DEV copy and use it for hot fix so that current sprint build will not be impacted. But with this approach you need to create a new PROD of each sprint as you will not be able to sync the existing PROD model with new sprint changes.
>>If there is an ongoing spring UAT then we have to hold that as well. Follow the same process as development. Is that a right understanding?
You need to maintain different UAT models for each sprint. Keep it in archived state and unarchive it when required, so that you can save space when the older UAT models are not in use. Else take a copy of PROD and perform UAT for hot fix.
>> Would it not override hot fix changes when we put back ongoing sprint build ?
Yes, it will. You need redo the hot fix changes after roll back in current sprint so that when current sprint went live there will be any issues.
0 -
Thanks Anil.
>> Yes, with this approach the current sprint build activity will be hold. If assumed that hot fix is going to take more time then better take the hot fix for next release if possible. Else after each sprint you need to take DEV copy and use it for hot fix so that current sprint build will not be impacted. But with this approach you need to create a new PROD of each sprint as you will not be able to sync the existing PROD model with new sprint changes.
New prod for each sprint may not be accepted by business . If there is no other way, I guess the only option is to propose business to hold development until patches are deployed in production.
>> You need to maintain different UAT models for each sprint. Keep it in archived state and unarchive it when required, so that you can save space when the older UAT models are not in use. Else take a copy of PROD and perform UAT for hot fix.
Just extending this approach please advice if it would make sense
a. Take a prod copy (HOT FIX #Nov30)
b. Apply bug fix
c. Perform UAT
d. Compare and sync UAT (HOT FIX #Nov30) and Production
e. Post production, Compare and sync UAT (HOT FIX #Nov30) and sprint development model
f. Archive HOT FIX #Nov30
0 -
@RajeshPrabhu please see my below comments
New prod for each sprint may not be accepted by business . If there is no other way, I guess the only option is to propose business to hold development until patches are deployed in production.
Yes, the only way is hold development. If possible move the fix along with next sprint if it not show stopper.
The next point, just making more clear.
If single DEV :-
1. Create the revision tag for current build and capture the history ID.
2. Roll back DEV to previous sprint and apply the fix.
3. Create the revision tag for HOT FIX and capture the history ID for future use.
4. Roll back DEV to future using history ID(point 1) so that current development can continue.
5. Take a PROD copy(HOT FIX #Nov30 UAT) or if already there is UAT model you can use that.
6. Sync the fix with UAT model.
7. Perform UAT.(need to repeat from step 1 to 6 if any fixes are required during UAT)
8. Sync with fix with PROD model.
9. Archive UAT model if not required.
0
