Best Practices for Concurrent Development

Use the following best practices as part of your organization's Software Development Lifecycle (SDLC) to enable multiple designers to work simultaneously on system changes.

Communicate, Communicate, Communicate

Communicate with your team as much as possible. The level of communication will vary based on project, but ensure that the following information is shared at the very least:
  • The Major Business Object and any associated Supporting or Lookup Table Objects that you will work on (example: I'm going to work with Incident and Tasks). Also communicate any associated Views or features.
  • Features (example: Calendar) you will work on that do not have an associated Business Object.
Communication might include:
  • Setting up automatic e-mail notifications (possible in most software).
  • Manually sending e-mail or chat messages.

Decide Whether to Use a Blueprint or mApp

Before beginning the project, decide whether to use a Blueprint or mApp for your system configuration by considering the characteristics and benefits of each.

Blueprints allow you to:
  • Use two or more Blueprints to develop the functionality and then apply each Blueprint to the production environment.
  • Use the Blueprint Changes window to view a list of changes included in the Blueprint, remove selected changes from the Blueprint, and compare the version of a change in the Blueprint with the version of the item in the current system.
  • Use the Resolve Blueprint Conflicts window to view a list of conflicts between your Blueprint and the current schema. Choose item by item which changes to apply and which to discard.
mApps allow you to:
  • Use one of two options:
    • Use two or more Blueprints to develop the functionality and then create a mApp to apply the functionality to the production environment.
    • Use two or more mApps to develop the functionality and then apply each mApp to the production environment.
  • Use the Blueprint Changes window to view a list of changes included in the Blueprint, remove selected changes from the Blueprint, and compare the version of a change in the Blueprint with the version of the item in the current system.
  • Specify what to import down to the field level of a Business Object.
  • Define the specific merge action to take for each item (example: import, overwrite, delete, etc.).
  • Rebase (refresh definitions) by looking at the current system's version of each item included in the mApp and bringing the older definition up to parity with the latest definition.

Assign Business Object and Feature Owners

Assign individual Business Objects (including their Views and associated features) and features (that do not have an associated Business Object) to different designers as their area of responsibility. For example, one designer is responsible for Incident changes (including the Portal View for Incident) and another designer is responsible for Calendar changes. If multiple designers need to work on the same Business Object or feature, ensure that the designers are using a check-in/check-out process (refer to the Create a Check-In/Check-Out Process section below).

Create Multiple Working Databases

Use multiple CSM databases when implementing concurrent development using Blueprints or mApps:
  • Have one independent development database for each designer.
  • Have one master development database where one or more gatekeepers are allowed to make changes.

Designers can use their independent development databases (which are restored using the master CSM development database) to develop their individual system configurations. Only approved changes are applied to the master development database (which is restored using the current production environment).

Create Frequent Backups

Before publishing Blueprints or applying mApps to the master development database, create a backup .czar file of the system. If the Blueprint or mApp causes significant errors, the database can be restored using the backup file. Also, consider automating frequent backups using the Backup Database option of the Scheduler.

Use a Consistent Naming Convention

Ensure that all Blueprints and mApps follow a consistent naming convention that includes:
  • When the Blueprint or mApp was created.
  • The primary Business Object.
  • The designer’s name.

    (example: 2016-12-10-Incident-Johnson.bp or 2016-12-10-Incident-Johnson.mapp)

Store all final Blueprint or mApp files in a common location in a network share. Then, the Blueprints or mApps can easily be grouped together and applied to the production system in the appropriate order.

Evaluate Security Risks

Consider security risks to both development and production environments throughout the lifecycle of the project. Risks might involve:
  • Customer data, including personal or company information.
  • Business Object data, including existing active and inactive records.
  • Impacted CSM Services, such as Application Service, Automation Process Server, etc.
  • Impacted external connections, such as SCCM, Outlook, Active Directory, etc.

(Optional) Create a Check-In/Check-Out Process

If more than one designer must work on the same Business Object, create a process similar to the following that allows designers to check out a particular Business Object:
  1. Create a master list of all target Business Objects. This can be done using a custom Business Object in CSM, a spreadsheet, or a wiki page.
  2. Notify all other designers and update the master list when an item is checked out. The checkout lasts until the changes have been approved by the gatekeeper and applied to the master development database.
  3. Create a .czar of the updated master development database. The next time work is done on the item, the designer must use new .czar.
  4. Notify all other designers and update the master list when an item is checked in.
  5. Repeat steps two through four until work on the item is complete.