Technical Troubleshooting Guide
Dev to QA Migration
Now as and when a Bot Designer would work on his automated Task, naturally this Task would undergo many changes and thereby have a default version associated with his Task. For example, in our example, you can see below the Task TK000319 has a current version v0.5. Everytime he makes a change/develops in his code, JiffyRPA would upgrade the version of his Task in steps of 0.1:
Now a Bot Designer would start working on this automated Task, thereby making changes to the Task. To make this Task work, he would have to perform two configurations which are as described below:
i. Configuration: Is the process where you configure the application/technology settings at a Release level, with their dependent parameters, for Jiffy to work with. To configure, you need to go to Task Design and select Configurations. This will open up the Configurations page, where we need to configure the DB (as an example) used, by clicking on the +Add icon. Here you have two options to either add a new configuration or copy an exisiting DB configuration available in Jiffy, which is as shown below:
On selecting the Copy Existing icon, the below window will pop-up where you need to mention the exisitng configuration that you want to use in your exisiting release. Once you choose the existing configuration by clicking the radio button and then clicking on Copy icon, which will take you to the Add Database Configuration page where you need to provide a DB configuration name, with the URL of the DB, the driver class of the DB along with the DB user credentials, which is as shown below. Once provided, click on Save button.
Similarly we configure the Web UI node using the above similar process, which would look like this:
One thing to note during the Web UI configuration would be the configuration of the cluster, required to execute these web nodes. You will have to provide an appropriate cluster name which is available for execution. To understand more on this subject, please refer to section Setting up the Automation Environment --> 5. Setting up the Bot.
In the Task that we create, we will enable the DB node to use this newly created Configuration. In this example, for the DB node in the Task, we will use the "CSS_Dev_Release" configuration.
Similarly appropriate web UI configuration will be used for the web node.
ii. Security Vault - We will now proceed to configure the key value-pairs that would be required to be set up in the Task that you create for this Dev environment. To do this, go to Security Vault. You will be able to see some exisiting key-value pairs, as shown below:
In our example, we need to create two Key-value pairs, for the Origin and destination codes. To do this, once on Security Vault page, we will have click on + Add Secure Data icon, which will open a new Add Secure Data window, where we will have to provide a name, with a valule/passcode for this key and a description. Click on Save, once finished. This is as shown below:
Now you will see the new key-value pair added into your existing list, as shown:
Using the above similar process, we will create the second key-value pair Destination_Code. Thus the list is as shown below:
To embed this secure data /code into our Task, we will now proceed to the Task and at the appropriate step of the Web UI Node, will select S
Similar process is followed for the Destination_Code.
Your Task will now look, as shown below:
Once a Bot Engineer develops his Task and makes changes to the Task, he can now move his Task into Jiffy's SCM Repository, which is described in the next section.
Now a Bot Designer would start working on this automated Task, thereby making changes to the Task. To make this Task work, he would have to perform two configurations which are as described below:
i. Configuration: Is the process where you configure the application/technology settings at a Release level, with their dependent parameters, for Jiffy to work with. To configure, you need to go to Task Design and select Configurations. This will open up the Configurations page, where we need to configure the DB (as an example) used, by clicking on the +Add icon. Here you have two options to either add a new configuration or copy an exisiting DB configuration available in Jiffy, which is as shown below:
On selecting the Copy Existing icon, the below window will pop-up where you need to mention the exisitng configuration that you want to use in your exisiting release. Once you choose the existing configuration by clicking the radio button and then clicking on Copy icon, which will take you to the Add Database Configuration page where you need to provide a DB configuration name, with the URL of the DB, the driver class of the DB along with the DB user credentials, which is as shown below. Once provided, click on Save button.
Similarly we configure the Web UI node using the above similar process, which would look like this:
One thing to note during the Web UI configuration would be the configuration of the cluster, required to execute these web nodes. You will have to provide an appropriate cluster name which is available for execution. To understand more on this subject, please refer to section Setting up the Automation Environment --> 5. Setting up the Bot.
In the Task that we create, we will enable the DB node to use this newly created Configuration. In this example, for the DB node in the Task, we will use the "CSS_Dev_Release" configuration.
Similarly appropriate web UI configuration will be used for the web node.
ii. Security Vault - We will now proceed to configure the key value-pairs that would be required to be set up in the Task that you create for this Dev environment. To do this, go to Security Vault. You will be able to see some exisiting key-value pairs, as shown below:
In our example, we need to create two Key-value pairs, for the Origin and destination codes. To do this, once on Security Vault page, we will have click on + Add Secure Data icon, which will open a new Add Secure Data window, where we will have to provide a name, with a valule/passcode for this key and a description. Click on Save, once finished. This is as shown below:
Now you will see the new key-value pair added into your existing list, as shown:
Using the above similar process, we will create the second key-value pair Destination_Code. Thus the list is as shown below:
To embed this secure data /code into our Task, we will now proceed to the Task and at the appropriate step of the Web UI Node, will select S
Similar process is followed for the Destination_Code.
Your Task will now look, as shown below:
Once a Bot Engineer develops his Task and makes changes to the Task, he can now move his Task into Jiffy's SCM Repository, which is described in the next section.
Now a Bot Designer would want to check-in his code on the newly created SCM Repository for a Build activity. To do his, he has to check-in his code into the newly created SCM Repository. To achieve this, he needs to go to his Overview tab and click on the Checkin To Repository button, which is as highlighted below:
Upon clicking, a new Comments window will pop up, where he needs to provide information on the edits that he has made on the specific Task that he is trying to check-in. This is an important and best practice where in the changes you push into the SCM Repository is captured/logged and does not impact the overall build. This is as shown below:
Once you click Push, you will see a pop-up on the top, as shown below:
Thus the Task will be checked into the SCM Repository and carry the same version, as highlighted below. Any changes made from here, will increment the version by 0.1.
This process will thereby create a branch associated with a release in Jiffy's SCM Repository, which will show the versions of the changes that this Task has undergone, as shown below:
Upon clicking, a new Comments window will pop up, where he needs to provide information on the edits that he has made on the specific Task that he is trying to check-in. This is an important and best practice where in the changes you push into the SCM Repository is captured/logged and does not impact the overall build. This is as shown below:
Once you click Push, you will see a pop-up on the top, as shown below:
Thus the Task will be checked into the SCM Repository and carry the same version, as highlighted below. Any changes made from here, will increment the version by 0.1.
This process will thereby create a branch associated with a release in Jiffy's SCM Repository, which will show the versions of the changes that this Task has undergone, as shown below:
Once the Bot Designers have added their Tasks to Jiffy’s SCM Repository, as part of Release Management, the checked-in Task is required in the QA Release. This is to QA Certify the Task developed in the Dev Release. To achieve this, the Tasks created in Dev Release needs to be imported/pulled-in to QA Release. To do this, you need to go Task Design–> Task Plan, select QA_Release and click on +Add Task and choose Add from SCM Repo, as shown below:
Once you click, you will see a new Add Task from SCM Repository window, from which you need to choose the Tasks that you want to import into QA Release. Once selected, click on Add to Release button to move your selected Task into another Release.
The new Task will appear in your new Release, as shown below:
Thus the Task will be checked into the SCM Repository and carry the same version, as highlighted below. Any changes made from here, will increment the version by 0.1.Kindly note that the start version of the new added Task is v0.1. The versioning will start from v0.1 and any changes you will make, will increase your versioning by 0.1.
To successfully execute this newly added Task in the QA Release, the Bot Designer/Release Manager needs to create
i. A new configurations for the QA_Environment (this is shown below) - He has the option of creating a new configurationor copy the existing configurations and make QA changes accordingly
ii. A new Security vault key-value pairs
iii. Machine cluster for execution in QA environment
He has to apply the above QA configurations for the nodes inside this Task, as shown below:
Once the Release Manager performs the necessary configuration changes, he will create a QA Environment for the execution of the new Task. To do this, proceed to Task Design-->Task Plan, select the project name (CSS), and then the release name QA Release and click on the + icon, as highlighted below:
This will open a new Add Environment window, where you provide the QA environment name and check the Is Active option and then click on Save as shown below:
Thus a new environment will be added to this QA Release. We will now tag the Task, that we imported and configured, into this QA Environment. To do this, go to Task Design --> Tasks, select the Overview Tab and click on Tag to Environment icon on the right handside, as highlighted below:
This will open a new Tag to window, where you need to choose the environment to which this Task has to be tagged and click on Update icon, as shown below:
Now you can see that this Task is now tagged to QA_Release, as shown below:
Once the QA_Environment has been set-up, the Release manager will schedule the Task to be executed, for which he would proceed to Task Execution-->Run Tasks, select the Project, Release and the Environment. This will show the list of Tasks available in this environment. Now he needs to select the Task and has the option of either Running it immediately or Schedule the Task to be executed, which is as shown below:
The Schedule screen requires the users to provide the Start Date and Start Time to schedule the execution, as shown below:
The execution result can be seen from Task Execution : Execution History, as shown below:
Thus a Release Manager has successfully imported a Task from a Dev environment to a QA Environment, configured the Task and scheduled the Task to be executed.
Once you click, you will see a new Add Task from SCM Repository window, from which you need to choose the Tasks that you want to import into QA Release. Once selected, click on Add to Release button to move your selected Task into another Release.
The new Task will appear in your new Release, as shown below:
Thus the Task will be checked into the SCM Repository and carry the same version, as highlighted below. Any changes made from here, will increment the version by 0.1.Kindly note that the start version of the new added Task is v0.1. The versioning will start from v0.1 and any changes you will make, will increase your versioning by 0.1.
To successfully execute this newly added Task in the QA Release, the Bot Designer/Release Manager needs to create
i. A new configurations for the QA_Environment (this is shown below) - He has the option of creating a new configurationor copy the existing configurations and make QA changes accordingly
ii. A new Security vault key-value pairs
iii. Machine cluster for execution in QA environment
He has to apply the above QA configurations for the nodes inside this Task, as shown below:
Once the Release Manager performs the necessary configuration changes, he will create a QA Environment for the execution of the new Task. To do this, proceed to Task Design-->Task Plan, select the project name (CSS), and then the release name QA Release and click on the + icon, as highlighted below:
This will open a new Add Environment window, where you provide the QA environment name and check the Is Active option and then click on Save as shown below:
Thus a new environment will be added to this QA Release. We will now tag the Task, that we imported and configured, into this QA Environment. To do this, go to Task Design --> Tasks, select the Overview Tab and click on Tag to Environment icon on the right handside, as highlighted below:
This will open a new Tag to window, where you need to choose the environment to which this Task has to be tagged and click on Update icon, as shown below:
Now you can see that this Task is now tagged to QA_Release, as shown below:
Once the QA_Environment has been set-up, the Release manager will schedule the Task to be executed, for which he would proceed to Task Execution-->Run Tasks, select the Project, Release and the Environment. This will show the list of Tasks available in this environment. Now he needs to select the Task and has the option of either Running it immediately or Schedule the Task to be executed, which is as shown below:
The Schedule screen requires the users to provide the Start Date and Start Time to schedule the execution, as shown below:
The execution result can be seen from Task Execution : Execution History, as shown below:
Thus a Release Manager has successfully imported a Task from a Dev environment to a QA Environment, configured the Task and scheduled the Task to be executed.