Recommended Environments

The Appian Cloud standard offering includes 3 environments (Development, Test and Production), which many customers use as a starting point. Once the first application is in production, Appian recommends increasing this to a minimum of 4 environments, which allows more efficient maintenance and production deployment while maintaining development velocity in the Development and Test environments.

Common Environments

Production

This environment runs your applications with real business data, and connects to production systems for integrations.

Release Candidate

This environment allows for a "dry-run" of the deployment process, execution of smoke tests and final validation of the deployment plan. It can double-up for other purposes as well. Commonly the release candidate has the same architecture as the Production environment, has representative data similar to Production, and can be used for UAT, automated testing, and load testing.

Test

This is where all testing activities beyond unit testing occur. You may execute functional, UAT, and load testing here.

Development

A shared environment where one or more teams of Appian Designers design applications. Unit testing is performed here before features are promoted to the Test environment.

Additional Environments

Many customers benefit from having additional environments to perform the following activities. This does not mean that each of these activities needs a separate environment but their impact on the timeline may necessitate setting one up. Keep in mind that while additional environments may make certain activities easier to manage, they do represent a cost, both in acquisition and maintenance.

Please see the examples on the bottom for common configurations.

Load Testing

In order to simulate conditions similar to production systems, this environment requires an infrastructure as similar to your production environment as possible. The environment should also contain production-like data, in both volume and content, to accurately measure performance and scalability of your system. Load testing should be considered required for systems with over 100 concurrent users.

Load testing can be done in your Test environment, if its infrastructure allows it. However, keep in mind that load testing will block execution of other testing activities.

Emergency/Production/Break Fix

This environment is used for building and deploying out of cycle changes (hotfixes) to address critical issues found in the production environment. It should contain the same application versions as Production.

Hotfix changes can be made in Development or Test, but may impact ongoing development activities and/or existing changes already in those environments. If you have multiple development teams or frequent releases, a dedicated environment is highly recommended.

User Acceptance Testing

This is a stable environment for a non-designer audience, where end users can access applications without frequent updates being made to them. Users should have access to production-like data so they can validate performance and view the application as it would appear after go-live.

This activity can be done in the Test environment, but it will block other testing activities, since they can add or remove data that might confuse end-users.

Less Common Environments

These capabilities are less often given a dedicated environment. Most can be combined with another environment with minimal impact.

Training

This environment can be set up separately to accommodate for training of new designers on the Appian platform and/or end users on the built applications. This allows for separation of training from activities critical to the development lifecycle.

Emergency/Production/Break Fix Test

In a situation where you have ongoing application development and testing, issuing an emergency application hotfix can coincide with other testing activities and impact their timeline. This environment is not needed if you do not have a Fix Dev environment but can complement it in order to test the hotfixes independently of the ongoing testing activities.

Platform Upgrade

This is specifically for self-managed customers. It allows for application regression testing without impacting existing testing activities. This also allows designers to "preview" newest features and can be treated as a training environment for new system administrators.

Production Support

This environment supports reproducing issues found in Production. It is uncommon to have a separate environment for this activity. In most cases you can use your Testing or Production Fix environment to reproduce issues, unless you need the exact Production data, which would require copying Production data into this environment.

Sandbox

This is an environment where various teams can execute non-critical activities. For example, feasibility studies, demonstrations, etc. This environment does not contain any critical data or application objects and it can be recycled and recreated at any point in time.

Sample Configurations

The examples below show different arrangements of activities in different environments. This does not mean that diagrams for your organization need to fit either of these. For example, in the second table, Training activities could be done in an environment different from the Load Test.

Low Environment Count

The production environment omitted for simplicity.

Moderate Environment Count

The production environment omitted for simplicity.

High Environment Count

The production environment omitted for simplicity.