This article contains recommendations common for all developers implementing any functionality or fixing issues on the existing SimpleOne solutions.
Before you start
Before starting the development on an instance, create separate user accounts for the developers. The simultaneous work of various developers authorized under one account may lead to collisions and other adverse effects.
After creating these accounts, grant them the roles necessary for the development: admin, security_admin, impersonator.
Guidelines for managing local packages
Follow these guidelines when creating your local packs:
- Collect the changes made for each task into a separate configuration pack.
- A local pack name should contain the application acronym and a short description of the task.
- Use the Name and Description fields to provide all the necessary information on the package. The Name field maximum length is 80 symbols.
| Good | Adding translations for all buttons on the Task table |
|---|---|
| Bad | Last fixes |
It is a good naming practice to to include the task number in the local pack name, for example: [ITSM] - Incident notification fixes - INC0001234
Do not perform configuration activities within the Default local pack.
Record policy
After development is over, ensure that:
- No redundant changes were added to the local pack.
- No record versions have the Record policy set to Changed.
- If there are any, fix such record versions automatically using the Export → As a new application UI action located in the hamburger menu
on the top left.
- If there are any, fix such record versions automatically using the Export → As a new application UI action located in the hamburger menu
When building a local pack containing changes for any application objects provided by the vendor, do not change the Record policy attribute value of the related record versions to Open. It may lead to the version state missing when the application update is delivered.
To avoid conflicts when updating application versions provided by the vendor, do not change the OOB-configuration. Instead, follow the guidelines below:
- Clone the configuration you need to update using the Make a copy UI action (this UI action is located in the form hamburger menuon the top left).
- Deactivate the original configuration:
- Return to the form of this configuration.
- Clear the Active checkbox.
- Click Save or Save and Exit to apply the changes.
- Make changes to the created copy, not to the original record.
Test configuration packages
Avoid configuring applications directly on a production instance when a development instance is available. Aggregate all changes to configuration packs on the development instance first. After that, deploy them on the testing instance (if you have one). Deploying to the production instance should be the last step after all the errors and collisions are solved.
This approach ensures rapid problem solutions on the development instance, without a downtime risk for a production instance.
