Chapter 6

Revision Tags

6.01-01 Create a Naming standard

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!

6.01-02 Create a Revision Tag at least once a day

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

6.01-03 Revision documentation

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

6.01-04 Synchronize Production regularly

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

 

6.01-05 Dummy Test Model

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

 

Production Lists

6.02-01 Define Production lists before the first sync

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

6.02-02 Formula protection - Hard coding

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

6.02-03 Review the need for Production Lists

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

6.02-04 Don't click and hope

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

 

Architecture

6.03-01 Don't take the model out of deployed mode

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

6.03-02 Use deployed in Dev mode for additional security

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

6.03-03 Keep Test models in Deployed mode

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

Deployed Mode

6.04-01 Back to the Future

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

6.04-02 Switchover

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

6.04-03 Master Dashboards

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

Managing Changes During Development

6.05-01 Make DEV the source for everything

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

6.05-02 Archived Models

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

6.05-03 Model modes

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

 

6.05-04 Keep the Development model small

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

6.05-05 Use a Data hub to populate the Development Model

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

Knowledge Base Dashboard