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
- 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.
- 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.
- 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.
- 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
- 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
- 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
- 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
- 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.
- 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.
- Create a .czar of the updated master development database. The next time work is done on the item, the designer must use new .czar.
- Notify all other designers and update the master list when an item is checked in.
- Repeat steps two through four until work on the item is complete.