Chapter 6

Be consistent with how you name your revisions. It is advised to use a Major.Minor nomenclature (e.g. R1.01, R1.02, R2 etc.). Remember, the description is permanent and cannot be changed - Be careful!

During periods of intense development, ensure that revision tags are created regularly and tested against a "shell" model

Best Practices article:
Revision Tag Best Practices

If you need a broader description of revisions, create a normal list (Non Production Data) and then house the revision details in a module with other fields such as Approved date User Story, Developer, Tested date, Sign off date etc.

Best Practices article:
Revision Tag Documentation

Minimize the risk of sync errors by synchronizing regularly to keep Production and Development aligned

Related to Rule:
6.01-02 Create a Revision Tag at least once a day

Best Practice article:
ALM Explained—Part 1: Compatibility

Set up a "shell" model (using create from revision) that contains no production list members on which to test revisions and synchronises regularly

Related to Rule:
6.01-02 Create a Revision Tag at least once a day

Best Practice article:
ALM Explained—Part 2: Testing

Don't set all lists to production initially. Setting a list back to Structural (after a synchronize) will remove data from the existing production list even if the members are the exact same

Best Practices articles:
Prepare Applications for ALM
ALM Explained—Part 3: Avoiding Data Loss

You cannot hard code a reference to an item in a production list because that member may be deleted by an end user

Best Practices article:
Formula Protection

Only lists that require amending as part of the business process, or where the lists are populated by imports should be set to production lists

Best Practice article: 
ALM Explained—Part 3: Avoiding Data Loss

Review the referenced by column of potential lists and check for hard coded formula references before checking them as production so you don't generate rollbacks

Related to Rule:
6.02-02 Formula protection - Hard coding

Best Practice article:
ALM Explained—Part 3: Avoiding Data Loss

Once ALM has been initiated, and Deployed mode is turned on, the Production model should NEVER be taken out of Deployed mode

Exceptions:
6.03-01a Development Model creation - When copying a Production model to create the initial ALM environment, or when re-creating the DEV model as part of a “reset”
6.03-01b There are no other exceptions! - It is just not worth it. ALM brings control, but there are rules, and Deployed mode is the key rule

Best Practice article:
ALM Explained—Part 1: Compatibility

Setting deployed mode for Dev models is OK and can prevent inadvertent structural changes being made outside of normal development cycles

Test models should be treated as Production Models.  This gives a true representation of testing and also prevents inadvertent synchronises from Test to Prod

Best Practice article:
ALM Explained—Part 2: Testing

This is a technique that reverts the model to a previous revision, allows you to make a fix, sync to Production, and then return Development back to where it was

Best Practice article:
Saving incomplete changes during development

After a revision, create multiple revision tags with different switchover dates prior to starting new development

Best Practice article:
Managing Frequent Structural Changes During Development

Master Dashboards will delete any personal dashboards.  Techniques to minimize user disruption include creating a copy and have a migration process to move users to the new dashboards

Related to Rule:
4.01-14 Enable Personal Dashboards

Best Practices article:
Personal Dashboards - Tips and Tricks

DEV> Test, and DEV>Prod is more flexible; it allows multiple Test models, and Test models to be created and deleted without compromising Prod.  It also supports segregation of duties

Best Practice articles:
ALM Explained—Part 1: Compatibility
ALM Explained—Part 2: Testing

Compatible models (DEV, TEST or PROD) can be archived without breaking the link between them

Related to Rule: 
6.05-03 Model modes

Best Practice article:
ALM Explained—Part 2: Testing

When restoring Archived models, restore the model to Deployed mode if this is a Production or Test model

Related to Rule:
6.05-02 Archived Models

Keep the Development model as small as possible.  Try and only use a selection of items in the production lists to minimize the model size.  Use the “create from revision” functionality as part of the set up

Best Practices article:
Prepare Applications for ALM

Use saved views within the Data Hub to populate the Development model.  This allows defined data and structures to be imported to assist initial development and component testing