Best Of

Best practices for Application Lifecycle Management (ALM) :

Model Structure and Naming Conventions: Use clear and consistent naming conventions for modules, lists, and actions. This helps in maintaining an organized model and makes it easier for team members to understand and navigate.

Regular Changes: Implement changes in small, manageable increments and synchronize frequently. This reduces the complexity and time required for each synchronization.

Keep Separate Development, Test Environments and Production Environments: Keep your development (DEV), Test (QA) and production (PROD) environments separate. This ensures that changes can be tested thoroughly before being deployed to production.

Regular Backups: Regularly back up your models to prevent data loss and ensure you can revert to a previous state if needed.

User Access Control: Limit access to the production environment to only those who need it. This minimizes the risk of unauthorized changes and maintains data integrity.

Documentation: Maintain comprehensive documentation of your models and processes.

Use Revision Tags: Utilize revision tags to track changes and manage different versions of your models. This helps in maintaining a clear history of changes and facilitates easier rollbacks if necessary.

Validation: Thoroughly test and validate changes in the development environment before deploying them to production.

@Vivekagarwal007 I like your idea of using History ID.

I myself use just a regular consecutive numbering system in RT Title. And in the description, I would write any notes I feel are related. For example, the name or code of the change request from our tracking system.

My ALM Best practice for Revision Tag is to use the Last History ID as a Revision tag Title in Dev followed by a short description of the contents by comparing the previous and Current tag. This helps reach the point in time where we completed the development and helps track Changes better.

ALM best practice checklist

1.Ideally Have dev and prod models in separate environments (ALM allows segregation of duties so there is complete possibility of different users in different workspaces as per role and requirement)
2. In case dev and prod models are in same workspace , ensure no production user is added or provided access to dev model since any structural change can be made ( ensured using security - roles, selective access)
3.Dev model has to be as lean & small as possible inclined towards Create Model from Revision. Having Production Data in your Dev model is not recommended as you might expose your live data to people.
4. Use revision tags ( capture the model structure at the time - Note history ID) and name RT properly so that other developers understand and relevant RT can be synced to production
5. Ensure any data which is to be updated in production model(live to business users ) is marked as production data and before that it is necessary to ensure that list to be marked as prod is not referenced as item format(item reference protection)
6. while doing compare and sync to sync RT in prod model , do get update as to which RT to push to production ( in case of multiple RT after last sync)
7. Before syncing any functionality which involves change in production data(update in formula or module data) , it is advisable to keep last production data in hand just before sync since data loss may be caused.
8. In case of any import needs to be updated in back end in production model, mark import as production import /source as production data
9.Enable deployed mode in test and production models. Deployed mode locks down your production models so that production users, including Workspace Administrators, can only modify production data, not structural information and deployed mode must not be disabled for production models else compatibility (sync with dev model) can be broken.

Hi all, ALM is one of the most important part in Anaplan.

In simple words we all know in Application Life Cycle management(ALM) we need 3 models. A Dev model where we do the developments, a Test or UAT model where we first test the development and the Production model where after business approval, we do the deployment.

The Dev model will always be in Standard mode, UAT and Production will be in Deployed mode. UAT model is likely be a copy of the Production model only.

Remember never change the mode of UAT or Production model from Deployed to Standard by mistake. Then this entire ALM chain will break and we wont be able to connect the Dev model with these models for deployment.

We do create a Revision Tag in the Dev model after making the development and then from Manage Models> Compare and Sync we add the changes from Dev model to UAT or Production model.

Make sure if you do this deployment in business hours then always keep the model in Online mode (Uncheck the Offline checkbox in the Revision tag deployment process). If you do this in Offline mode then Business users wont be able to see the Production model until the sync gets completed.

Few Best Practices:

• "Keep your Dev model clean! Regular metadata cleanup and module optimization will make deployments smoother." (Emphasizes model health)
• "Always validate your deployment packages before pushing to Production. Prevents unexpected changes." (Highlights pre-deployment checks)
• "Use descriptive names for revisions and deployment tags. Makes tracking changes much easier." (Focuses on clear documentation)
• "Document your ALM process! A clear guide ensures everyone follows the same steps." (Stresses process standardization)
• "Leverage line item subsets for ALM. This helps manage changes to specific line items efficiently." (Highlights a specific technical tip)
• "Always use a development workspace, a test workspace, and a production workspace." (reinforces a three workspace strategy)

Deployment Specific Tips:

• "When deploying, carefully review the impact analysis. It shows what's changing and helps identify potential conflicts." (Emphasizes impact analysis)
• "For large deployments, consider breaking them down into smaller, manageable packages. Reduces risk and troubleshooting time." (Suggests a strategy for large changes)
• "After a deployment, always perform thorough testing in the target environment to ensure everything works as expected." (Stresses post-deployment validation)
• "Use selective import during deployment to only update changed items. This speeds up the process and reduces errors." (Highlights a performance optimization)
• "Be mindful of production data during deployments. Avoid overwriting or corrupting it." (Highlights data integrity)

Revision Tag and Branching Tips:

• "Use clear and consistent revision tag naming conventions. Include date, feature, or bug fix details." (Focuses on clear version control)
• "When branching, clearly define the purpose of each branch. Avoid creating unnecessary branches." (Emphasizes efficient branch management)
• "Merge branches regularly to keep them up-to-date with the main development line." (Highlights the importance of regular merges)
• "Use tags to mark significant milestones or releases. This makes it easy to revert to a previous version if needed." (Emphasizes the use of tags for tracking milestones)

Troubleshooting Tips:

• "If a deployment fails, carefully review the error logs. They often provide clues about the cause." (Highlights error log usage)
• "Use the compare feature to identify differences between revisions or deployment packages." (Suggests a tool for comparison)
• "If you're unsure about a change, test it in a non-production environment first." (Reinforces testing in non-production)