Do you know Tricentis Tosca... can work with CI pipelines? (part 1)

Most of us are familiar with CI/CD. CI stands for “Continuous Integration” and CD stands for “Continuous Deployment” or “Continuous Delivery”. Many IT companies use CI/CD as a building block for (a) development (team) to speed up product development. Despite being a relatively established concept in “IT”, CI/CD is by no means always well understood and, moreover, implemented in various ways. In this article, the focus is on CI, and “CD” is not considered for further explanation. In a nutshell, “CI” is an automated software development process that aggregates, integrates, and tests all changes as soon as they are committed.

First of all, let's go back in time. To the year 1989 to be exact. The year of the fall of the Berlin wall, but also the year in which the PTT was privatized (now KPN and PostNL). Furthermore, that year, at an IT conference in Orlando, the term “Continuous Integration” was used for the first time. This as a result of a study on "integration test management", see the site of IEEE.org. With eXtreme Programming (XP), CI (under the term “Continuous Process”) came into focus more clearly as a way to further organize software development more efficiently. A legacy system at that time such as TFS (Team Foundation Server) is known to the "old-timers" among us, as one of the first modern SCM (Source Code Management) tools for managing and organizing software. The all-encompassing process of “Branching” was not yet commonplace at the time.

With that in mind, I start with an example from practice. As a developer you want to make a copy of the source code from an internal network “storage” to your local PC. You usually do this by using a so-called “Version Control System” (VCS) repository to check out a specific version. All source code of a project is kept in this repository. Furthermore, to make it clearer for all colleagues, the current state or version of a project is called “Master” or “Main”. From your “working copy” you perform your tasks, such as modifying the code, refactoring your functions or automating your (unit) tests. Once done, run an “automated build” on your local PC: your working copy source code is compiled and then automated (unit) tests are run. If error-free and (peer) reviewed, this is checked in or commited in the “Master” branch.

A potential problem that can arise here is of course that colleagues can make interim changes to the “Master”. The "working copy" must then be updated on the basis of interim changes and finally rebuilt again. If intermediate changes collide with your changes (so-called conflicts), then when recompiling or testing this will produce a large number of errors. In that case, it is your responsibility as a developer to solve this: repeat updates and checks as necessary until your "working copy" is properly synchronized with the "Master" (build). This is unfortunately an error-prone and intensive development process! Fortunately, we have modern CI tools for that... By the way, a "commit" doesn't finish your work. There is also such a thing as an “integration build”, but I won't go into that in detail.

In the third series of "Do you know Tosca..." I'm going to take a closer look at a specific CI tool. Let's start with 3 popular tools within the “DevOps” world. Let's say you use GitHub as a “cloud repo”, Azure DevOps as a CI tool and Tosca to automate your tests. To make things more practical, use your local PC as an agent for running so-called “jobs”. So how do you implement the whole thing as a CI pipeline? That's a very good question!

For those who are not yet familiar with the terms "cloud repo", VCS and/or GIT, it is useful to google "git" for example. In addition, it is practical to register with one of the well-known “cloud-based git repo hosting” providers, in our case this is GitHub (see link/URL at the bottom of the page). It is a free “cloud service”, and you are not tied to any obligations. After registering your free account with GitHub, your next step is to register with Azure DevOps (see link/URL at the bottom of this blog). According to Google, Azure DevOps is a (cloud) server for version control, automated builds and testing, and also for release management. We focus on builds and testing. The registration process via “Azure” is very simple and you will soon arrive at your personal dashboard (see Figure 1).

To be able to perform your “CI jobs” you need a “CI agent”. So your next step is to download and install the agent on your local machine, which is a zip file of about 150 MB. This is done via “Organization Settings” and “Agent pools”. Then create a suitable directory for this “Azure agent”, in my case this location is “C:\agent”. Then start Powershell and run the command shown in Figure 2. Figure 3 shows the final situation after installation.

After that, the intention is to let your local “Azure agent” communicate with the Azure DevOps server. You can do this by starting the batch file “config.cmd” first (see also Figure 3). In the interactive screen that appears afterwards, you will be asked for your token (for more info, see link/URL at the bottom of this blog). If the configuration process has been successful, the agent will appear on the “Default” overview of the Agent pools (see Figure 4).

Then start your batch file “run.cmd” to start the agent (status “online”). If you now have a GitHub account and have created a GitHub repository (see link/URL at the bottom), it's time to link this to your Azure DevOps account. This is again done via the “Project settings”, where you have to select the option “GitHub connections”. If you have successfully completed all steps, your GitHub repo will become visible in Azure DevOps (see Figure 5).

So far we haven't done anything with Tosca Commander yet. So now it's time for Tosca! In the installation folder of Tosca there is a folder “ToscaCI” (see Figure 6). What are we going to do with that?

In sub-folder “Client” is the ToscaCI client (an executable) that acts as a trigger to run the Tosca tests without the need for “user” interaction. In addition, ToscaCI can communicate with external CI tools, in our case Azure DevOps. To let ToscaCI talk to your Tosca workspace, you need to open “ToscaCIClient.exe.config”, an xml file, and specify the location of your Tosca workspace (see Figure 7).

If the above is configured, then you need to add 2 “Test Configuration Parameters” (TCP) in Tosca Commander. In the “Execution” folder of your workspace, at the “ExecutionLists” level and at the “ExecutionList” level, add TCP “ContinuousIntegrationBuildRootFolder” and TCP “ContinuousIntegration” respectively, see Figure 8.

Both TCP “Values” must be set to “True”. Once the parameters are set, exit your Tosca workspace and exit Tosca Commander as well. What is the next step? That will be a surprise! By the way, your first part for implementing a Tosca CI pipeline is a success! Nice, isn’t it? Are you curious about part 2?

In my next article (4th in this series) I will go further into the “how-to’s” of the “CI pipeline in action”: from a “commit” in GitHub to running the tests following this commit.

For more information about Tosca CI, Azure DevOps, and/or GitHub, see the references:

• Azure DevOps registration on Microsoft website
• Azure DevOps personal access token(s) on Microsoft website
• GitHub registration on Github website
• GitHub Repository on Github website
• Tosca CI on Tricentis website