Learn how the Designer application development workflow is managed with builds and streams.
Designer uses a stream-based workflow for developing applications. In this type of model, an application consists of multiple work streams, each of which represents a different stage in the life cycle of the application (such as the development or quality assurance stage).
At various times, you can "freeze" the current state of the application code as a build, which you can then assign to the appropriate stream. The builds are promoted through the various streams until a build is approved for use in the live production environment.
One of the primary benefits to this type of workflow is that each stream runs a build of the application that is completely independent of the others. For example, the development team can be working on a build without impacting the build being tested by the quality assurance team or the build that is actively running in production.
This page provides more details about builds and streams. You can also watch this video to see an example of a workflow in action:
You can view and manage the streams of an application from the application properties:
There are four application streams:
This stream always runs the latest published version of the application code. As such, it is also the only stream that can be affected by Designer upgrades.
QA (Quality Assurance)
This stream is for builds that require quality assurance testing.
UAT (User Acceptance Testing)
This stream is for builds that require beta-testing or some other variation of user-based trials.
This stream is for builds that are actively running in the production environment.
This is an optional stream that can run a second application build in the live production environment. For more information, see LIVE B streams.
All streams are enabled by default. You can use the Status sliders to enable or disable them, as needed.
When you want to "freeze" a version of your application code, you can create a build. A build is basically a self-contained package of the application code. It has all of the resources it needs to run, so you can assign a build to a stream without worrying about impacts to the original resources or to the other builds.
You can only create a build after the application has been published. If your application has not yet been published, the Build button remains disabled until the application has been published at least once. When generating a new build, Designer always uses the most recently published version of the application code. If you've made changes to an application that you want to capture in a new build, you must re-publish the application before generating the build.
To create a build, open the application in editing mode and click Build:
Designer automatically adds or increases the version number of the build. You must assign the build a Label and, if desired, you can also add a Note. When you are finished, click Build.
Things to keep in mind when working with builds:
- Builds are generated from the latest published version of the application code. If you've made changes to an application that you want to capture in a new build, you must re-publish the application before generating the build.
- Builds are immutable. Once generated, a build cannot be changed.
- Rollbacks are permitted. To perform a rollback, simply assign a previous build to a stream.
- Each applications has a 20-build limit. Therefore, it's recommended to only generate builds when required. If you exceed this limit, the Build button becomes disabled. You can re-enable the button by deleting builds that are no longer needed.
Parallel Test Environment (PTE)
The Parallel Test Environment enables you to use test resources instead of production ones when running an application build in a non-production stream. You can enable this option on the Misc tab in the application settings. When enabled, you can create copies of certain resources and add a special test_ prefix to the resource name.
Streams that are running non-production builds (DEV, QA, and UAT) will reference the PTE versions of the resources (test_<resource name>) instead of the ones being used in production. The LIVE build continues to reference the original production resources.
PTE is supported for Business Controls resources (Business Hours, Emergency Flags, Special Days, and Data Tables) and certain configuration resources (Virtual Queues, Agents, Agent Groups, and Skills).
LIVE B streams
You can run an optional LIVE B stream in addition to the existing LIVE stream. This allows you to run a second application in LIVE production mode, which gives you greater flexibility in how you can introduce new application builds into your production environment.
For example, each LIVE stream can have different contact points assigned to it, so one way you could use the LIVE and LIVE B streams is to allocate interactions coming from a certain region to a particular stream, or use the streams to balance (or gradually introduce) the number of interactions being handled by a new production build. In this way, you can implement a form of A/B testing.
Let's say you wanted to split or balance the number of interactions being handled between the LIVE and LIVE B builds. Typically, you would gradually introduce more interactions from LIVE to LIVE B, which could be done as follows:
- Assign Build X to the LIVE stream.
- Use the Manage button to assign phone numbers to the LIVE stream. At this point, 100% of the interaction load will be handled by Build X on the LIVE stream.
- Now, assign Build X+1 to the LIVE B stream.
- Assign some of the phone numbers to the LIVE B stream so that 70% of the interaction load is handled by LIVE and 30% by LIVE B.
- TipThe Transfer from Others button is a great way to easily and quickly move several numbers from one stream to another.
- Check Designer Analytics to see if there are any issues.
- If there are no issues, we can then move more of the phone numbers from LIVE to LIVE B, so that 30% of the interaction load is being handled by LIVE and 70% load by LIVE B.
- Again, we continue to monitor Designer Analytics to see if there are any issues.
- If everything still looks ok, we can move the remaining phone numbers from LIVE to LIVE B, so that 100% of the interaction load is being handled by LIVE B.
- Assign Build X+2 to the LIVE stream. This is a new build that we want to test in conjunction with Build X+1 on LIVE B.
- Assign some phone numbers to the LIVE stream so that 30% of the interaction load is being handled by our new application build running on LIVE and 70% by LIVE B.
- Continue to check Designer Analytics for any issues, and adjust and balance the interaction load between the two builds as desired.