Microsoft Team Foundation Server and Kiuwan are old pals. They’ve known each other well since TFS 2013, as you can see in this post. If you are still using TFS and Visual Studio 2013 (or 2015), follow the procedure described in it. A walk in the park.
You know as well as me that software is not static, it is in continuous evolution to offer users more capabilities. This, of course, apply to Kiuwan and TFS. So it is time to see how these good’ol pals get along in their latest reincarnations TFS 2017 and Kiuwan latest release, Summer 2017.
The basics are more or less the same, TFS 2017 functionality is still the same (code repository, continuous integration, issue tracker), but the architecture is a bit different. It’s less coupled to Visual Studio, and it is more open so it can be a valid product outside the Microsoft world. Which I think is a good step forward. The biggest change is for the TFS build agents that now are supported in several platforms and can run a wider variety of build steps. Regarding Kiuwan, the integration still relies on the Kiuwan Local Analyzer, but with the Summer 2017 release, you can have an architecture analysis along with the security and code quality analysis, thanks to the new Kiuwan Architecture product.
Let’s get down to business and see how can you run automatic code analyses in your TFS 2017 builds step-by-step. I’m assuming you have your TFS 2017 server installed and running, and that you have deployed your TFS build agents in the distributed machines you may need for the continuous integration of your applications.
Automated Kiuwan analysis with TFS 2017 step-by-step
1. Install the KLA in the agent machines
Installing the KLA is pretty simple and straightforward, just take the KiuwanLocalAnalyzer.zip downloaded directly from your Kiuwan account and unzip it in a directory of your choice. That directory /KiuwanLocalAnalyzer will be your Kiuwan home (sometimes we call it agent home, to avoid confusion with the TFS agent I’ll stick to Kiuwan home). In Windows machines, the KLA installation is done just unzipping. For unix based machines there are a couple of little things to do:
- Go to your <Kiuwan home> directory and run a chmod command for all *.sh files to add execution permission (
find -name “*.sh” -exec chmod +x {} \;) - Now, go to <Kiuwan home>/bin directory and create a symbolic link named agent pointing to agent.sh (
ln -s agent.sh agent).
To be able to invoke the KLA CLI in every machine without the installation path, add the <Kiuwan home>/bin directory to the system path.
2. Select an existing project in TFS or create a new one
In TFS every project must have one or more Version Control repositories associated with it. This way the build agents take care of extracting the source code automatically. In TFS 2017 the supported repositories are Git and TFS itself.
For existing projects, most probably the repositories will be configured and the code should be already there. For new projects you can add the code to version control from Visual Studio.The repositories you configure here will be the ones that new Build definitions will use by default.
3. The next step is to configure a new build step
that will run the Kiuwan analysis in a project existing build configuration, or create a new build configuration to include the Kiuwan analysis step.
Click the build definition edit link to add new build steps.
4. In the build definition settings screen, the first thing to do is to define a couple of variables
that will be available for the build agent at execution time to hold your Kiuwan credentials necessary to run the analysis. Look for the variables section in the top Build definition submenu.
Using the add variable link, create the KiuwanUser and KiuwanPasswd variables (you can choose other names of course). Just make sure click the lock icon to the left of the password variable value to hide it and never displayed.
5. Go back to the build definition configuration, first option in the top Build definition submenu to configure a new build step.
Depending on the build definition template you selected to create your build, you will have some pre-configured build steps. In the screenshot above you have the step for a Visual Studio build. Click the Add build step… link.
From the Task catalogue, in the Utility section, select the Command Line task.
6. Now, let’s configure the command line task
to run a Kiuwan analysis using the Kiuwan Local Analyzer CLI.
Give the step a name (Run Kiuwan analysis in this case). The Tool to run will be agent (this is the KLA command). And the arguments passed to the Tool are as follows:-n $(System.TeamProject) -s $(Build.SourcesDirectory) -l "TFS build $(Build.BuildNumber)" --user $(KiuwanUser) --pass $(KiuwanPasswd)Notice that we are using System and Build predefined variables from TFS for the name of the application to analyze (it will be the project name), the directory where the source code is (it will be the checkout directory), and the label for the analysis (it will be the build number). Finally, we use the 2 variables we previously defined for the Kiuwan credentials. Using variables ensures consistency for every analysis and make them independent of the build agent machines that run them.
There are another couple of things you can configure in the step. The most relevant one is the Continue on error. Check it if you want to continue with the build even if the analysis fails (warning: that the analysis fails means that it could not run for some reason, it has nothing to do with the results of the analysis. Conditioning a build based on analysis results is a different matter that requires extra steps).
This configuration will run a Kiuwan Baseline analysis. If you want to run a delivery analysis for a change request you can define another build configuration where the analysis step will have extra parameters for the KLA agent to run a delivery analysis. Refer to the Kiuwan Local Analyzer documentation for more information on the available parameters. In this case, what makes sense is to run a Kiuwan analysis right after the Build solution step. You just have to click on the newly configured step and drag it right after the desired step.
7. The last thing is to define triggers to run the build on the project on given conditions.
The possibilities here are:
- Continuous integration (CI): Run the build when changes are checked-in in the repository (this will work when checking-in changes from Visual Studio)
- Scheduled: Run the build periodically based on a defined schedule.
- Gated Check-in
Or any combination of the 3. This is a cool feature. For testing purposes, you can always run your build clicking the Queue new build… link on the top right of the above screen.
Congrats! You are done configuring a build definition that will run an automatic Kiuwan analysis.
Run a build from Visual Studio and see the results
Now we are going to see how the build we have just configured triggers automatically after checking-in a committing changes to the project files from Visual Studio.
I have done some changes to Settings.cs file in my project and I’m ready to check it in. I add a comment in the Team Explorer panel
Once the check-in finishes in Visual Studio we go to TFS to see that our Build and analyze with Kiuwan build has been queued and it is running
By clicking the build name in the right hand side table, we can see the console output from the build agent and the progress of the different steps. In particular the step we configured to run the Kiuwan analysis.
After all the steps finished successfully we can see our build definition summary with the results of the recent builds and more historical information.
Now we just need to login to our Kiuwan account in the cloud to see the results of this build analysis. We can clearly see the analysis label corresponding to the build number that just executed successfully.
So there you go! Your applications continuously analyzed with Kiuwan using TFS 2017.
Once you know how to configure a Kiuwan analysis as part of a TFS Build definition the possibilities are endless. It all depends on how exactly you want to drive your software development process and your continuous integration pipelines.
And going beyond with the REST APIs from Kiuwan and TFS 2017 you can build custom integrations to, for example, create work items in your TFS projects from Kiuwan action plans. The sky's the limit...