All happened so fast that I even can't say how complete was our research process.
There is still a long way ahead of us, we are tuning\changing our PowerShell scripts and maybe we will use different tools in future.
What we had:
- BuilBot (on other .Net projects);
- NuGet (our own feed. for our project);
- a lot of deployment scripts (cmd, not ps1).
What we wanted to have:
- Full Build automation;
- Deployment tool with a nice UI and only one button - "Make me happy".
What we have now:
- BuildBot (separate project; totally different master.cfg);
- NuGet (no changes here);
- Octopus Deploy (a new tool for us).
Short remarks about each of these tools:
- BuildBot
This is a true Linux way tool. You can't just set it up and start using it. You need to read some documentation first. Yes, it is doing its work and doing it good, but there is no "Make me happy" button inside. [And that is sad :( ]
I know python so I suppose, it was easier for me to start. Setting up of a Master and Slaves is not very difficult. But when you are starting to write master.cfg... you are starting to write a code. This is not what I am usually expecting from a 3rd party tool. Anyway, I wish BuildBot had a UI for configuration, it would have been much easier to configure it.
- NuGet
Nuget is a great tool and if you are using it already in Visual Studio - you know that. But since it is just a zip file, it can be much more than just a container for a library. You can pack anything you want into it.
- Octopus
This is The Tool that has The Button ("Make Me Happy"). Starting from the installation process and finishing with the deployment. Installation is easy. Configuration steps are obvious and easy as well. Deployment is a pleasure. This tool utilize NuGet, but requires PowerShell scripts inside of a nuget package (PreDeploy, Deploy, PostDeploy).
Current Workflow:
- BuildBot periodically polls SVN;
- If any project has updates, BuildBot will:
- Checkout it;
- Build it;
- Create NuGet package;
- Push the package to our local NuGet server.;
- After that, a Release could be created\deployed to any environment\server using Octopus UI.
Final impressions:
- I am happy with the Octopus Deploy as well as with the NuGet. These are a great tools.
- I am not very happy with the BuildBot... Yes, it is doing its work. Doing it nice... But can do it even better...
I hope it will do it better in future.
I use a json file to control my buildbot, that makes things much less painful; no coding is needed to add new projects.
ReplyDeleteI'm about to look at using buildbot together with nuget. Do you have example scripts? I'm going to write up a tutorial when I'm done, if I end up using this approach.
Hello Dan,
DeleteThank you for the comment, I will try to find more information about "json file" in buildbot. I was unaware about such a way of configuration.
I don't have any special scripts for nuget...
We are using regular "ShellCommand" buildbot commands to run MsBuild with particular targets.
There are 3 targets in our *.msbuild files:
#1 "compile" - compile a solution
#2 "pack" - pack all required projects into *.nuget packets
<Exec Command=""$(nugetApplication)" pack $(projectToPack) -OutputDirectory $(outputDir) -version $(calculatedProjectVersion) -Properties Configuration=$(Configuration)" />
#3 "push" - push created nuget packets to a remote server
<Exec Command=""$(nugetApplication)" push "$(outputDir)\$(packageToPush)" -s "$(nugetRemoteUrl)"" />
There were a lot of changes in our *.msbuild files and now they are a little bit complicated because we added projectVersion calculation (version looks like this - "1.0.0.$(SvnRevisionNumber)") and multiple projects support (all projects are declared inside of the element)
Sorry, I forgot to change some angle brackets in the previous comment:
Delete>...multiple projects support (all projects are declared inside of the <ItemGroup> element)...
MSBuild Items - http://msdn.microsoft.com/en-us/library/vstudio/ms171453.aspx