CSM 10.4 Documentation

Home

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 needed will vary based on project, but ensure that the following minimum information is shared:
  • 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® Solution

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

Blueprints allow you to:
  • 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.
mApp Solutions allow you to:
  • 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 Solution 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 Frequent Backups

Before publishing Blueprints or applying mApp Solutions to the master development database, create a backup .czar file of the system. See Database Export Tool. If the Blueprint or mApp Solution causes significant errors, the database can be restored using the backup file. Also, consider automating frequent backups using the Backup Database option in the Scheduler. See Define Action Properties for a Scheduled Item.

Use a Consistent Naming Convention

Ensure that all Blueprints and mApp Solutions follow a consistent naming convention that includes:
  • When the Blueprint or mApp Solution 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 Solution files in a common location in a network share. Then, the Blueprints or mApp Solutions 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 the Cherwell Application Server,Automation Process Service, 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 a 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.

Was this article useful?