11

So, a friend and I have been discussing continuous integration and bat/powershell scripts versus CI servers like CruiseControl.Net or Hudson.

The following powershell pseudo script works to update from SVN, build using msbuild, deploy/copy out, update a build/revision number in the app, and emails on failed builds. The next step would be to add calls to MSTest and email results when not successful.

  1. svn update
  2. msbuild > build_deploy_development_out_msbuild
  3. ([xml](svn info --xml)).info.entry.commit.revision + [char]13 + [char]10 + (echo %date% %time%) > build_revision_number.html
  4. $linenumber = Select-String build_deploy_development_out_msbuild -pattern "Build Failed" | Select-Object Linenumber
  5. $smtp = New-Object System.Net.Mail.SMTPClient -ArgumentList localhost | if($linenumber > 0) $smtp.Send("From:Email","To:Email", "build failed", "build failed... some one must die!")

This has lead me to the question of the value of CI servers, when you can write your own shell scripts to accomplish the same goal, using the specific tools of the project (build tool, source control, unit testing) (i.e. msbuild, nant, svn, git, nunit, mstest, etc.)

I have not experienced the maintenance cost as of yet. I wanted to get others opinions on the roll your own shell script versus a CruiseControl.Net or Hudson. Please note, I do not have experience with CI servers, thus the question, so please don't take this as being critical of CI servers; I simply don't know the best answer, and thought I would ask the community.

Best wishes! Pete Gordon

Daniel Daranas
  • 22,454
  • 9
  • 63
  • 116
petegordon
  • 339
  • 1
  • 9

5 Answers5

9

CI Servers give you several advantages:

  • Web access, usually with ability to integrate with existing authentication mechanisms (see Hudson's ActiveDirectory/LDAP support)
  • Tons of existing support for unit testing, zip archive creationg, etc.
  • Hudson (and others) supports slave build nodes, for doing distributed CI tasks.
  • No need to maintain it yourself.

Some of these may not be things you need now but are you sure they aren't things you might need in the future?

Pete
  • 11,313
  • 4
  • 43
  • 54
  • 1
    Would love to see a poll on peoples use of these types of features. I am not 100% confident I understand them all. It did make me curious about zip archiving in powershell, and I found this... http://tfl09.blogspot.com/2008/12/zip-files-with-powershell.html Thanks! – petegordon Oct 14 '09 at 10:39
  • 1
    I've used some of these features and I've built a few adhoc Hudson plugins to solve some project specific needs. The most important aspect with Hudson is that it is a growing project with an increasing number of plugins. – Jim Rush Oct 14 '09 at 12:48
  • How would you perform con-current builds with Powershell? How would you manage versioning, deployments and code coverage reporting? Why re-invent the wheel? – TheOptimusPrimus Aug 29 '13 at 18:36
3

I've installed Hudson a couple of weeks ago to replace the current CruiseControl server. The greatest advantage I see in Hudson is that pretty much anybody can use it, while launching a parametrized build with CruiseControl (or a batch file) is still scary for a lot of people.

Usually I tend to write all my build scripts with Ant (because it's portable), insert a couple of parameters and I invoke them from Hudson.

Hudson gives your scripts a great visibility (everything can be seen on the front page) and they are self explanatory. Usually with a bash script, you need to write a readme (that nobody reads) and remember where they are located.

Vladimir
  • 6,853
  • 2
  • 26
  • 25
3

... or have it both. Ayende (the creator of Rhino Mocks) has done that recently. He wrote a CI server using PowerShell. Perhaps this provides new insights for your discussion.

The Chairman
  • 7,087
  • 2
  • 36
  • 44
1

Below are my thoughts on CI Server over a Powershell scripts

  • Highly Configurable Plugins are available for all different kinds of version control, notifications and testing.
  • Logs These are maintained wonderfully. Failure and succesful build logs are at your finger tip.
  • Scheduling You can set all kinds of scheduling including triggerring based on other succesful build
  • Security You can set different groups to be able to execute, view only or set to see some projects
  • Visibility You can use a web dashboard or cctray for different audiences.
  • Scalability. Easy to scale when needed.

Bottom line if you have to maintain lots of builds for different environment and team projects then CI Server is the way to go. Other than that a simple PowerShell Script is enough for small projects. Once the project grows you can just hook up the existing PowerShell Script to a CI Server.

otaku
  • 964
  • 5
  • 16
1

For a year I've tried to maintain custom-written python scripts to do basic CI stuff: recieving notifications of commits via e-mail, checking out and building stuff, sending back blames and congrats, then when it came to publishing this for use by everyone else in my team, it turned out raaaather unusable without monitoring, web-access, etc, etc.

Then I've dived into buildbot and found it truly beautiful. I've set up basically the same process in a couple of days. Build script is a true python object, that is customizeable at the master, from where it gets transferred to slaves and executed there. Built upon twisted framework, that is lots of stuff out-of-the-box ;)

Web UI is minimalistic, though sufficient.

Well, this is unpublished too, though I'm close to it this time %)

user256849
  • 1
  • 1