I am really excited about writing this, because its truly been a while since my last time. As I am completely new to Jenkins, Jira and Git I must apologize for the eventual lack of details on setup/installation on these systems as I am sure that many of you will have more experience than me on this. Worry not though, I promise to put in good links on instructions for how to do this.
Like the name implies, we will look at how a development environment supporting CI and TDD can be created using open source tools such as Git, Jira and Jenkins together with Visual Studio. I am personally used to working with TFS, which means having about everything I need in one place – my IDE.
By saying “almost everything” I am pointing to functionality such as viewing tasks related to myself as well as creating new and updating them, viewing current sprint status, creating custom builds as well as doing full CI cycles, checking in / out as well as merging / branching code, viewing history of code / comparing as well as having full traceability to sprint/tasks/changesets when I checkin and the best of all – no context switching, its all integrated in the IDE (Visual Studio)!
Now, I do like this approach because of several reasons
- it helps me stay focused at my work by reducing context switching
- it supports my way of developing by dispatching builds every time I checkin which in turn executes my tests, this makes some kind of assurance that checked in code is sensible
- it offers me easy overview on how the current sprint is doing
- it offers easy overview for my project manager as well as customer(s) at how the work is progressing
In this article, I am assuming that you have basic knowledge of Git, and Jira as well as using Visual Studio.
Our current environment consist of a Jira server, Windows Server Running Jenkins, Git server and of course developer machines running Visual Studio 2010 or newer.
It is important that the machine which will host Jenkins is running Windows as it will build our projects and run unit tests.
Unfortunately I haven’t installed Jira by myself as this was already up and running and in use when I started this little experiment. In case you do not have Jira already and thus have to do this yourself, you will find everything you need on the topic right here. When the installation is complete, do add a couple of users along with a test projects and some issues.
For Git installation instructions go here. After installing, make sure that you have at least one repository ready for use.
As with Jira, Jenkins was allready installed before I started researching. For those of you that need to do this by your own here is link with good documentation on that topic. Note that you will need a couple of Jenkins plugins in order to grab code from Git repositories and build .NET assemblies. These are
Visual Studio and Jira
Luckily for us Atlassian has made a plugin for Visual Studio, Visual Studio Connector, click on this link right here and follow the installation instructions.
Configuring Visual Studio Connector
Once the plugin has been installed it needs a little bit of configuration in order to work. Lets start Visual Studio and open up a solution for this purpose. When in Visual Studio go to Tools -> Toggle Atlassian Tool Window.
You will notice the connector window showing up at the bottom (this depends on your Visual Studio setup). In the connector window, click Project Configuration at the top left corner
This will display a configuration window which will enable you to at your Jira server to the current configuration.
Put in the address for your Jira server along with the correct credentials and test the connection. When the connection is stabile, hit Apply and your ready to go 🙂
You should now be able to retrieve the issues from your Jira server as well as create filters on what issues you want to look at, view the details of issues, start/stop tasks and update work. All of this without switching to a browser.
Visual Studio and Git
Using Visual Studio and Git is getting pretty common, you will find a lot of documentation for this. Our team decided to go for the more graphical approach of communicating with Git so I will give you a quick instruction of what plugins we installed to make this work. I assume that you already know the basics on Git, which means that repository cloning/creating wont be a problem once the plugins are installed.
After some research, we chose two plugins to deal with Git. The first plugin is Git extensions, and can be found here. Git extensions provide windows shell extensions to Git related files, as well as libraries, a graphical environment for communicating with Git and Git bash which is a command prompt that lets you execute Git commands. On the website provided with the link above, you will find tutorials on its use.
The second plugin, Git Source Control Provider, provides a more complete experience on using Visual Studio with Git by providing git aware context menus and other enhancements that makes using git with Visual Studio feel more seamless. This plugin can be installed from Visual Studio Gallery by clicking Tools -> Extension and Updates .. and searching for the plugin.
Let there be builds!
Allright, if you have come this far then we have the fun part left. Its time to create a build project in Jenkins that will poll our code at fixed intervals and if there has been any changes since the last poll, build the code, run all unit tests, create a nice little test report and if anything fails, send out email notification to project members.
Browse to your Jenkins instance and choose to create a New Job. Here you will be presented by many types of build jobs, but the one we are interested in is free-style software project and name it whatever you find appropriate.
Hit OK. On the next screen I will just go through the most important options which are related to ms build and our new job. If you got more than one host running Jenkins, i.e a Linux host and a Windows host, you have to tell Jenkins to restrict this build to the Windows host only. This is done by applying the Restrict where this project can run option and labeling it with the correct host label so Jenkins can do the filtering. In our case, we got a Jenkins slave named Windows which builds windows binaries, so Im gonna but my label to Windows here.
In the Source Code Management section we are gonna apply for using Git and input our repository which Jenkins will be so kind to poll our source code from along with the sln file and the msbuild definition. Under Branches to build we will specify to build everything by inputting a ** here.
Right, now we have to define some build triggers. These will be our criteria as to when to start a build. In my case, I wish Jenkins to poll my SCM every two minutes. These options will be found under the Build Triggers section. I can define it like this
Lets look at the Build section. This section lets you define custom build steps and build definitions for your current job. In my case, we have a .NET v 4 project which I must tell Jenkins to build as well as the name of the solution file I wish to build along with the configuration (Debug or Release). Your section will probably look a bit more different than mine, at least the solution file will be another one. Here is what I defined
We are almost there, what I would like to do in my builds is to run all my unit tests and generate a result file of my run that I can represent as ,a nicely, html report. I can do this by clicking at Add Build Step and choosing Execute Windows Batch Command. Here I did specify path to msbuild.exe along with a parameter pointint to the assembly containing my unit-testst, Jenkins.Test, and the target destination where I would like my test result file to be written to.
And finally to complete my job definition I want to add post-build actions, one for displaying my test result as we created earlier and the other on to send email notification to all project members if a build fails.
All of this is of course done by adding post-builds steps in the Post-Build Actions section. Here is how mine looks like
Thats it! You have done it, now its time make those builds going by either waiting for the two minute interval or executing your build explicitly.
I hope it has not been a too big frustration to set all this up. My opinion about the setup is that it works well enough, it gets the job done but its not near as smooth and easy as Visual Studio and TFS. While this is a very subjective opinion I can point out a few things that lacks in this setup, hopefully there are a lot of you out there that know more than me on this topic and thus can guide me to an even better solution.
- I really miss tagging / relating my checkins with the related issues in jira so it can be recorded by some kind of log and used later for sorting and searching
- For every new unit test assembly in my solution that I want to run and create report on, I need to explicitly add the test assembly to my Build Step. I find this hard to keep in mind and it distracts me from my real goal – to develop
- For every new solution file I wish to build I need to context switch to Jenkins to setup a job, in fact I need to switch over to Jenkins for every change I wish to make to the build system
- In order to view code history and i.e do rollbacks to a certain version of my code I need to use Git Extension toolkit or the command shell to do this, which is at times confusing and less intuitive (I realize this probably is based on my personal experience with other toolkits, but please feel free to point me into better directions)
Thats it people! Again I apologize for being very brief on the installation and configuration instructions as I did not need to do this myself.
By the way, I did find out that Microsoft is planning to offer TFS services through Azure. The service is currently out for preview/test and can be found at http://tfs.visualstudio.com. I’m very satisfied with this service since it offers me a lot of functionality neatly integrated with Visual Studio, and I believe that I will soon do a research on how I get to integrate TFS with Jira so that I can use Jira to define tasks and sprint and TFS for everything else. Stay tuned.