Application Lifecycle Management (ALM) (313)
Overview
Application Lifecycle Management (ALM) enables clients to effectively manage the development, testing, deployment, and ongoing maintenance of applications in Anaplan. With ALM, changes can be introduced without disrupting business operations by securely and efficiently managing and updating your applications with governance across different environments, and quickly deploying changes to run more “what-if” scenarios in your planning cycles as you test and release development changes into production.
Videos
This series of videos discuss different aspects of ALM and includes demos performed in a live model.
Part 1 (8:00) click here
- Benefits of ALM
- Model modes of ALM (Standard & Deployed)
- Structural vs Production Data
- What is a production list?
- What can and can't be changed in Deployed mode
Part 2 (11:30) click here
- Revisions and Revision Tags
- Compatible Models
- Syncing between Development and Production
- Model types: Single, Split Model, and Similar Model
Part 3 (11:48) click here
- Set up - Development only
- Set up - Production only
- Set up - Existing Dev/Test/Prod
- Set up - Simple
- Set up - With Data Hub
We value your feedback!
If you enjoy the videos please give a Kudo! Leave a comment and let us know if there is other information you would like around ALM. You can also do a search on community for more information around ALM.
Comments
-
Hi Shashishankar, I'm going to send you a PM directly. - Thanks!
0 -
Super informative and useful tutorial!
0 -
Hi @DavidSmith, this tutorial is great for ALM. I have one question. I noticed in the part 3 video that you create the additional environments (DEV, TEST, PROD) by using a model copy (this would enable you to copy data as well as model structure). In Anaplan Anapedia for ALM, https://help.anaplan.com/anapedia/Content/ALM/Prepare_Existing_Models.html, the instructions have you create new environment using a Revision Tag (only copy model structure). Is either way acceptable or is one a more current best practice?
Thanks
Linda
0 -
When this article was original written, we did not have "create from revision"
Now that we do have, it is recommended to create from revision for a new DEV because we should be looking to keep the DEV as small as possible for efficient modelling.
The copy of Prod to Test is a good strategy when you need to check the latest developments against the up to date set of data. This is one of the reasons we recommend Dev>Prod and Dev>Test rather than Dev>Test>Prod, you can delete, adjust, create multiple Test environments
I would also recommend setting up different views in the data hub to populate Dev, Test and Prod.
Once the imports to Dev have been set up from saved views in the hub, when Test and Prod models are created, all you need to do is re-point the source models. This is particularly useful if the scope of the Test model needs to be variable (for testing a specific bug fix, for example)
One final piece of advice and a warning to those who have taken a Prod model out of deployed mode; copying models creates a revision tag automatically, so if you will break compatibility if this copy is done after the initial Dev>Prod sync
I hope this helps
David
0 -
Thank you! @DavidSmith
0 -
Just to follow up with @linda_erickson question.
If I want to make a compatible model in a different workspace will we have to use the copy method? I didn't see an option to create a copy using a revision tag to any other workspace.
I successfully created a compatible model using the copy method but I had to copy the data too, as @linda_erickson suggested.
By the way, these videos are terrific. I'm sure I speak for a lot of people by saying thank you! This is what makes using Anaplan so easy.
0 -
Yes
However, you cannot do it on one go
First you need to create the copy and then move to the desired target workspace and import the new copy into there
The golden rule of compatible models is that the last revision tag in the target must exist in the source.
Assuming there are no outstanding structural changes in the model to be copied, when it is copied, it creates a revision tag in itself and the new copy, thus the compatibility is set up.
Importing the new copy to the new workspace doesn't set another revision tag, so the compatibility is maintained
I hope this helps explain it
David
0 -
Good tutorial.
Things that would be additionally good to have is some of the big issues that clients face while managing ALM in a post go live stage. That helps developers train the model admins before the leave.
0
