Overview There is not a switch to “turn-on” ALM. ALM is based on entitlements described in your subscription agreement Discuss your subscription with your Anaplan Account Executive and Business Partner Workspace administrators can check the feature availability: Log in to Anaplan Click on your name in the top-right-hand corner Select Manage Models Look for the Compare/Sync button Button is greyed out: Speak to your Anaplan Account Executive regarding your subscription agreement Button is available: You currently have access to ALM functionality on your workspace. Additional information is available in the 313 Application Lifecycle Management (ALM) class, located in the education section.
A revision tag is a snapshot of a model’s structural information at a point in time. Revision tags save all of the structural changes made in an application since the last revision tag was stored. By default, Anaplan allows you to add a Title and Description when creating a Revision tag. This article covers: Suggestions for Naming Revision Tags Creating a Revisions tracking list and module Note: For guidance on when to add revision tags, see When Should I Add Revision Tags? Suggestions for Naming Revision Tags It’s best to define a standard naming convention for your revision tags early in the model building process. You may want to discuss with your Anaplan Business Partner or IT group if there is an existing naming convention that would be best to follow. The following suggestions are designed to ensure consistency when there are large number of changes or model builders as well as allow the team to better choose which Revision Tag to choose when syncing a production application. Option 1: 1.0 = Major revision/release 1 = Minor changes within a release In this option, 1.0 indicates the first major release. As subsequent minor changes are tagged, they will be noted as 1.2, 1.3, etc until the next major release: 2.0. Option 2: X = Major revision/release X.1 = Minor changes within a release In this option, YYYY indicates the year and X indicates the release number. For example, the first major release of 2017, would be: 2017.1. Subsequent minor changes would be tagged: 2017.1.1, 2017.1.2, etc until the next major release of the year: 2017.2. Creating a Revisions tracking list and module Revision tag descriptions are only visible in the Development application. That means that it can be difficult for an end-user or Production Workspace Administrator to know what changes have been made in the current release. To provide release visibility in a Production application, consider creating a Revisions List and Module to store key information about revisions. Revisions List: In your Development application, create a list called: Revisions Do not set this list as Production. You want these list members to be visible in your Production model Revisions Details Module: In your Development application, create a list called: Revisions Details Add your Revisions List Remove Time Add your Line Items Since this module will be used to document release updates and changes, consider which of the following may be appropriate: Details: What changes were made Date: What date was this Revision Tag created Model History ID: What was the Model History ID when this tag was created Requested By: Who requested these changes? Tested By: Who tested these changes? Tested Date: When were these changes tested? Approved By: Who signed off on these changes? Note: Standard Selective Access rules apply to your Production application. Consider who should be able to see this list and module as part of your application deployment.
“Back to the Future” Imagine the following scenario: You are in the middle of making changes in your development model and have been doing so for the last few weeks. The changes are not complete and are not ready to synchronise. However, you just received a request for an urgent fix from the user community that is critical for the forthcoming monthly submission. What do you do? Well what you don’t want to do is take the model out of deployed mode! You also don’t want to lose all the development work you have been doing. Don’t worry, following the procedure bellows will ensure you can apply the hot fix quickly and keep your development work The following diagram illustrates the procedure: It’s a two-stage process: Stage 1: Roll the development model back to a version that doesn’t contain any changes (is the same as production) and apply the hotfix to that version. Add a new revision tag to the development model as a temporary placeholder. (Note the History ID of the last structural change, you'll need it later.) On the development model, use History to restore to a point where development and production were identical (before any changes were made in development). Apply the hotfix. Save a new revision of the development model. Sync the development model with the production model. Production now has its hotfix. Stage 2: Restore the changes to development and apply the hotfix. On the development model, use the History ID from Stage 1 – Step 1 to restore to the version containing all of the development work (minus the hotfix). Reapply the hotfix to this version of development. Create a new revision of the development model. Development is now back to where it was and has the hotfix applied. When your development work is complete, you can promote the new version to production using ALM best practice. The procedure is documented here: https://community.anaplan.com/t5/Anapedia-Model-Building/Fixing-Production-Issues/ta-p/4839