Did you know that you can navigate the posts by swiping left and right?
A sophisticated continuous integration setup is a key aspect for successful and efficient team work within a project. As part of our university studies, we have built an online version of a board game. It is known in Switzerland under the name ‘Dog’, Dutch people call it ‘Keezen’ and Canadians should be familiar with it being named ‘Tock’. The Backend is coded in ASP.NET MVC, the frontend visualization is using the Phaser gaming library and the communication is done over WebSockets, in our case provided by SignalR. It took me quite a while to get it up and running, so let me guide you through the – in same corner – tricky setup.
As with every project, it started by evaluating a good platform which covers our needs to track & plan our work, manage our projects source code and continuously integrate it. We decided to go with Visual Studio Team Services – the hosted version of Microsoft Team Foundation Server – for the following reasons:
Head over to visualstudio.com and search for the paragraph ‘Visual Studio Team Services - Get Started for Free’. Next, you need to sign-in with a Microsoft account. After that, you are asked to provide a project name used to create your own subdomain. Your VSTS instance will then be available under the URL https://YOUR-PROJECT.visualstudio.com. Finally, you can create your first project. The setup is incredibly easy, so I won’t bore your with it.
Head over to Visual Studio, I assume that you have basic knowledge of it. Use the File -> New -> Project…
wizard to create a new ‘ASP.NET Web Application’. We are using the ‘MVC’ template and do not host the application in the cloud. Make sure that you check ‘Add to source control’ and ‘Create directory for solution’. You will probably get asked about whether you want to use Git or TFS as your source control system. We will be going with Git. Open the Team Explorer and setup a new connection to your above created VSTS server. The steps following should be easy as well. Finally, commit and push your locally created project to the remote branch on VSTS. You can find plenty of documentation on how to do this in the web.
We have used the Track and Plan features of VSTS. It is possible to customize the work item attributes for a specific work item type. Coming from RTC Jazz, I missed a lot of configuration possiblities and many features which I liked there, but I must admit that for a small team the features provided by VSTS were sufficient for our work.
Now let’s talk a little about the tricky part. We had to achieve the following goals for our CI process:
Simply reference the desired solution for which a NuGet package restore should executed and you are in!
The next step is to build the application. Reference the desired project file (in our case we had only one project to build), and provid the appropriate MSBuild arguments:
/p:Platform=AnyCPU;Configuration=Release;PublishDestination=Deployment /t:PublishToFileSystem
It’s important to mention that in this case the output will written to the Deployment
directory and that our build uses the PublishToFileSystem
option, which allowed as to publish the build result directly via FTP onto our development server.
I don’t have to tell you why Test Automation is important. I can only tell you that we reached a coverage of 55.5%, which is really poor… But to come back to the topic, it is important to define in which directories the test files are stored. Additionally, if you are using an external test adapter as we do for running our Jasmine tests, reference it in Path to Custom Test Adapters
The last step we did was to publish our build results for Download, like this:
The information provided in this post might not be sufficient enough for you to get started with the project, so head over to my Github profile where I published the entire source of our dog2go game.