Category Archives: .NET

18 Continuous Integration Questions

Top .NET dog Roy Osherove just blogged some good questions about choosing a build automation or CI tool. This comes hot on the heels of his post about the difference between continuous build and continuous integration.

Here’s a few more questions:

  • If someone breaks the config, can I roll it back?
  • If not, can I secure it so that people can manage their own projects?
  • Can I use the tool to help release code as well as build/test/integrate?
  • Is there an ecosystem around the tool? (plugins, etc)
  • Can I trace artifacts of a build back to the original commit?
  • Is it platform agnostic (I won’t go back to the days of 3 ports of CruiseControl, thanks very much)

What would your questions be?

18 Questions to ask yourself when choosing continuous integration and build automation tools – ISerializable – Roy Osheroves Blog.

dbdeploy.net

dbdeploy.netAgile Database deployment for Java and .NET

(This post was originally hosted at http://www.dbdeploy.net)

DbDeploy is an implementation of the ActiveRecord Migrations pattern. DbDeploy.NET is the .NET port of DebDeploy. Both DbDeploys are projects initiated by ThoughtWorks. ActiveRecord comes to us via DHH.

Why would I use it?

When you’re developing software that hasn’t been released, the database is easy: you can tear it down and rebuild it at will. Once you have production data that people are using it, what do you do? How do you manage the change? The Migrations pattern allows you to make bite-sized changes to your database, and test it. It works very well with Continuous Integration.

What else is out there?

Payware:

Open source:

When should I use this pattern?

It’s ideal for greenfield agile projects where you are using Continuous Integration and want to make sure that changes to the database schema will be applied to integration tests. You can use other approaches if you have an ORM and you haven’t released to production yet.

When shouldn’t I use this pattern?

  • When you have a huge legacy database
  • When you’re trying to put data into a database and not schema changes
  • When you don’t use source control

The Migrations pattern is a really helpful way to manage database change; It’s not a silver bullet though. You need to have discipline and a good test regime. It works well with Continuous Integration.

Update: Gregg Jensen got in touch with a new URL for DbDeploy.Net

.NET: Who cares?

No more .NET articles on this blog, unless something really interesting happens. Most of the .NET posts are there by accident; I accidentally ended up doing nothing but .NET build and release management work.

It’s just not likely that there’s a great deal of .NET developers who:

  • care about deployment and CI matters
  • want to read blogs about deploying .NET code
  • want to read blogs about deploying .NET code written by a Unix Systems Administrator
  • actually get around to reading this one

Don’t get me wrong. I’m not bashing Microsoft. C# is a fine language, their database system seems pretty solid, and Microsoft’s build/deploy story has come a long way since the early days of .NET.

It’s just not my tribe. Java, Ruby and Unix systems are, though. So I’m writing about them.

If you do care, and want to tell me how you’re a .NET developer who misses my contributions to the .NET community, I’ll be delighted to read your comments and guest posts. Otherwise, Scott Hanselman’s blog is over here.

Photo by the author of Apache Ant


CruiseControl Build Radiator

Sudhindra Rao from ThoughtWorks has released a Build Radiator (Big Visible thing) for all the CruiseControls that support CCTray.

I installed it tonight. Needed to install the rack and activerecord gems. It would be nice to see it wrap around if you have more than a few projects. Most teams would probably do fine with this on a big display, I suspect.

This is pretty much what Michael and I did last year, except Sudhindra has made his nicely generic. Oh, and open source and available to the public. That helps a lot.

Nice work, Sudhindra.

Link


Tagged

Microsoft Web Deployment Tool

Microsoft Web Deployment Tool
(image taken from Scoble’s Photostream)

Microsoft are now offering a deployment tool to assist with the scary XCOPY-style deployments of .NET web applications. I’m old enough to have used XCOPY in DOS. It always seemed a little backwards to me: invest millions and millions in a language and platform to take on Java, and still use something that hasn’t changed since DOS to push your built apps around.

The features seem quite useful. It’ll allow you to compare both the source and target filesystems to only copy what has changed; GUI and command line I believe. It looks like it uses it’s own wire protocol to move assemblies about; no having to map drives or fiddle with UNC paths.

Props to my colleague Daniel Richardson who told me about this. I still owe him a beer.

Link

A real Build Refactoring, in the wild

A real Build Refactoring, in the wild

(image taken from A Princesses photostream)

As a build manager I have often looked on at my developer peers with a little envy. It’s a niche position, which might explain why tools seem to lag behind sometimes.. There’s plenty of editors out there that one can edit build files with; some you’d even want to use. But refactoring is something I miss. And that’s not just because I wrote an article on refactoring build files: it’s a genuinely useful technique that would make me more effective.

Anyhow, I feel a little better that there’s one authentic build refactoring available in the EAP version of ReSharper 4: Introduce variable. On Friday I did actually introduce some variables (well, properties) in a Nant build file that I was looking at. Resharper did tend to throw exceptions, but I suppressed them and it soldiered on. I had a look at the latest IDEA and Eclipse releases yesterday and could find no build refactorings. Still, it’s a start.

Unclean. (does your CI server have an IDE installed on it?)

Unclean. (does your CI server have an IDE installed on it?)

(image taken from SubFlux’s photostream)

Your build shouldn’t depend on an IDE. I’ve been saying that for a long time. It doesn’t matter that all the developers use the same IDE on your project. At least in the Java world that I have inhabited for most of the past 8 years, you absolutely should not need an IDE installed on your build server.

Yesterday I installed an IDE on the build server.

Casey Charlton and I both agree that in an ideal world, there’s no connection between the build and the IDE. I’ve been trying to find a reference to the “thou shalt not install an IDE on the damn build server” rule. I’ve found a pretty authoritative quote from Paul Duvall’s book:

You should avoid coupling your build scripts with an IDE. An IDE may be dependent on a build script, but a build script shouldn’t be dependent on your IDE. …. Creating a seperate build script is important for two reasons:

1. Each developer may be using a different IDE, and it can be difficult to to account for configuration differences in each IDE.

2. A CI server must execute an automated build without human intervention. Therefore, the same automated build script used by developers can and should be used by the CI server…

As usual, Paul is bang on. But my issue at the moment is Visual Studio. Not that I can’t write code in it (I haven’t really tried), but the fact that it’s actually more than an IDE in the traditional sense. It’s also the container for the testing framework. It’s almost the entire stack. It comes with Crystal Reports (which I’m happy to say I didn’t install), and other stacks of middleware. Which you need to build your app. Ever tried to build a VSTO app? You need Visual Studio.

In theory, you don’t need it, because the build tool for Microsoft Products (MSBuild) comes with the .NET framework. But it seems like in practice, you do.

So I installed it. And the build works, without me fiddling with the GAC. I can live with that. What works for you?