About Project Deployment

Use a project deployment to move automation solutions with integrations and robots to a higher environment, such as from development to testing. Project deployments offer convenience, easier activation of integrations, and improved stability of your testing and production environments.

If your process for deploying automation solutions to a new environment has focused on moving only updated integrations, a project deployment is going to offer new capabilities, including a more stable production environment. To take advantage of all the benefits of production deployments, you'll need to approach your promotion differently. Keep reading to learn more.

Think Beyond New and Updated Integrations and Robots

Before working in projects, when you needed to deploy a new or updated integration to a testing or production environment, you probably moved only the new or updated integration.

To take advantage of the convenience of project deployments, including easier activation of integrations, you can continue this practice and include only new and updated integrations in each project deployment. However, to gain improved stability in your testing and production environments, you should deploy differently when working with project deployments.

Project Deployments Are the Current Snapshot

Think of a project deployment as a snapshot of all the integrations that must be in the environment that you're promoting to. For instance, consider a project with fifteen integrations. You included ten of the integrations in an earlier deployment and promoted them to your testing environment. You're now ready to promote the remaining five integrations to the testing environment.

Before working in projects, you probably would have moved only the remaining five integrations to testing. However, the best practice for project deployments is to include the five integrations as well as the ten other integrations in the project deployment.

Enjoy Improved Stability and Easier Rollbacks

If the ten integrations in testing haven't changed, why should you include them in the project deployment? The reason is stability.

If you include all fifteen integrations in the production deployment and experience any issues in the testing environment, you can roll back to the previous stable version of your product deployment.

Issues in a testing environment are expected and likely aren't going to derail your business. However, imagine the power of a project deployment in your production environment. Your business will stay on track, and you can troubleshoot and resolve any issues in your lower environments. For example, if a new or updated integration introduces any issues, you can:
  1. Perform a rollback by deactivating the faulty individual integration to avoid impacting unaffected integrations included in the project deployment.
  2. Reactive the prior stable project deployment.

Once the faulty integration is fixed, you can create and activate a new project deployment that includes the fixed version, along with all the unaffected integrations. Your business will stay on track, and you can troubleshoot and resolve any issues in your lower environments.

See Life Cycle of a Project Deployment that Requires a Rollback.

Workflow for Deploying Automation Solutions

When your automation solutions are finished, a few fast and easy steps promote the integrations, robots, and more to your testing or production environments. See Workflow for Deploying Automation Solutions.