Setting up my infrastructure – Part 8: A little bit more evaluation

After a little break I’m back again with the next findings in my little pet project.

First of all I wanted to check out the build servers before diving into the bug trackers. So I set up the first assembly for my project, with just one class and a unit test for it. As I already mentioned in my requirements it is a .NET project and I want to have at least the very basics (building, unit testing etc.) covered.

My test case for this was very easy:
Set up a project in the build server, have it check out the sources of the project and let it build.
After building is okay, add the configuration for unit tests and let the test run.
Check if it builds when checking in new code, and check how it reacts when either the build breaks or unit tests fail.

So, now this is, what I encountered with the systems:

Bamboo

Without digging too deep into the documentation (Documentation? Yes, this is the url. Check.), I set up a build plan in Bamboo to build my project. I set up a first stage that should check out the project from source control and build it.

Well, the setup was done quickly, but the build would not start. What I did was the following: I configured two local agents, both are capable of running the build. The build plan had a single stage “Build” with two jobs: Checkout and call msbuild with my solution file.

When I manually selected ‘Run’ it was queued and ‘waiting to be build’ forever. When clicking onto it, and selecting the only stage with the hourglass besides it from the sidebar, it told me this status: “Status: Job has not yet been queued. Waiting for prior stages to complete.”.

This was where I went like WTF? What prior stages? This was the only existing stage in the only existing plan.
After spending several hours with this situation I decided to create a User account on my Bamboo evaluation installation for someone to support me and opened a support ticket at Atlassian.

A few hours later the support logged in – and just saw a failed build that started like 20 minutes before.
After that the server behaved like normal: A new checkin resulted in an almost immediate new build like I would have expected.

So, why did the build fail? I used a Git repository on BitBucket for the tests, and configured the version control settings to check out from Git. I though that was the obvious way to do it. I was wrong, as Bamboo would not check out the sources. As I later found out, since the Git (hint! hint!) repo is hosted on BitBucket, I needed to select ‘BitBucket’ instead of Git from the repository type selection to be able to use it. My dear. After that it worked.

So, after this little problem I went on to configure the unit tests. I added a new stage for the tests to the build plan and configured a new job that would call MsTest and run the tests.

That job failed on every approach to run it. It always told me that the assembly was not found.
To make a long (several hours over a few days!) story short: Obviously the different stages in a build plan are executed on the same agent, but in different working directories.

At the time of this evaluation there wasn’t anything hinting to that in the Atlassian docs. By now, there is a small article explaining that you need to configure Artifacts to bring build results from one stage into another, but without further explaining how to set up the artifacts in detail.

Back then, I tried to figure out the different directories but that required a lot of changes to my build scripts that wouldn’t work on the dev machines after that, and so I put the MsTest job in the build stage to have it execute.

Guess what? After changing the build stage it wouldn’t start again with the same delayed until forever problem I already had until I waited several hours when it suddenly executed.

After all, my experience with Bamboo wasn’t really turning me on.

TeamCity

I already mentioned that we use TeamCity at my work place. So setting up the initial project was a bit new to me, but I knew what the settings were and where I had to tune a little bit. So the initial setup of my project with two build steps build and test was done in a few minutes.

Of course everything worked from the very instane I clicked on run.
Then I went on to activate code coverage reports for the test build step by simply activating dotCover from a little drop down in the test build step. After the next build I had a complete test coverage report on TeamCity.

Conclusion

I struggled a lot with Bamboo. It has a steep learning curve and the documentation is.. well, let’s simply call it it could be better. A lot. The Atlassian tools in general, and Bamboo is no exception, are obviously powerful, but you have to spend a LOT of time with the system to get it running like you expect it to – and I don’t want to spend too much time fiddling around with my toolset.

TeamCity on the other hand is streamlined and guides you through the process of configuring your builds. Everything I needed was set up in a matter of minutes and everything worked directly as expected from the very beginning.

Actually, at this point it was clear for me to use the JetBrains tools and not Atlassians, but I still had a quick look at Jira and YouTrack, which I want to describe in a dedicated blog post.

See the other parts in this series:

[contentblock id=infrastructurelinks]

Setting up my infrastructure – Part 4: Build server requirements

Okay, after the short delay I want to continue with my pre-thoughts for the tooling evaluation for my pet project. I already mentioned my requirements for a task and bug tracking tool to coordinate my work and keep me on track.

Now the second important thing is to stay in control of my code I’m going to produce driven by those tasks. For that I want a good suite of unit- and integration tests. The next logical step is having the tests run at every checkin, so a CI / build server is required. This also automatically opens up the possibility to automatically deploy certain parts of my project to test, staging and eventually production environments. So this is something I totally want to go for.

My personal requirements for a CI / build server:

  • Work fine with .NET environments
    I want to write something for .NET developers. As such, my pet project is a .NET project itself. I like to use the things that come in the same box as .NET (MSBuild, MSTest). Whatever tool I chose, it should support that out of its own box.
  • Work fine with Git
    Okay, that probably is a no-brainer. Git is the new SVN (just talking about adoption here, please don’t kill me for that comparison), and I assume all tools out there will have Git support in some degree.
  • Can build branches automagically
    That probably comes with ‘fine’ Git support. Whenever I create a new branch and push it to the repo the CI server builds from, this branch should build too automatically. This way I know for sure everything is working before merging stuff.
  • Easy to setup
    I actually want to work on my project and don’t spend all my spare time with getting my infrastructure up and running.
  • Integrate with my bug tracker
    As already mentioned in the previous post, a two-way integration of Ci server and task tracking would be extremely cool, but is not an absolute must-have.
  • Allow extensions with reports easily
    I think about code coverage analysis, running FxCop and or StyleCop on the Buildserver and have their reports displayed directly with the build report. Not from the very beginning, but such things should be possible.

So, that’s pretty much it for the CI / build server.

The next post will bring some light in the darker areas of the infrastructure part, like where to host my Git repositories and what additional tooling may be nice when working with the code. This will also raise some questions about hosting in general as well as setup and tooling on the server, which may affect the tools that I’m going to evaluate.

Continue with the next part, or see the other parts in this series:

[contentblock id=infrastructurelinks]