Welcome to part 2 of Tosca and CI pipelines!
|Before we start with the 2nd part, there is an important announcement. Since the introduction of Tosca version 15.2, as of June 1, 2022, Tosca CI is no longer “the default” feature for CI integration between Tosca and any CI tools. This means that Tosca CI is no longer supported from version 15.2. Tosca CI is first of all replaced by the “Tosca Execution Client”. In addition, an API is available, the so-called “Tosca Server Execution API”. Both new features work exclusively via “Distributed Execution” using AOS (Automation Object Service). Want to know more about this? I will go into more detail about this in my next blog.
Does this mean that everything has been for nothing...? Luckily not! For example, if you use Tosca version 15.0 LTS, you will receive support for 3 years after the introduction, in this specific case until December 13, 2024. LTS also stands for Long Time Service. In addition, Tricentis Support or the active Tosca community usually offers intermediate solutions or workarounds for “legacy(-becoming)” features. At the bottom of this article I have added a link for more information about releases and support.
In part 1 we linked a GitHub repository with Azure DevOps. Because as a developer you also build locally, it is useful to clone your “cloud repo” to your local PC. On GitHub you have a number of options to copy the code locally, see the green button “Code” in figure 1.
Suppose we are building a React application. Before we start with the code, let's first explain what React is. In other words, what is React? In 2011, a software engineer from Facebook came up with a way to make code of large web applications more manageable: the React or ReactJS library was born. One of the front-end frameworks/principles, the dependence on the so-called MVC architecture (a “design pattern”), was thus negated. This allowed developers to build more flexibly and freely. The advantages also lie in the accessibility of front-end development and ease of use (usability). ReactJS has since become a popular open source front-end framework worldwide, which is actively maintained on GitHub (see link at the bottom of this article).
Back to the code! If you click on the green button in GitHub, 6 cloning options will appear (figure 1). This article uses the “HTTPS” option. First of all, please note that to communicate with GitHub, you must have Git software installed on your PC/laptop. Git is a Source Control Management tool (SCM), for local version control that is ideally suited for communicating with “public” and “private” repositories (cloud or internal network). Git generally consists of a GUI version and a command prompt version, we use the last one. See the link at the bottom of this article for both.
After you install Git, the Git command prompt will look like this, see Figure 2.
In figure 2 you can also see that it is a Unix-style command prompt, also called “bash”. If you find the Windows style much better or easier, you can of course also opt for the Windows style. By the way, you don't have to start “bash” to use Git, you can also run Git commands in the Windows command prompt, as long as the environment variables are configured properly. If you look at the picture above, you will see that I have created a folder “dev” on the local C drive. The code will be cloned from GitHub to this folder. Which steps do you need to take for this? The first step is to initialize the directory where the code from the repository goes to. Initializing is done by running Git command “git init” in the command prompt. This prepares folder “dev” for communication and versioning with the GitHub repository.
The next step is to clone the code to your local PC. If we click on the green button in GitHub, you will see a copy icon at TAB “HTTPS” (figure 1). When you click this, the URL of the repository will be copied, which you can then paste into the Git command prompt, see Figure 3. To do this, add Git command “git clone”, then click ENTER, and your repository will be sub -folder “react-app” created locally.
That's it, as for the cloning part! As a developer, you can now work locally with the code. Each developer uses her/his own development environment (IDE), in my situation Visual Studio Code is used. In Visual Studio Code you can open a new (project) folder, sub-folder “react-app” of folder “dev”, and it will look like this:
Now that the development environment has been set up globally, we move to Azure DevOps. In Azure DevOps, pipelines must be prepared to perform specific development and testing tasks. To keep things simple, I've created a CI pipeline for running a simple build task, represented in a YAML file (see Figure 5).
Affected build CI pipeline is linked to the “react-app” repository, meaning every change and commit triggers a build. This build will normally become a new release if properly tested. A (software) package is then produced from this new release. For simplicity, we omit the bit about the release process (Continuous Delivery / Deployment) in this article. Now we still miss the link with Tosca. In part 1 we configured the Tosca CI client. This client is the “mediator” between Tosca Commander and Azure DevOps and vice versa.
How are we going to perform automatic Tosca tests based on a CI build from Azure DevOps? The “react-app” build pipeline from Figure 5 is going to be the trigger for a test build pipeline, which I will call “Tosca CI – Test” (see Figure 6). To prepare this pipeline I use the “Classic” view (not a YAML view), so that it is immediately clear which (build) tasks can be added.
To keep it simple, then we only add via the plus sign “+”, 2 tasks, namely “Command Line” and “Publish Test Results...”. We can give the tasks their own label/name to make the task more understandable.
Then copy the data as shown in Figure 7. This concerns the minimum data to run Tosca CI via command line. The “Tool” field displays the location of the Tosca CI client on your local PC. In specific “project” situations this will usually be a remote “server path”, but in this case we'll keep it simple. The remaining fields can simply be left at their default values. For the 2nd task, the following must be completed as a minimum, see figure 8:
Incidentally, this is an additional or optional task for the Azure DevOps dashboard, since the test results are also kept in Tosca Commander. Then save pipeline “Tosca CI – Test”.
Now we have 2 CI pipelines, which can run independently of each other, but do not yet have a direct relationship / link. Ultimately, what we want to achieve is that a developer "commits" his code, and this should trigger the “react-app” pipeline to run a build, and when this build is successful, this again triggers the “Tosca CI - Test” pipeline to run the Tosca tests. How do you set this up further? Very easy! Edit pipeline “Tosca CI - Test” with the “Edit” button (top right) and navigate to the “Triggers” TAB. If you want to add a trigger, click on “+ Add”. In figure 9 you can see that at “Build Completion”, a number of fields have been filled in, the “Triggering build” and the “Branch filters”.
Copy the above 1-to-1 and save pipeline “Tosca CI - Test” again. The “Build completion” option is one of the trigger options within Azure DevOps. With “Build completion” the previous CI pipeline is used as a trigger to start the current pipeline on a successful build. Now we have realized the link between the 2 CI pipelines!
If you have correctly performed all the previous configuration steps in part 1 , then it’s time for a “change” in the code. As a developer, let's make a simple local change to the README file, and in Visual Studio Code it would look like this:
In the project you will see an “M” and a blue icon “1” appear on the left of the screen, which means that we are now running ahead of what's on the GitHub repository in terms of version (management). An important task then arises for the developer to align the local code with the GitHub repository. How does the developer do that? One of the skills a developer possesses is being able to use Git commands. In this situation, “Git-bash” command prompt is used to run Git commands for communication between your local PC and the remote repository. If you run “Git-bash”, and then type command “git status” and finally hit ENTER, you will see the following:
On branch “master” the change is tracked locally (Figure 11). Then execute the following commands one after the other (numerical order):
- git add .
- git commit -m “README change”
- git push origin master
The above “add” command (note the last dot!) places the change in the so-called “stage”, from which a final commit can be executed. The last command is the final trigger for the CI pipelines in Azure DevOps. If all build pipelines have been successfully completed, then in Tosca’s ExecutionList folder, the “build” test results will be displayed with the default “date-time” label (see figure 12).
Now you can count yourself among a select group of DevOps guilds! Cool right? Curious about my next article (5th in the series)? A summer break for now, stay tuned and see you in September!
More information about Tosca releases/support, GitHub, Git and Visual Studio Code:
Published: 8 July 2022
Author: Otman Zemouri