NOTE: In some cases, Dev and Test may be the same instance.
NOTE: Multiple browser tabs or windows open to different versions of the product is not supported.
New flows and recipes are created in a Development instance of the platform. Experiments can be undertaken without concern that production use of the recipe or flow is affected.
Rules should be established on how flows, datasets, and recipes are organized and structured. Where are these assets stored? Where are shared versions of them made available? What are the rules by which items in Dev can be moved to Test/Prod?
In the Testing deployment, the objects in development are subjected to various stress tests. In the
In the Production deployment, flows and their objects are presumed to be ready for regular, read-only use. After imported flows are reconfigured for the environment, they are ready for immediate use and require no further modification.
When errors are detected, you can:
When objects are moved between environments, paths and other object-related references may require updating to point to the new environment.
NOTE: Import mapping rules do not work for parameterized datasets. If the imported dataset with parameters is still accessible, you should be able to run jobs from it.
For example, a dataset in the Dev environment may be pointing to the following location:
For the Prod version, the flow may need to be changed to the following:
To support this kind of remapping, you can specify import rules at the level of individual deployments.
NOTE: For each deployment that you create, you must define new import remapping rules.
These rules can be specified using literal values,
|D s item|
- If possible, you should maintain separate instances of the platform for Dev and Prod.
- If you must use the All-in-One method of managing Dev and Prod instances, you should maintain a small number of non-admin accounts that are specifically used for Deployment Manager.
- Avoid scheduling Prod executions through Flow View. While possible, these schedules continue to exist even if the version of the flow has been replaced by another. Consequently, schedules that were specified through the application continue to execute, even though the flow itself is outdated. Instead, scheduled executions should be specified at the command line through cron jobs pointing at the latest release of each at all times.
- Do not modify Flow View settings through a Prod instance. These settings are not applied back to the Dev version and are lost when the next release package is imported.
NOTE: Running a package containing more than 5 concurrent jobs is not supported.
You can configure jobs on-demand through the Flow View page of a Production instance. See Flow View Page.