Application Lifecycle Management (ALM) has been available since late 2016, and it is used widely and successfully across the Anaplan-customer base. ALM is founded on certain fundamental rules and structures, which if followed, will ensure the integrity between development, test, and production models is maintained.
This is the first of a three-part series which will explain in detail some of these fundamental rules, techniques to validate the changes prior to deploying to production, and finally, what to do if things go wrong.
This series does assume that you already are familiar with ALM and understand the basic concepts. If you are new to ALM, it is advised to review the various articles and training materials available on Community and Anapedia. Here is a good starting point.
Let’s start the series by looking at the fundamental concept of ALM—compatibility. We will look at what compatibility is and how it is set up, how to ensure models stay compatible, and what to do to avoid breaking compatibility.
Compatibility is the term used to describe whether two or more models can be used as part of the ALM synchronization process—the process in which structural changes are deployed from a development model to test and production models. Structural information consists of a model's configuration settings and lists (with the exception of production lists). Structural information can't be edited when a model is in deployed mode. Changes that affect a model’s structural information are known as structural changes.
The other two terms associated with compatibility are source and target models.
For a source and target model to be compatible, the two models must have a common origin. That means they both originated from the same revision, such as when one model has been copied to produce two models. Also, only one of the two models can have structural changes after it was copied or synchronized.
Let’s look at the first condition; common origin.
To initiate ALM, a model must be copied. It does not matter if you create a development model by copying a production model, or if you create a production model by copying a development model. It is the copying process that creates the common origin and creates the initially shared revision tag.
If this is the first time the models have been copied, then a revision tag called “Copy Model” will be created in the source and the target models.
The “Copy Model” revision tag will also be created if there are any structural changes outstanding, i.e. changes that have not yet been crystallized in a revision tag (you can tell if this is the case because the “Add Revision Tag” icon is bold).
Assuming the model is copied without adding a revision tag for those outstanding changes, you will see the Copy Model revision tag in the source model once it is copied.
Assuming the revision tag was added for the outstanding changes, you will see the named revision tag in the development model.
Note that in the development model, the “Add Revision Tag” icon is now greyed out; this signifies that all structural changes have been captured in the revision tag or no structural changes have been made since the revision tag was added.
In the production model, when synchronized, the same revision tag is shown.
It is also possible to use the “Create Model From Revision” option.
This will create a copy of the model structures but will not create entries for production lists members or associated data. This is especially useful when setting up ALM, as it adheres to ALM best practices of keeping the development model small; it will create a shell model of just structures, so the development model will be much smaller than the production model (assuming you have set production lists in the production model first).
It can also be used to create a production model from a revision tag that is not the latest one within the development model; e.g. if you have already started work on phase 2. Using either ‘Copy Model’ or ‘Create Model From Revision’ will create a compatible model within the same workspace. As per best practice, this model should then be imported to a separate workspace.
Note that importing models across workspaces maintains the compatibility; it is possible to synchronize models across workspaces.
We mentioned above that is it possible to have multiple target models form a single-source model, and when many copies are taken (including archived models), it can be rather confusing to know if a target model is compatible with a source. There is a simple statement that will help clarify this.
“The latest revision in target model must exist in the source model.”
In our example, we can see that ‘Revision 2.1’ is shown in both source and target models. It is possible to create revision tags with the same name in different models, so to double-check, click on the icon next to the revision tag; this will show the source of the revision tag.
For ALM integrity, models must remain compatible. If, when running the synchronization process, you see a message like the one below, it is most likely that the models are not compatible.
There is one exception. The last part of the description above states “a more recent revision tag must exist in the source model”. If you have just run a synchronization or are in the process of making changes in development but not yet added a respective revision tag, both models are structurally compatible, but there are no changes to the process, so the message appears.
This diagram shows the different stages of a development model and the associated message (assuming the models were compatible in the first place).
To maintain compatibility, the one golden rule to remember is: “Never take a production model out of deployed mode.”
Deployed mode prevents structural changes being made (even by an administrator), so if the production model is always in deployed mode, it is not possible to break compatibility. However, we do have situations where the compatibility is broken. So, if deployed mode prevents compatibility being broken, how does this happen?
Remember at the outset, the second element of compatibility was that only one model can have structural changes. Models cannot be compatible if there are structural changes in both source and target models. To make structural changes in a target model, the model mode must be changed from deployed to standard.
Taking a model out of deployed mode is not something that happens by accident. There are a number of steps needed to take a production model out of deployed mode:
However, despite this warning, target models are taken out of deployed mode. The main reasons for this are:
The latter two points are difficult to police, but depending on the circumstances, it might be possible to restore compatibility, if and only if, a revision tag has not been set in the target model. If that has happened, the rule “the latest revision in the target must exist in the source” will have been broken. Once a new revision tag is set in the target model, compatibility is lost forever.
The following shows the different circumstances of compatibility:
It is possible to “flip” the modes from deployed to standard without breaking the compatibility, but why would you? Any structural changes made will break the compatibility, even if done by accident.
The second situation is the most common and we will cover how to recover from it shortly, but in this state, it is easy to “accidentally” set a revision tag. A common occurrence in the field is developers make changes to test or check something. They know about the compatibility issues and understand that they will have to set the target model back as it was, so to preserve their work for reference, they copy the model.
As mentioned above as part of the initialization process, copying a model creates a new revision tag, immediately breaking compatibility. So, unless you are starting/re-initiating ALM from scratch and you have taken your target model out of deployed mode, DO NOT COPY IT.
As outlined, taking a model out of deployed mode is risky and should be avoided, but let’s finish by outlining how to restore compatibility.
Let’s assume a target model has been taken out of deployed mode and structural changes have been made. (Note: no new revision tags have been set in the target model).
We now want to synchronize ‘Revision 3’ to our target model.
As we navigate through the process, it seems initially that the models are still compatible; after all, they do still share a common revision tag (‘Revision 2.1’). Only in the final step to confirm the synchronization does the problem become apparent.
As mentioned, it is possible to restore compatibility (if no new revision tags have been set).
Navigate to the Revision Tags tab, and if structural changes have been made, the “Revert to Last Revision” icon will be bold.
Click the icon. As the message says, this will revert all structural changes made since the last synchronization, so setting the target model structures back to those as at ‘Revision 2.1’.
Reverting will restore the compatibility allowing the target model to synchronize to ‘Revision 3’.
Once ALM is initiated, there is no real reason why compatibility should be broken or mode models should be changed. It is always possible to start the ALM process again which will re-initiate compatibility, but this will not restore compatibility between existing models; rather, it will set up compatibility for a new set of models:
Compatibility is key to the Application Lifecycle Management process. There are defined rules and model modes designed to maintain this compatibility. Following these rules will allow ALM to be used effectively without issues.
Part two of the series will cover how to test changes to prevent issues post-synchronization.