ALM syncing when multiple developments are happening

DeveloperCYT

We have 2 developers working on the same model in different modules.
One has completed his changes but the other is not ready to sync.
Unfortunately you have to sync the whole model, and this means partial changes would then be synced. If the first developers' changes are urgent, waiting for a major change to be finished is unproductive.
Would it be an idea to just sync the changes (by choice), and not the whole model?

PaulinaLangowska

I second this - it would be useful to have an option to selectively sync changes as we are often caught waiting for an approval for one change where multiple other ones are ready to go. Additionally, we have to rely on our team communicating before syncing any models in case another developer made a change somewhere else that isn't ready to be pushed into PROD just yet

JosephPhilp634

I have just asked a similar question on this discussion it would be amazing if you could pic the individual changes you want to sync.

https://community.anaplan.com/discussion/157189/can-you-stop-revision-tags-changing-versions

SaiPrasanthK

I can suggest two approaches to manage scenarios where multiple developers are working on different enhancements to the same model, and we need to push their changes separately into the production model:

1. Rollback Method:

• After completing a build in the development model (in standard mode), the developer meticulously documents all changes made during the build process.
• They then roll back the model to a previous revision tag history ID that aligns with the current production model.
• Following the documentation, they rebuild only the changes intended for production.
• Once this targeted build is complete, they create a new revision tag, push those specific changes into production, and roll forward the history ID to the rollback ID. This allows developers to seamlessly resume their individual builds.
• Crucial Notes:
  • Clear communication among developers is paramount to prevent unintended changes during the rollback state.
  • Exhaustive documentation of every aspect of the build is essential to avoid discrepancies when pushing to production.

2. Dormant Method:

• Each developer creates a manual Boolean line item (e.g., "P12 build") and bases their entire enhancement on that Boolean.
• For example, when pulling sales data into a line item and performing subsequent calculations, the formula could be written as: If P12 build then Sales ELSE 0. This ensures the build remains dormant and doesn't impact the production model until the Boolean is activated.
• Key Considerations:
  • This method might not be ideal for large models in classic Anaplan, as it could potentially strain production workspace capacity.
  • Developers must have a clear understanding of their build plans and the ability to make it Boolean-dependent.
  • Impact analysis is highly recommended before commencing, as most enhancements are add-on features that rely on existing builds.
  • Saved views should also incorporate the Boolean line item as a filter to prevent unintended actions.