dashy an automatic deployment system

complete guide for dashy installation

First, look at and enjoy this image:

Figure 1. Beautiful sunny balcony, where you will soon be able to relax.

Because soon you will be able to relax there, while enjoying the beautiful automatic deployment system that you have set up for yourself :) Okay, on to serious matters.

1. Download 'dashy client' and 'dashy server'

Get them from the download link here.

2. Pre-requisites

Both dashy server and dashy client communicate with their respective services using Microsoft Message Queues. This is available on all Windows machines, but will need to be explicitly installed. See here for how to install it.

3. The dashy client install

As discussed in how does it work dashy client is installed on your build server. In these instructions I will refer to my CI server, CruiseControl.NET, but any build server should work. Extract the files into a path like c:\program files\dashy\client so you will have a folder called web, data and one called service and then set up the web\web.config and service\dashy.service.exe.config like:

in web\web.config

<appSettings>
<add key  = "BinarySavePath"
value = "c:\program files\dashy\data\data.v3.bin" />

<add key  = "FilePath"
value = "c:\program files\dashy\data\" />

<add key  = "MaxWaitTime"
value = "1800000" />

<add key   = "managementchannel.in.queuename"
value = ".\Private$\dashy_managementchannelqueue_in" />

<add key   = "managementchannel.out.queuename"
value = ".\Private$\dashy_managementchannelqueue_out" />
</appSettings>

in service\dashy.service.exe.config

<appSettings>
<add key   = "FilePath"
value = "c:\program files\dashy\data\" />

<add key   = "managementchannel.in.queuename"
value = ".\Private$\dashy_managementchannelqueue_in" />

<add key   = "managementchannel.out.queuename"
value = ".\Private$\dashy_managementchannelqueue_out" />
</appSettings>

With that done, you can double-click install.bat in the "service" folder, and type net start dashyworker at the console to start the service.

You will now want to configure a virtual directory in IIS to point to the dashy client website: c:\program files\dashy\web.

4. Setup projects

