ALM and release syncing

Bob-Bachynsky
Bob-Bachynsky
in Security and tenant administration

Hi users. This question was asked of me in a personal message. I thought it might be something others would have questions about so I am reposting it here for everyone to see and discuss!

 -Bob

 

I am working for Anaplan implementation project as project manager. We are adopting the Agile implementation, and as many other agile methodology, we build the requested functionality first, show it to client, and only developing it if we have approval. Those approval mainly doesn`t based on technical readiness, but based on business judgement. Example if we implemented function A, B, and C and showed it works on Dev. Then client ask only to release C to the Prod. It is sounds possible for ALM to only put revision tag to C and limit the sync from A and B? The next question is about module filter condition saved only in particular dashboard. If we set a filter as default on Module A in Dashboard A in Dev, would it be lost or also synced when released to Prod?

Tagged:

Best Answer

  • DavidSmith
    DavidSmith
    Answer ✓

    Hi

    The simple answer is no, C will include all of the developments done for A and B, as the synchronise is a whole model sync.  The only way to deploy independant features would be as follows:

    Develop feature A and set a revision tag

    Restore the model "pre-A"

    Develop feature B and set a revision tag

    etc...

    Then one of A, B and C could be deployed.  However, when/if you needed the other features, the devlelopment work would need to be repeated.

    The is ongoing work in the prodict roadmap to allow branching and merging which would mean A, B and C could be devleoped in separate branches and merged together before synchronising to Production

     

    In terms of the module filter, generally, yes, the filter will persist in production.  However, if the filter references a production list item, this will not synchronise becasue production lists are data items and do not sync; therefore the filter item in devleopment is treated as a different item

    I hope this helps

    David

Comments

  • charis_nugroho
    charis_nugroho

    Hi David

     

    Thank you for providing me these insights

    Indeed these help a lot

     

    Then one of A, B and C could be deployed.  However, when/if you needed the other features, the devlelopment work would need to be repeated.

     

    >> We thought about this method but affraid that this will takes us double time in case feature A and B share some common modules.  Perhaps the best way to deal with this parsial deployment is to do it manualy but frequently.

     

    The is ongoing work in the prodict roadmap to allow branching and merging which would mean A, B and C could be devleoped in separate branches and merged together before synchronising to Production

     

    >> Would you mind to share about when this branching feature will be released?

     

    Warmest

    Charis

     

Categories