# Understanding project deployment with environments
FEATURE AVAILABILITY
This guide is applicable to workspaces with the Environments feature enabled. Environments is available for direct and Embedded users. Learn more about Environments for Embedded customers.
Video guide: Build, test, and deploy with Environments
With just a few clicks, you can easily deploy projects to different environments. For example, when a recipe is ready for testing, you can deploy it from the Development (DEV) to the Test environment.
This guide covers the following topics:
# Deployment basics
- How does deployment work?
- Who can perform deployments?
- What can be deployed?
- Where can I deploy projects?
- How are recipe dependencies handled?
- How do deployment updates affect the target environment?
# How does deployment work?
In Workato, deployment is a process that pushes recipes and other assets from one environment to another as part of recipe lifecycle management (RLCM). Recipes are typically developed in the Development environment, deployed to the Test environment for validation, and then deployed to the Production environment directly from the Development environment following testing and approval.
When deploying a project, you can either deploy to an environment or download a ZIP file version as a package.
# Who can perform deployments?
To deploy a project to an environment, a collaborator needs:
- Access to the project to be deployed
- The deployment privilege enabled in the environment containing the project.
- The deployment privilege enabled in the environment you plan to deploy the project to.
For example, to deploy a project named HRBot from Development to Test, you must have access to the HRBot project in Development, and the deployment privilege must be enabled in both the Development and Test environments.
ENVIRONMENT ACCESS RESTRICTION
A collaborator with access to only one environment can't deploy projects.
# What can be deployed?
Deployment occurs at the project level. You can deploy any type of asset, such as recipes, connections, and lookup tables, but only from a single project at a time.
# Where can I deploy projects?
You can only deploy projects from the Development environment. The Test and Production environments serve specific purposes:
- Use the Test environment to test recipes.
- Use the Production environment to run finalized recipes.
This restriction ensures consistency, prevents conflicts, and records a complete deployment history in the Project > Deployments tab.
For guidance on structuring your workspace and planning recipe development using environments, see Environment structure and planning.
# How are recipe dependencies handled?
When a project is deployed to an environment, dependent relationships are deployed and maintained:
If the dependency exists in the target environment, the reference will be automatically resolved.
For example: A lookup table used by a recipe already exists in the target environment prior to deployment. In this case, the reference would be automatically resolved.
If the dependency doesn't exist in the target environment, then the reference must be resolved by you.
For example: A lookup table used by a recipe already doesn't exist in the target environment prior to deployment. In this case, you'd have to deploy the lookup table from the source environment to resolve the reference.
RE-ESTABLISH CONNECTIONS AFTER DEPLOYMENT
Reconnect connections after deploying them to an environment for the first time. Recipes cannot run until you re-establish the connections.
# How do deployment updates affect the target environment?
The system makes deployment updates in the target environment based on the project’s status:
If the project doesn't exist in the target environment, all recipes and assets deploy as new.
If the project exists in the target environment, the system overwrites existing recipes and assets and adds new recipes and assets. However, if you move a recipe or asset to a different folder in the source environment, the target environment does not recognize this as an update. Instead, a new instance of the recipe or asset is created in a new folder within the target environment, keeping the original instance in its previous folder. This results in two copies of the recipe or asset in the target environment, one in the original folder and one in the new folder.
The system does not delete recipes or assets removed from the source environment. For example, if you delete a Slack connection in Development and deploy to Test, the Slack connection remains in Test.
# Deploying projects
# Deploying to an environment
Ready to start deploying projects to environments? Check out the Deploying a Project to an Environment guide for step-by-step instructions.
# Downloading a project package
Similar to exporting a package using RLCM, you can download a ZIP file package of a project. You can download the entire project or customize which recipes and other assets to include.
After the download is complete, you can upload the package to a version control system or import it to another Workato instance.
# Viewing deployment details
You can view deployment details in a project's Deployments tab.
DEPLOYMENT PERMISSIONS
Only users with deployment permissions can see this tab. Project deployment logs are only available in the Development environment.
Deployments tab
To see what was deployed, click an entry in the history list of past deployments. This action opens a new page displaying the deployment details.
View deployment details
In addition to the deployment activity log, all deployments are included in your account's Activity audit log (Operations hub > Audit).
# Resources
Last updated: 12/2/2024, 7:22:45 PM