Setting up your environment
Exactly how you will want to manage your Org to enable version control and environment promotion will depend on your use case and which package of Tray you are working with.
Exactly how you will want to manage your Org to enable version control and environment promotion will depend on your use case and which package of Tray you are working with.
Workspaces as environments
You should make use of shared workspaces to manage your environments. The following diagram shows a multiple workspace setup whereby you have dev and prod workspaces for each department. Workspaces can be created and used to sub-divide your organization, for example:
- Company departments (sales, marketing, HR etc.)
- Internal teams
- A bespoke integration for a customers.
- Control what access each user has access to which env/workspace
- Auths are only available to users in that workspace
- Export project from department dev and import to department prod workspace
- Create in organization workspace to make custom services and custom connectors available to all workspaces
Embedded integrations setup
For Enterprise customers building out Embedded integrations, it is not currently possible to create Solutions in shared workspaces. In order to manage multiple integrations you will need to set up multiple Tray orgs to act as e.g. dev, staging and prod. Each integration is then promoted from the 'Embedded' workspace of one account to the next. This is the most common setup for Embedded environment control, and is most effective in terms of segragating users, auths, test vs live data and End Users
| Feature | Notes | Limitations |
|---|---|---|
| Users (RBAC) | Users in dev account have access to all dev projects and auths. Same for prod account users | Unable to assign different roles to users per project |
| End Users | Use Test End Users in staging/dev environments so that billing is not affected | |
| Auths | Dev workspace auths are available to be used in all dev projects. Same for prod workspace auths | Cannot limit auth access per project within an environment |
| Promotion method | Export from project in dev, import to project in prod | |
| Custom services | Will need to create in each account | During env promotion, need to map custom services |
| Custom connectors | If using a custom service, will need to create in each account | During env promotion, need to map custom connectors |
| Tokens | Each env has its own token - use separate master tokens to connect with dev and prod in your codebase |
Dependency prerequisites
You will need to make sure that all services, connectors and authentications are mirrored from one environment to the next. This page will take you through the different options.
Custom services
Any custom services must be replicated in all environments before first import. Custom services here refers to services for which you have set up a custom authentication mechanism - primarily for services which do not have a pre-existing Tray connector and you wish to connect with using the HTTP client. When you first import a project which has a workflow step which makes use of a custom service authentication, you will be asked to map it to the relevant service in the destination environment. Note that, for token-based services it is possible to use the ‘Generic service’ creation method, which allows you to create the service on the fly on first import.
Custom connectors
Any custom connectors you have built using either the CDK or Connector Builder must be shared with both environments Custom connectors are generally built when there is no pre-built Tray connector for a third-party service and you wish to build a full set of pre-configured operations in a single connector (i.e. using the HTTP client to access one or two endpoints is not sufficient) Connectors built with Connector Builder can be shared with individual users. Therefore you must make sure a connector has been shared with all relevant individuals within all environments via the CDK deployment API.
Custom OAuth apps
Custom OAuth apps are primarily used for whitelabelling logos and urls in Embedded integrations. Note that the only way to create a Custom OAuth app is via the workflow editor where you must:
- Add a connector step for the relevant service
- Create a new auth
- Choose the 'use own OAuth app' option in the auth dialog This must be done in both the source and destination environments before creating and importing the first version of your project. So in the destination environment you may need to create a test workflow specifically for this purpose.
Project / workflow dependencies
It is generally advised to make your projects 'self-contained' in that callable workflows and alerting workflows should be part of the project.