ALM setup for parallel release: Spring development and HotFix

Options
RajeshPrabhu
RajeshPrabhu Member, ALL USERS, Community Member Posts: 5 Occasional Contributor
in Enterprise Scale

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

Tagged:

Comments

  • RajeshPrabhu
    RajeshPrabhu Member, ALL USERS, Community Member Posts: 5 Occasional Contributor

    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 ?

      

     

  • RajeshPrabhu
    RajeshPrabhu Member, ALL USERS, Community Member Posts: 5 Occasional Contributor

    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

Categories