Duco provides staging copies and change control mechanisms to all our clients, for the purpose of testing different configurations of a process. However, some organisations, operating under stringent compliance landscapes, may require a higher degree of environment segregation. In such instances Duco offers development environments as an additional module. If you are interested in this module, please contact your Account Team.
As best practice, a typical setup will contain 3 environments with specific purposes for each:
*All environments run the latest released version of Duco.
You can deploy configurations between these environments, with the integration working seamlessly with our existing change control mechanisms.
Environment Characteristics
Environments come with their own URL, separate user base, SFTP data submission mechanism and API endpoints.
Volume, process and user limits are equal to your production environment. Environments are legally restricted to use for development, training and production testing.
Processes and their configuration are retained indefinitely, unless deleted by users. We retain Sandbox result data for 3 months.
Backups, failover and SLAs
Data is backed up to secure storage, in-line with our normal backup procedures.
The Support SLA does not apply to Testing and Sandbox environments and no support credits are claimable.
-
Logically segregated environment
- We will provide an additional, logically segregated environment for governance and adoption purposes. Additional environments will come with their own URL which will be used to identify it.
-
Shared hardware, segregated data
- Hardware may be shared between environments, but the environments will be completely logically segregated. This includes process configuration, audit log etc.
Sandbox
Sometimes called the “dev” or development environment. The sandbox environment is where processes should be built and tested with sample data. Also it can be used for training, and experiment with new rules and datasets - away from production change controls.
Testing
The testing environment can be used for user acceptance testing of processes deployment from the Sandbox environment. Processes that fulfil requirements can then be deployed to Production. If any issues are found, it should be fixed and tested in the sandbox environment, and be deployed to UAT for testing again. .
Some clients may have more relaxed control and allow some configurations to be changed in the UAT environment. In which case it is recommended that you (down)deploy the latest changes back to the sandbox environment to keep them in sync, to make sure next time when changes are needed, the sandbox environment has the latest version to be updated.
Production
Environment for running live processes. No configuration changes should be allowed in the Product environment, to minimise unwanted disruptions to daily operations.
Roles
There are roles specifically associated with the use of Development environments.
-
Process Configuration Exporter:
- Ability to deploy the configuration of a process between Development Environments (Only visible to clients using Development Environments).
-
Process Configuration Importer:
- Ability to import the configuration of processes that have been deployed from a Development Environment (Only visible to clients using Development Environments).
Overview
Purpose and benefits
Development environments enable change management with 4 eyes control, full auditing and segregation of data during build and testing phases, which is a key part of Duco’s self service and agility. Integrated Configuration Deployment aims to tackle the following key problems:
- Avoid manual configurations needed in production after deployment, such as groups, labels, reference data tables and submission routes. They are all included in the integrated configuration deployment, which helps to save time, ensure consistency across all environments and minimise human error. Duco will automatically map all components to existing ones by their names, or create new ones if it is not yet configured in the target environment, so there is no need for you to do any manual setup after deploying process configuration
- Automatically include any dependencies used by the process to be deployed and make all related changes at once. This helps to further reduce the amount of time needed to deploy multiple process configurations. This also enables a clearer change record that is easier to test and iterate, as well as auditing.
- Fully automatize change management process by leveraging APIs to create and approve packages with processes and their associated components with your own central change management systems.
Best practices
While using this feature, we recommend to follow the principles below:
- All configuration should take place in Sandbox and be deployed through UAT to Production.
- No new processes should be created in the UAT environment.
- Deploying the process from the sandbox directly to production (hence skipping UAT) should not be allowed.
- Directly referring to specific users in configurations such as Workflow rules and permissions should not be allowed, all references should be group-based to avoid dependencies on individuals and make managing of user joining and leaving teams more easily.
- Deleting components which were previously promoted via configuration deployment is not advisable, as it breaks subsequent deployments to that environment with the same components in the package (for example, if you delete groups that were created from a deployment, trying to promote those same groups later on may return an error)
Integrated configuration deployment between environments
Creation of a package
- To create a package navigate to the Administration page -> Configuration deployment -> Create package
- Make sure to name the package appropriately to reflect the change scope, together with description, then select the target environment to deploy to. .
- Select one or more reconciliations or Data Prep Processes to form a package - Duco will automatically include all necessary related components. In order to view all components associated with a deployed process, click on components number, which will redirect you to the Components tab with pre-filtered components.
- Duco will automatically show related Processes that can be included or excluded from packages. For example, when selecting a parent process, Duco will suggest adding associated connected processes:
- To ensure the process will be deployed without any issues, when selecting a connected process, the associated parent process will be automatically added to the package.
- Duco will perform checks to ensure that any processes or reference data tables have at least one group with ‘Config Admin’ or ‘User Admin’ included (to ensure they are accessible in the target environment). Any other problems that may prevent you from creating a package will be highlighted with a red triangle and the ‘Create and deploy button will be disabled:
- To view all components that will be deployed, navigate to the ‘Components’ tab (remember to reset filters on the ‘used by’ column, if you have any). In this screen, you will see the extensive list of all labels, groups, submission routes and processes where these components will be used.
- When you are ready to create and deploy the package, the next step is to hit the ‘Create and deploy’ button. The package will then be created with a unique ID, and deployed to the target environment for review.
- Login to the target environment to review the package.
Review package on the target environment
Each manually created component is unique, such as:
- The first time a component is deployed it will be treated as new in the target environment
- Subsequent deployments of each component will overwrite existing deployment
- Subsequent deployments of component with updated names will be treated as overwrites
Navigate to the ‘Configuration deployment’ section in the ‘Administration’ tab to see all the packages deployed to this environment, along with their statuses. Open the package to review the request by clicking on the package name:
To review what are the process configurations in the package, click the “Download config” button, which will give you all the configuration documents for all processes included in the package.
This screen also gives you visibility of all included components, and it is where you can approve or reject a package. Approved packages will be validated and fully deployed with no further manual tasks needed (such as merging staging copies to parent process)
Previously approved / imported packages can be re-deployed to a new target environment. This means that after user tests and provide a sign off for new configuration, you can take the exact package that was promoted from Sandbox to Testing and deploy it to Production. This can be done by opening a package that was deployed from Sandbox and clicking the ‘deploy package’ button.
Rejected packages will stay active for 7 calendar days after rejection. In case the reviewer made a mistake, the package can be re-approved and applied to the environment. After that period, those packages will no longer be approvable. Deploy it from the source environment again.
Possible statuses associated with Integrated configuration deployment process
Status | Description |
Import request - Pending | A package deployed from source environment (Sandbox) is awaiting approval/ rejection |
Import request - Rejected | A package deployed from source environment (Sandbox) was rejected in current environment (Testing) |
Import request - Approved & imported | A package deployed from source environment (Sandbox) was approved in current environment (Testing) |
Pending on target | A package deployed from current environment (Testing) to target environment (Production) is awaiting approval/ rejection |
Rejected on target | A package deployed from current environment (Testing) was rejected in target environment (Production) |
Approved on target | A package deployed from current environment (Testing) was approved in target environment (Production) |
Generating package | A package is being generated, for both manually and API created packages |
Failed to generate package | A package failed to generate due to an error, for both manually and API created (package creation only) |
Failed to deploy package | A deployment failed due to an error (future deployment only) |
Importing | An import request has been approved and the package is being imported to target environment |
Handling non-breaking changes
The main challenge of changing a reference data table definition is about potentially breaking live data that’s already in the table, which may be essential for existing processes to run - hence we only support non-breaking changes:
Changes | Capability | Notes |
Change table name | Possible | |
Change column name | Possible | |
Add column (to the end) | Possible | |
Remove column | Not possible | Requires changes to active data |
Change column order | Not possible | Requires changes to active data |
Change column data type | Not possible | Requires changes to active data |
Audit and compliance
- Users who have both ‘Configuration Exporter’ and ‘config admin’ roles enabled can select any process for inclusion in a packaged environment deployment
- All related components will also be automatically selected, regardless of the user's individual permissions associated with components
- Existing “Configuration Importer” permission allows users to approve / reject a package
- All exports are audited in the source environment
- All approvals or rejections are audited in the target environment
Unsupported components
While using the Integrated configuration deployment feature, bear in mind the following:
- Deployment of users (associated with Groups or referenced in a process or other components) is not allowed
- Deployment of Domain whitelist and processes with Masking feature enabled is not supported
- Ability to use Integrated configuration deployment to delete any component in a target environment is not allowed
- Since Reference Data Tables names are not unique, we link this component between environments by their unique ID, not by their names. This means to ensure this process works smoothly in the future, you might need to replace old RDT with the newly created one for first-time promotions on already live RDTs.
-
Deployment of any records in reference data tables is not possible
- This can be handled through existing APIs for extracting and delivering onto SFTP for consumption (as per 100k lines max, CSV input source only)
- Regenerating a new package based on the latest configuration of components listed in an existing package is not allowed
- Integrated configuration deployment does not support building a package, saving it and coming back to it before exporting
- A single package of configuration should contain no more than 50 processes plus their associated components
Cash module is not supported hence any cash processes should be deployed between environments by using Configuration export/ import feature (link to HC article)