This page describes the builds and streams workflow that Designer uses 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 video shows an example of a workflow in action:
You can view and manage the streams of an application from the application properties:
All streams are enabled by default. You can use the Status sliders to enable or disable them, as needed.
This stream is the only one that can run the latest published version of the application code. As such, it is also the only stream impacted 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.
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 create a build by clicking Build when the application is open in editing mode. Designer automatically increases the version number of the build, but you can add your own label and note:
You can manage the builds for an application by clicking Manage Builds from the application properties.
- Once generated, a build cannot be changed. If you want to make changes, you must generate a new build. You can also choose to perform a rollback by selecting a previous build.
- There is a limit of 20 builds for each application. Therefore, it's recommended that you generate a build only when required. If you exceed 20 builds, 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.