Latest revision as of 12:32, October 2, 2020

Application Workflow

Important

This content may not be the latest Genesys Engage cloud content. To find the latest content, go to Genesys Engage cloud for Administrators.

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:

Application streams

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.

DEV (Development)

Use this stream to test the latest changes to your applications. You can then generate a build that can be promoted to QA, UAT (as applicable), and then to a LIVE stream. The DEV 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.

Warning

The DEV stream is intended for development testing purposes only and does not support live production traffic. Live production traffic must always be assigned to the LIVE or LIVE B streams.

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.

LIVE

This stream is for builds that are actively running in the production environment.

LIVE B

This is an optional stream that can run a second application build in the live production environment. For more information, see LIVE B streams.

Application builds

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.

Important

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.

For example, if you create a business object resource to use in the LIVE Production stream (example: Hours), you would also create a similar business resource object with the test_ prefix for use in the non-Production streams (example: test_Hours).

Then, you can reference the resource in your application as you would normally, using the original name (using the above example, you would just reference the Hours resource). Streams that are running non-production builds (DEV, QA, and UAT) will automatically 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.

Important

When making changes directly to the test_<data table>, you do not need to add the test_ prefix to the resource names, as Designer adds this prefix automatically when PTE is enabled.

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.
Tip
The 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.

@@ Line 1: / Line 1: @@
 =Application Workflow=
-Designer uses a stream-based workflow for developing applications. In this type of model, an application consists of multiple work [[AppStruc#appStreams|streams]], each of which represents a different stage in the life cycle of the application (such as the development or quality assurance stage).
+__NOINDEX__
+{{Template:PEC_Migrated}}
+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 [[AppStruc#appStreams|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 [[AppStruc#appBuilds|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.
@@ Line 6: / Line 10: @@
 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:
+This video shows an example of a workflow in action:
 {{#widget:Vimeo|id=305589601|height=405|width=720}}
@@ Line 14: / Line 18: @@
 You can view and manage the streams of an application from the [[ApplicationsBar#appprops|application properties]]:
-[[File:des_app_properties_streams_example.png]]
+[[File:des_app_properties_streams_example_02.png]]
-There are four application streams:
+All streams are enabled by default. You can use the '''Status''' sliders to [[ApplicationsBar#stream_status|enable or disable them]], as needed.
-* '''DEV (Development)''' — 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.
-* '''LIVE''' — This stream is for builds that are actively running in the production environment.
-All streams are enabled by default. You can use the '''Status''' sliders to [[ApplicationsBar#stream_status|enable or disable them]], as needed.
+====DEV (Development)====
+Use this stream to test the latest changes to your applications. You can then generate a build that can be promoted to '''QA''', '''UAT''' (as applicable), and then to a '''LIVE''' stream. The DEV 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.
+{{NoteFormat|The '''DEV''' stream is intended for development testing purposes only and does not support live production traffic. Live production traffic must always be assigned to the '''LIVE''' or '''LIVE B''' streams.|3}}
+====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.
+====LIVE====
+This stream is for builds that are actively running in the production environment.
+====LIVE B====
+This is an optional stream that can run a second application build in the live production environment. For more information, see [[AppStruc#liveb|LIVE B streams]].
 {{AnchorDiv|appBuilds}}
@@ Line 41: / Line 51: @@
 {{AnchorDiv|pte}}
 ==Parallel Test Environment (PTE)==
-The Parallel Test Environment is an [[ApplicationsBar#pte|option you can enable]] 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.
+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 [[ApplicationsBar#pte|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.
+For example, if you create a business object resource to use in the LIVE Production stream (example: '''Hours'''), you would also create a similar business resource object with the ''test_'' prefix for use in the non-Production streams (example: '''test_Hours''').
-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.
+Then, you can reference the resource in your application as you would normally, using the original name (using the above example, you would just reference the '''Hours''' resource). Streams that are running non-production builds (DEV, QA, and UAT) will automatically 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.
-{{NoteFormat|If you've enabled PTE and the test version of a resource can't be found, Designer displays an error.}}
+{{NoteFormat|When making changes directly to the '''test_''&lt;data table&gt;''''', you do not need to add the '''test_''' prefix to the resource names, as Designer adds this prefix automatically when PTE is enabled.}}
-PTE is supported for Business Controls resources ('''Business Hours''', '''Emergency Flags''', '''Special Days''', and '''Data Tables''') and certain configuration resources ('''Virtual Queues''', '''Agent Groups''', and '''Skills''').
+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''').
+<!--
 ===Using PTE and production resources in the same application===
 You can also mix and match PTE resources with production resources.
@@ Line 58: / Line 71: @@
 In this case, the DEV, QA, and UAT streams will automatically select '''test_Joules Coulomb Data Table''' and the LIVE stream will use the original '''Joules Coulomb Data Table'''.
-If you wanted all streams to use the same business controls resource, you can specify the business controls resource using a variable containing the resource ID:
+If you wanted all streams to use the same business controls resource, you can specify the resource using a variable that contains the resource ID:
 [[File:des_pte_select_data_table_var.png]]
-{{NoteFormat|You can find the ID of a resource by selecting it and referencing the URL. For example, if we browse to the Joules Coulomb Data Table, the URL appears as follows (resource ID is highlighted):
+{{NoteFormat|You can find the ID of a resource by selecting it and then referencing the URL in the browser. For example, if we browse to the Joules Coulomb Data Table, the URL appears as follows in the browser (resource ID is highlighted):
 [[File:des_pte_select_resource_id.png]]
   |2}}
+-->
+{{AnchorDiv|liveb}}
+== 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.
+*: {{NoteFormat|The [[ApplicationsBar#Transfer_from_Others|Transfer from Others]] button is a great way to easily and quickly move several numbers from one stream to another.|2}}
+* 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.
 [[Category:V:PSAAS:Public]]

Latest revision as of 12:32, October 2, 2020

Contents

Application Workflow

Application streams

DEV (Development)

QA (Quality Assurance)

UAT (User Acceptance Testing)

LIVE

LIVE B

Application builds

Parallel Test Environment (PTE)

LIVE B streams

Contact

Genesys

Customer Care

Legal