dashy an automatic deployment system

some notes and comments

Because dashy is currently at an 'alpha' release, it should not be considered stable. I don't suggest using this to deploy your critical live environments yet, but I do suggest that it can be used to deploy your testing/staging/demo environments, or just for some fun personal testing. Below I will list some of the problems I know about, and comments on how to resolve any errors.

You can force an automatic deployment (you don't need to click deploy on dashy client) with a special querystring

But you shouldn't really do this for anything by your testing environment. I use this to save time, because I want every commit I do to go directly to my testing servers. But it's worth noting that this is exactly what will happen - every commit will be pushed up. The format is like so:

http://buildserver/dashyclient/ops/DoDeploy.aspx?auto=1&op=deploy&project=dashy&release=latest&instance=dashy server website

So you can see you just put the relevant names of all your project there. I just a NAnt custom task to perform this, at the end of my build scripts. It looks like this:

<script language="c#">
<references>
<include name="System.Net.dll" />
</references>

<imports>
<import namespace="System.Net" />
</imports>

<code>
<![CDATA[
[TaskName("CallURL")]
public class CallURL : Task {
    private string
        url;


    [TaskAttribute("url", Required=true)]
    public string Url { get { return url; } set { url = value; } }


    protected override void ExecuteTask ()
    {
        try {
            using(WebResponse response = WebRequest.Create(url).GetResponse()){
                response.Close();
            }
        } catch(Exception e){
            Log(Level.Info, "Call failed to url [" + url + "], Because: " + e.Message);
            throw e; // throwing it so the build fails if the auto-deploy fails
        }
    }
}
]]>
</code>
</script>

And I call it like:

<CallURL
url = "http://buildserver/dashyclient/ops/DoDeploy.aspx?auto=1&op=deploy&project=dashy&release=latest&instance=dashy server website"
/>

You can do exactly the same on the server, with the following style of query

http://webserver/dashyserver/?what=force-update&identifier=dashy - latest -dashy server website

But, you must set up authentication for the dashy server website (using IIS or another in-built system), so you will need to provide authentication credentials when calling this url.

Log files aren't deleted

At the moment, both dashy client and dashy server create log files describing the results of their actions. This ends up as a lot of files in the relevant "\data" directory. You can safely just delete any files you don't want to have anymore. The list isn't serialised into the data format anywhere; dashy simply reads that directory and looks for files in the specified format.

Make use of the 'CopyToDirTask'

Use the CopyToDirTask for all ASP.NET websites, and probably all projects in general. The reason for this, is that it means you can create files in the resulting directory, and have them not deleted, via the 'ignore' patterns. It means you can also (temporarily) modify the files, if it becomes appropriate. If you just run off the working copy that dashy will create, the hidden folders may cause problems, and you may get yourself out of sync (which will require a delete of that folder to resolve, currently).

If you get a corrupted working copy, just delete it and it will be checked out again, clean

It shouldn't happen, but if it does, this is how you solve it.

Because your SVN server needs to be accessible by your web server, it will be probably public, so make sure it is secure

On dashy client, the SVN account you provide will need to have write access (but that's okay, because it will be local only). You should configure apache (or whatever hosts your SVN server) appropriately.

With dashy server, the SVN account you provide does not need to have write access, so it will be relevant to create an account specifically for that, and restrict it like so. But do be very careful; and you may want to restrict the IP ranges that your SVN client will accept connections from.

How do I deploy locally?

Good question. Because of the naked build system, the resulting build that will be produced on your local machine by your IDE won't work, because it won't have any configurations. I am working on a solution to this; temporarily, the best way is to use the ".config.template" approach to configs, and maintain a ".config" locally, with the relevant settings for your machine. DO NOT commit this to source control.

In the future, I will put together a template for a "local" build script (in NAnt) and you will use this to perform the replacements and so on, but no matter what, you will need to duplicate the configuration of variables that you've done on dashy client. I'd be interested to here if anyone has any other thoughts on how to solve this problem :)

A beautiful side-effect

You can check out the releases to your own machine. You'll already have the /releases folder in your main folder for the project (it's at the same level as "/trunk"). So you can simply update this folder at any time, to see what dashy client is up to. It can be a really nice way to get the code that is currently deployed to the server, or view a list of recent changes to any given server! Quite wonderful, in my humble opinion :)

There are a lot of revision numbers.

Yes, that's because dashy is committing to your main repo, therefor increasing the main revision number. I'm working on making this clearer. To understand why there are so many, for every deployment dashy commits to your repo. It's important to understand repo numbers when you want to perform a rollback. My advice is that you find the number you want to rollback to by updating your own working copy of the /releases. Once you've done this, review the log for the relevant release/instance, check the revision number and then put that into the rollback prompt.

The configs are all saved in XML

So you can go onto the server and edit it yourself, if you wish, or view it. But be careful; and make a backup before you change too much. You may be interested in modifying the 'sort order' on a few items I haven't made editable view the interfaces, or just looking at how it's saved.

Pre-deploy tasks aren't executed on checkout

This is by design, because I don't think you'd actually want this. Let me know if you do though, and I'll change it (or provide an option).

You can do a lot with Post/Pre actions

Use them to run NAnt tasks, zip files up, you may even want to, in a pre task (or at least before a directory sync with CopyToDir) create a App_Offline.htm file (ASP.NET) that will serve as a place-holder while the automatic update takes place. And let me know if you do something cool! I'd love to hear about it.