How I Built It: Method for branched development within ALM

NoahJ

Author: Noah Jackson is a Certified Master Anaplanner and Principal Data and Insights Architect at Anaplan.

Hello Anaplan Community!

Since the release of the “unlink revisions” feature, it is possible to do branched development within Anaplan ALM. This is most useful when you are beginning work on a larger change or new feature, but want to retain the ability to sync small maintenance changes or hotfixes to production without interrupting the new development work. Below I share a write-up on this topic and below that, a video overview.

The method will use two Dev models; I’ll refer to them as the “Maintenance” Dev and the “New Build” Dev. Changes can be synced from Maintenance Dev to Prod, and then when the new development in the New Build Dev is ready the Prod can be switched over to it. The video below explains the method and some background to it, but for easy reference I will also detail it in text here.

First it is important to understand the limitations:

This method will not merge changes between the two Dev models. The structural changes from Maintenance Dev will be removed, and the Prod model will be fully synced to the New Build Dev. Any changes made in the Maintenance Dev that are needed moving forward will need to be replicated in the New Build Dev.

Additionally, even if the hotfix line items are replicated identically in the New Build Dev, when you switch branches the process involved will delete and then re-create them. This has potential negative impacts:

• If the hot-fix line item is non-formula and has data entered into it, that data will be cleared
• The hot-fix line items may disappear from UX pages depending on how they are displayed
  

To reduce the risk of lost data and duplicated work efforts caused by those limitations, the timing for switching to the New Build Dev should not be too long and the work in the Maintenance Dev before then should be limited to minor changes. Additionally, when you are ready to sync the New Build you should sync to a UAT model first and look for these impacts and make a plan to address them.

Instructions for branched development

Assuming a starting state of one Dev model, one UAT model, and one Prod model, all on revision tag R1. The exact model names and revision tag names are not critical, as long as you use clear naming to avoid confusion. This can be done without a UAT model but it is not recommended.

1. Make a copy of Dev named Dev MAINTENANCE, then change the name of the original model to Dev NEW BUILD. Begin development of the larger change or new feature of the model in Dev NEW BUILD.
2. When minor hotfixes or model maintenance needs arise, build them in Dev MAINTENANCE and sync to UAT / Prod as normal, using revision tag R2, R3, etc.. Keep track of these changes so that any relevant ones can also be built in Dev BRANCH.
3. When the Dev NEW BUILD new feature is ready for release, create revision tag Branch1
4. Then prep UAT model to sync:
   1. Take UAT out of Deployed mode, set into offline mode.
      
   2. Use History menu to identify a point in the model after R1 revision tag and before R2. Restore back to that point, and make sure "Unlink Revisions" is checked.
      
   3. Do a second History restore back to the "present" (i.e. last normal history ID), again making sure “Unlink Revisions” is checked.
      
      1. After this action, the model should be identical to the state it was in Step A except that the tags for R2, R3, etc. no longer exist in Revision tags settings area.
         
   4. Use "Revert to Last Revision" to set the structure back to R1, while retaining all production data that has been entered since then in the rest of the model.
      
      1. If the production data in the model is easy to re-import or does not need to be preserved, you can skip Steps C and D and sync immediately after Step B.
         
   5. Put UAT model back into Deployed mode, then sync Branch1 revision tag from Dev NEW BUILD into UAT
      
5. Examine the UAT model to confirm that the changes synced correctly, and identify anywhere that cell data in hotfixes may have been cleared or lines may have disappeared from the UX. Record any cell data in those corresponding lines in Prod that needs to be preserved.
   
6. Repeat Step 4 with the Prod model. Set the Prod model back online once all changes have been verified.
   
7. The Dev MAINTENANCE model will now be incompatible with UAT and Prod, so should be locked and/or archived. The Dev BRANCH should be renamed to Dev and used as the singular development model going forward.

Video tutorial

https://play.vidyard.com/iyFeskPpNooYAdKYhcMiqj

I’d love to hear your thoughts on the method, how you might use it and/or any questions you have!