This guide will show you how to integrate Kiuwan into Team Foundation Server 2017.
Contents:
1. Install the KLA in the agent machines
See how to install KLA here: Install and Start Up Kiuwan Local Analyzer
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 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. Configure a new build step
The new build step will run the Kiuwan analysis in a project's existing build configuration. It is possible to also create a new build configuration to include the Kiuwan analysis step.
Click the build definition edit link to add new build steps.
4. Define variables
In the Build Definitions settings screen, 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.
Click Add variable to create KiuwanUser and KiuwanPasswd variables (you can choose other names of course).
Click the lock icon to the left of the password variable value to hide it!
5. Configure a new build step
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...