When you navigate to your dashy client website (I'm going to assume it's configured at: http://buildserver/dashyclient) you will be presented with an empty list and the option to add a new project, like so:

Figure 2. Add new dashy client project

Explanation of the fields:

Once you've set all the variables appropriately, click 'add', and you will proceed to the group configuration page. You will be able to configure variables, the variable "file extension" replacement map, release, and instances.

5. Configure variables

The variables are the main differentiator between release. As discussed in "getting started", you need to have your build server and general project set up to produce a naked build. With this in mind, in your configs you now have replaced and abstracted out all variables that determine a release mode and called them something like $connectionString. Hence, you add these here. Note that you don't add the values yet (that comes later). This also implies that the variables need to be the same across all releases and instances. So add them all here, and lets move to the next part ...

6. Variable "file extension" replacement map

Dashy won't attempt to replace variables in all the files in your repositry. It will only attempt it in files that are of the extension you write here. Further, due to reasons I will bring up later, you wil like to have your typical (in ASP.NET) configs named .config.template instead of just .config in your repo, but you want them to become .config when the project is deployed. In this case, your "source extension" would be .config.template and the "destination extension" would be .config.

If you wish, you can replace variables in any files. For example it may be interesting to set a variable in a ".css" file called like so:

body { background-color : $deploymentColour; }

In this case, you would place an entry as .rss in both fields. This will indicate that no change in extensions is required.

7. Configure releases

Okay, now, as we've been discussing, multiple releases are a critical component of dashy. A release can be anything that requires different configs. At work, I have the following releases for one of our projects:

• au testing
• au demo
• au staging
• au live
• uk demo
• uk staging
• uk live

So you can configure yours appropriately. The "image" field is optional, and, seen on how does it work - click deploy page, it will be used as the background image when you get to the 'deploy' confirmation screen. This is so you are reminded of what you are about to deploy.

8. Configure instances

Instances refer to the projects inside your main application. In dashy's case, the instances I have configured are:

• dashy server website
• dashy client website
• dashy server service
• dashy client service
• dashy public website
• dashy tasks

Yours will be similar. The "source directory" refers to directory where the naked build that we've discussed previously will place it's output, per project. Again, in the case of dashy, the values for the aforementioned projects look like so:

c:\cc.net\dashy\release_naked\server.web
c:\cc.net\dashy\release_naked\client.web
c:\cc.net\dashy\release_naked\server.service
c:\cc.net\dashy\release_naked\client.service
c:\cc.net\dashy\release_naked\public.web
c:\cc.net\dashy\release_naked\dashy tasks

So we can infer that the build process that my build scripts go through results in the production of "instances" in the "release_naked" folder.

9. Configure variables

It is now time to go back to the dashboard, and review the fruits of your configuration. You will notice that the releases are listed out, and then the instances repeated within them, with variables layed out in between. You will note that all the variables are marked in red as 'not being set'. When a variable is not set, it will be replaced with a blank string. It is merely a warning, a reminder, because you may forget to set a variable. It is interesting to note that when a new variable is set, after you've configured all your others, it will appear in red, again to serve as a reminder to set it.

So now you may wish to set some of these variables. Click the "edit variables" link, and set them appropriately.

10. That's it for the client

That's effectively it. You can now click on the relevant release, and deploy it. It will show a history of the actions it performs on deployment in the "view history" page.

11. Dashy server

Dashy server is installed on the server you wish to deploy your project to. If your project is deployed within, say, a server farm and hence deployed to multiple servers, you will like to install the dashy server on each of them. With any luck, the layout on each will be the same, so you can sipmly copy the dashy server directory you are about to set up now, on to each of them. In this way, updates to all your forms will, effectively, be done asynchronously (though they will be contacting the same SVN server).

It is worth noting, at this point, that your SVN server (where dashy client is commiting builds) must be available from the servers you intend to deploy to.

With that said, let us begin configuration of the server. Please repeat step 3, on the server. Step 4 is also similar, on the server.

12. Configuration of projects on the server

Again, on the server, you configure releases. The releases you configure may differ, depending on which server you are on.

For the instances, you configure a polling timeout, at which dashy server will look for new updates automatically. Set this to "0" if you want to initiate it manually; you will need to click "force update" for anything to happen. For the "repo type", you must write "svn" (as that is the only source control system supported, for now).

With a project set up, we now get to the interesting part on dashy server, configuration of pre/post deploy actions.

13. Deploy actions

Now the fun begins. Click the "edit deployment actions" link, and you will be presented with a screen asking for "deploy directory" and with a list of tasks you can add to the deployment. The deploy directory is the directory that SVN will update into. So it is worth noting that this directory will contain hidden SVN folders, and is generally not a good place for a "live" application to live. For this purposes, I have created the "CopyToDirTask" task. If you add one of these, and set the directory appropriately, for every update, it will sync the two directories, so any updates will be immediately copied into the appropriate directory. I use this for all web projects, services, etc.

The other type of task you can add, is the generic "RunCommand". Using this, you may (and I do), stop services before update, pause so threads get a chance to finish, then perform a "CopyToDirTask" to get the relevant service updated, and then execute a "net start" again, to get the service going. You may also like to execute a nant task that you have written (this is what I have, in my "dashy tasks" project that I talked about earlier).

As with dashy client, you get histories for all the actions. Only on dashy server, it is slightly more involved. You get to see each task, and the results thereof. If one fails, you may retry it from the website (though the results of its execution won't be saved).

... that's it!

I would say that's about it for the configuration of dashy. I would truly love to hear any thoughts you have on it, and the interesting ways you may configure and use it. If you encounter any problems, or just have any comments in general, let me know via the mailing list, outlined on the contact page.

At this stage you may like to check out the: special variables or notes.