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