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.

Accepted answers

All comments

Bob-Bachynsky

Hi Shashishankar, I'm going to send you a PM directly. - Thanks!

spakhira

Super informative and useful tutorial!

linda_erickson

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

DavidSmith

@linda_erickson

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

linda_erickson

Thank you! @DavidSmith

JaredDolich

@DavidSmith

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.

DavidSmith

@JaredDolich

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

kausghosh

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.

Quick Links

Can you help?

Unanswered questions

Request for Workflow Design: End-User Report Finalization & Stakeholder Notification with Version Co
Hi everyone, I'm looking to design a workflow and would appreciate your input or guidance on how to set this up effectively in Anaplan. So, the goal is: Once end users complete their data input, they should be able to trigger a process that: Notifies stakeholders via email with a link to a report. The report includes: A…
Generating Failure Dump - even though no warnings/error in Actions
I've few actions in our Supply model which when run takes some time on the "generating failure dump" step at the end of the action even though the import is a full success without warning or errors. This is just a few seconds when run for a single action, however we have a process with 120 actions, and most of these…
OAUTH 2.0 vs Google Sheets Extension
Hi, My org is looking to explore leveraging Google Apps script to extract data out of Anaplan and update already built templates in Google Sheets. We use the Anaplan Extension currently but find it crashes often with the amount of tabs, data, etc. Has anyone used both Anaplan OAUTH 2.0 API and Goolge Apps Script to write…