4. Setting up Software Release Management

In Jiffy, Release Management is one of the crucial part of the software configuration management(SCM) where the process of tracking and controlling changes at the development/Tasks along with the repository is carried out. The Release management practices here include version control of the Tasks, repository data (xml, JSON, CSV, document templates) and thereby the practice of establishing baselines. In case of something going wrong, SCM can determine who changed it in the different versions of development. If a configuration is working well, SCM can determine how to replicate it across other environments (Dev, QA, Staging, Pre-production, Production).

In the following sections, we will walk you through the various ways of setting up a release management and how to move your tasks from one environment to another.

Step 1 - Pre-requisites for setting up Release Management in JiffyRPA
i. To start using JiffyRPA, we need to have a Project (for example: Project_CSS), Release (Dev_Release & QA_Release) and Environments (Dev_Environment & QA_Environment), as shown below:

Create a project

Reference: To create Project, Release and an Environment, please refer to sub-section “1. Creating a Project, Release and Environment”

ii. The Configurations required for the applications to be set up the Bot Designer. In this example, we have the Database, Email and Web UI configurations created as below:

Create a project

iii. The automated Task which needs to be exported, is configured, built and ready to be executed (For example - Task CSS_Dev_Scenario_1), as shown below:

Create a project

iv. The necessary key-value pairs created in Secure Vault (for both the Dev_Release & QA_Release, in our example) created by the Release Manager, working on this Project, as shown below:

Create a project

These Tasks should have utilized these key-value pairs in the Task, as shown below:

Create a project

v. The Tasks are required to be tagged to the environment. In our example, the Task: CSS_Dev_Scenario_1 has been tagged with the Dev_Environment, as shown below:

Create a project



Step 2 - Setting up the version control management in JiffyRPA

i. As a primary step, the Release Manager needs to create a SCM Repository in Jiffy. To achieve this, he has to go to Settings, Applications and click on +Add in the SCM Repository page. This opens up a new Add Repository window, where we need to provide a unique name, select a Repository Type, provide a base version to start the version control management with a user credential, as shown below:

Create a project

Upon clicking the Save button, you will see your new SCM Repository in the list:

Create a project

ii. Now 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 makesa change/develops in his code, JiffyRPA would upgrade the version of his Task in steps of 0.1:

Create a project

iii. 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:

Create a project

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:

Create a project

Once you click Push, you will see a pop-up on the top, as shown below:

Create a project



Step 3 - Setting up the Release Management in JiffyRPA

Once the Bot Designers have added their codes to Jiffy’s SCM Repository, as part of Release Management, the checked-in code is required in the QA Release. This is to QA Certify the code 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:

Create a project

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.

Create a project

The new Task will appear in your new Release, as shown below:

Create a project

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 apply the QA configurations for the nodes inside this Task, as shown below:

Create a project

We will then check this code into the SCM Repository, using the process explained in Step 2 section above.



Step 4 - Export and Import Tasks into Jiffy

It is vital in a Release Management to move your changes into different stages of the development lifecycle (Dev–>QA–>Staging–>Production) and move the stable code into the Production environment to create an effecient and a quality software. In Jiffy, there could arise a situation where the Dev and QA environments could be in one Jiffy machine and the staging and Production environments could be altogether in a different machine. This should, though, not hamper the movement of the stable code going from one environment to another. Jiffy provides an import and export feature where you could export, say, the example Task (CSS_Dev_Scenario_1) from QA environment to a Staging environment in another setup. We will now see how this is carried out in Jiffy.

i. Jiffy provides an Export facility at two levels. You can export either from the Task level or at the Release level. We will export our example Task from the QA_Release to Staging_Release, by performing one of the below:

Create a project

Create a project

ii. Once you click on the Export button, Jiffy will download a .zip file which consists of the Task that we are exporting.

iii. The next logical step is to import this Task into the Staging Release. To achieve this, in our example, select the Staging_Release and click on +Add Task and click on Import from File, as highlighted below:

Create a project

iv. The import wizard opens up where, by default not only do you have an option to import a Task from the .zip file that we created and saved on our system, but can additionally import the various central repository files (xml, csv, JSON,..), templates, UI Controls, any reusable components and the configurations of the imported Task. The wizard driven import Tasks makes it easy for the users to work with the import feature. The wizard driven approach is as shown below:

Create a project

Click Next

Create a project

Click Next

Create a project

Click Next

Create a project

Click Next

Create a project

Click Next

Create a project

Click Next

Create a project

Click Next

Create a project

Click on Save. This will create a new Task in the Staging_Release, as shown below:

Create a project

To see the version management of this Task, you can go to Repository–>SCM Repository from the main page, which will display the versions of the Task in the Staging Release, as shown below:

Create a project

v. Once the Task has been configured and built successfully, we can now move this to Production. The approach will be similar to what we did earlier, where we would copy this Task from the SCM Repository. The steps to achieve this are, as shown below:

Create a project

Create a project

Create a project



Step 5 - Post version control setup in Jiffy

i. You need to configure the imported Task to include the configurations set up for the Production Release

ii. Make any necessary changes in the Task to execute it - Like tagging it to the Production Environment for Execution or Scheduling the Task to execute at stipulated hour

Create a project

iii. You can check the Test Run / schedule in the Execution Summary of the Task Execution section, as shown below:

Create a project

Did you find what you were looking for?

Automation Analytics and AI in a box

Contact Us

HfS Hot Vendor

Option3's Automation capabilities featured in HfS Research's Hot Vendors List for Q3, 2018

Access your copy here