I've started working part time on a very interesting project. It's a CMS project, but it's focused around a C++ back end system that the CMS site will interact with. It's all COM-based, which means we'll be using COM interop. Fun!

Anyway, my role isn't really to build the CMS site. I'm developing the framework we'll use to build CMS templates, as well as setting up continuous integration so we get automatic builds.

Well, I got the build process done today, and there's parts that I'm happy with and parts that I'm not.

Let's get the part I'm not happy with out of the way first. Building the project is a pain. I'm currently using an exec task in nant to call devenv. I tried using the solution task (I'm using .85 rc3), and it can't build it correctly - at least not consistently. I had issues with certain obj files being given incorrect names, and therefore, the linking doesn't work correctly.  So I had to resort to shelling to devenv. It sucks because you don't get any output from devenv back into nant or CruiseControl, so you don't really get an idea of why the build is failing - just that it is.

Now for the cool part of the solution. I'm not sure how most develop with CMS, but we're doing all of our development against a local CMS database, and we migrate our changes to a dev server. Usually, that’s a process - export your changes from your local database in an sdo, and then remotely import those into the dev database, which is a remote server, and you hope you have permissions to get to it. Then, you hope the dev build is up to date, and you hope that all works when you test it out.

Here's how we've changed this process to be more automated. First, your check ins ensure that the dev build is always up to date. As far as importing the sdo file - our build server is in our DMZ, meaning you can't get to it directly from our internal network - at least not for file sharing or database connection purposes. So we decided to automate this process - you export your changes, drop them in a folder in source control, and the build process monitors that folder. It gets the sdo file, imports it into the dev database, deletes the file from source control, and then exports the full CMS structure (it's small, otherwise we would be more granular about the import/export process). That file gets checked into source control, so all developers have access to the latest sdo for the whole CMS site.

To get this set up, I used the code from Mark Duant's post about a helper he wrote that uses the CMS publishing interop API exposed by CMS. I modified it a little bit - it uses the CMS interop DLLs directly, rather than the wrapper DLL he mentions, and it goes against the server site deployment API, not the client site deployment API. It also accepts command line options to specify whether you want to import or export, as well as a file to import, or a file to export to. It's pretty rough, but it works.

Anyway, the more I get into build processes, the more things I see that you can do. Next, I'll be developing a build plan for BizTalk, which will probably include automatic deployment to a dev server. Gotta love the power of CI!