This is a series on my findings around building open source software online for free. There are many SAAS (Software As A Service) platforms out there and a lot of these are free to use with your open source projects. But not all of these work with C# and .Net. So this series highlights the tools and products out there that work with .Net in different phases of the software development life cycle.
So not we have our source control sorted (and if you don’t check back on part 1) We can start writing code. And once we have some code together we need a way to build it. If your a Visual Studio developer like me, you might think ‘I have foo.csproj, and it builds just fine!’. Well that’s great, if your wanting to depend on a visual studio GUI. But if you want to reach Continuous * Nirvana, you need a build server, and it needs to run autonomously. As well as needing this build server, we probably want scripts to automate our build process. And over time we can add to these scripts with other steps, like running tests, packaging deployables, and running static analysis.
I will quickly run through a few build script options I’ve used, and although not definitive, are plenty powerful to get the job done. These are:
- Node.js (Grunt/gulp)
And as far as builder servers go, (skipping over the self-hosted servers like TeamCity and Jenkins Build Servers), there are some great Build Server as a Service (BSAAS) options that you can use to host your public open source repositories.
- Atlassian Bamboo
Unless you’ve been blinding using Visual Studio like magic, you will be aware that this is the way *.csproj files get turned into dlls and assemblies. And all of this can be done on command line as well, either with devenv.exe, or with the MSBuild tool itself. A good baseline in absence of anything else.
the simple cmd.exe command shell is the most basic place to start stringing simple commands one after the other. If all you need is to run devenv.exe or MSBuild.exe with the ‘build my solution’ command, followed by a call to something else to ‘run my tests’, then maybe you can get away with something as simple as a .bat file. If your more into mono, then the shell capabilities of Linux and probably all too familiar. You can even get some powerful behaviour out of batch scripting if you want to go down that road.
psake (+ PowerShell)
I used psake about 3 years ago with a project and it did seem quite heavy handed. It was also already established when I got there. After being if TFS build script land for a while I came back to try psake again on my own projects and when starting from scratch I finally see the power and simplicity this has. Not only is is just PowerShell, so I can run any arbitrary command line, PowerShell or .net code I need, but its also a simple yet powerful task orchestration system. I think I’m going to be more than happy having all my projects using this as their build system.
FAKE follows the tradition of other *ake build tools (make, cmake, rake etc) but uses the F# language to do it. If you have ever wanted to learn F#, or are already using it, this is a nice choice to write your build scripts in. There are plenty of projects using this, and since its all just IL, people are using it with their mono builds too. I haven’t used this myself but it does seem like a nice way to write your build scripts.
And on to the build servers.
Ever since Scott Hanselman did this great write-up on AppVeyor I’ve started using it with my open source projects. For .Net developers, AppVeyor is the simplest, most powerful Build Server experience I’ve seen for a C# project, that just works out of the box. On top of that, you can configure it to do just about anything with extra scripting, on top of the configuration extensions they already have available to configure in their settings GUI. This is my go-to Solution for my CI, and I can’t see myself being easily swayed towards anything else in the short term.
Travis-CI only just opened up beta support for .Net back in December 2014 (less than 3 months ago at the time of this writing) and already they have support to build and test Xamarin, portable class libraries and anything that will run against the mono runtime. This is a great way to ensure your open source library will actually build and run on mono and that your not doing anything that will break for your mono users, without knowing about it. I even have my integration tests running against one of my projects on .Net and mono with AppVeyor, and again with mono on Travis-CI on every commit, which really neat to see.
Atlassian, not to be left out from a ALM opportunity, have a build server called Bamboo. In fact keep an eye out in almost every most I think I’ll be finding an Atlassian product to call out. They seem to be right behind open source and it is great to see. Although I use their products at work, I haven’t really had the chance to use Bamboo with any projects, so If your interested you will have to follow this one on your own. But I would be keen to hear back from anyone who has used it on how they found it.
Just when you thought you couldn’t keep using your beloved TeamCity, the team at CodeBetter have collaborated with JetBrains on this hosted version, TeamCity.CodeBetter.com and its free for open source projects to register and get their CI running here. Personally it is a few hoops to just through, and AppVeyor is much simpler so I don’t think I will make the leap. But its an open available if you want it.
So there it is
I’m sure there are more out there (I know there are but the others I found don’t support .Net), and would love to hear about them if you find them.
In conclusion, I find AppVeyor is the one I’ll keep using, because its got a great range of features, and I’ve managed to see and make change on what comes in the build VM when it boots, which is awesome. For mono I will keep using Travis-CI and see how it goes, and hopefully help them extend their support for C# along the way too.
Now the have source control, and a place for continuous integration, next up is testing!
I totally forgot to mention one other awesome tool for CI builds - GitVersion! This awesome library (available as a Chocolatey Package) determines the ideal version number for your current build, and gives you various permutations so you can use it exactly how you want to inside your build scripts. It integrates with various build servers, and (mostly) just works. There is plenty of guidance on their wiki on github, and they support Git Flow and GitHub Flow branching strategies. Recommended.