This article contains recommendations common for all developers implementing any functionality or fixing issues on existing SimpleOne solutions.
Before you start
Before starting the development within the instance, create separate user accounts for the developers. The simultaneous work of various developers authorized under one account may lead to adverse effects, such as collisions.
After creating these accounts, grant them roles necessary for the development: admin, security_admin, impersonator.
Process guidelines
Follow these guidelines when making out your local packs:
- Roll up the outcome of each task into a separate configuration pack.
- The local pack name should contain the application acronym and a short description of the task.
| Good | Adding translations for all buttons on the Task table |
|---|---|
| Bad | Last fixes |
It is a good naming practice to place a task number into the local pack number, for example: [ITSM] - Incident notification fixes - INC0001234
You can use the Description field along with the Name field for the sake of clarity to keep all the necessary information. It's quite OK if the Name field maximum length, 80 symbols, is not enough.
All configuration activities should not be performed within the default local pack.
Record policy
After development is over, make sure about two points:
- No redundant changes were added to the local pack.
- No record versions have the Record Policy attribute value equal to Changed.
- If there are any, then you can fix such record versions automatically using the Export → As a New Application UI action located in the form hamburger menu on the top left
.
- If there are any, then you can fix such record versions automatically using the Export → As a New Application UI action located in the form hamburger menu on the top left
When building up local packs containing changes for any application objects provided by the vendor, do not change the Record Policy attribute value for 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 out-of-the-box configurations delivered by default. In this way, 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 menu on the top left ).
- Deactivate the original configuration:
- Return to the form of this configuration.
- Unselect the Active checkbox.
- Click Save or Save and Exit to apply changes.
- Make changes to the created copy, not to the original record.
After finishing
Avoid configuring applications directly on a production instance with a development instance 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 on the production instance should be the last step after all the errors and collisions are gone.
This approach allows to rapidly finding possible problems on the development instance, without downtime risk for a production instance.
