While I consider myself experienced in debugging with Visual Studio I still didn’t know the Ctrl+B trick Ingo shows in the first session to create breakpoint groups, for example to break on all methods named WriteLine.

Ingo’s second session goes into detail how to start with WinDbg. During his talk Ingo wrote down quite a lot of WinDbg commands that I copied and extended a bit for my own reference.

Updated on 2012-03-06 to reflect the changes to the Gitolite installation process.

For obvious reasons, a couple weeks ago my team made the switch to Git.
Hosting a Git server on Windows is by all means
possible, and there are two options:

Gitosis is a Python-based solution that provides basic Git
hosting with per-repository permissions.
Shannon Cornish has an excellent
two-part
guide how to set that up.

Gitolite, a Perl-based rewrite of Gitosis, is a more advanced
Git server that has
a lot more configuration
options. For example, it’s
possible to specify who is able to force a push to a Git
branch, an operation that is possibly problematic when
working in teams.

A notable aspect of both solutions is that repository configuration and permissions management is done through
Git itself. Over time, you will build a versioned history of the server configuration. Without further ado,
let’s get started!

Contents

You’ll see that we have to deal with Cygwin and SSH mostly.
Gitolite’s installation is pretty easy and does not require a
lot of work by itself. Getting the Windows Server in a condition
where it handles SSH takes most of our time.

In the packages list, select the following packages by clicking on “Skip” text in the “New” column. When you
clicked, the version that will be installed is displayed instead of “Skip”.

Net | openssh

Devel | git

Editors | vim

Click Next and wait for the installer to complete.

You may choose to add icons to the Desktop and Start Menu. Click Complete.

I recommend leaving the setup.exe in place, as you can use the installer to add, remove or upgrade Cygwin
packages later.

Repeat the process on your local machine, this time with an extended set of packages
to install:

Net | openssh

Devel | git

Devel | git-completion (optional)

Devel | git-gui (optional)

Devel | git-svn (optional, if you want to commit to SVN)

Devel | gitk (optional)

Connecting Cygwin to Windows Security

In preparation for the SSH server installation in
the next section, we need to provide Cygwin with
means to impersonate a SSH user as a Windows user
with public key authentication. You can read more
about
integrating with Windows Security in the
Cygwin documentation.

Setting Up the SSH Server

SSH will encrypt and authenticate connections to your Git repositories. SSH will use public key authentication to
check if the user is permitted to access the server. Once the user got past the SSH security check Gitolite will take
over handling the request.

When the Git server finished rebooting:

Open a new Cygwin Bash prompt by running C:\Cygwin\Cygwin.bat as Administrator.

*** Info: Note that creating a new user requires that the current account have
*** Info: Administrator privileges. Should this script attempt to create a
*** Query: new local account 'sshd'? (yes/no)

Type yes.

*** Info: Updating /etc/sshd_config file
*** Warning: The following functions require administrator privileges!
*** Query: Do you want to install sshd as a service?
*** Query: (Say "no" if it is already installed as a service) (yes/no)

Type yes.

*** Query: Enter the value of CYGWIN for the daemon: []

Just hit the Return key.

*** Info: On Windows Server 2003, Windows Vista, and above, the
*** Info: SYSTEM account cannot setuid to other users -- a capability
*** Info: sshd requires. You need to have or to create a privileged
*** Info: account. This script will help you do so.
*** Info: You appear to be running Windows 2003 Server or later. On 2003
*** Info: and later systems, it's not possible to use the LocalSystem
*** Info: account for services that can change the user id without an
*** Info: explicit password (such as passwordless logins [e.g. public key
*** Info: authentication] via sshd).
*** Info: If you want to enable that functionality, it's required to create
*** Info: a new account with special privileges (unless a similar account
*** Info: already exists). This account is then used to run these special
*** Info: servers.
*** Info: Note that creating a new user requires that the current account
*** Info: have Administrator privileges itself.
*** Info: No privileged account could be found.
*** Info: This script plans to use 'cyg_server'.
*** Info: 'cyg_server' will only be used by registered services.
*** Query: Do you want to use a different name? (yes/no)

Type no.

*** Query: Create new privileged user account 'cyg_server'? (yes/no)

Type yes.

*** Info: Please enter a password for new user cyg_server. Please be sure
*** Info: that this password matches the password rules given on your system.
*** Info: Entering no password will exit the configuration.
*** Query: Please enter the password:

Type and confirm a secure password for the SSH service account. This account will later fork processes on
behalf of the user logged in via SSH. You will see another slew of text (which you should read) and then a
blinking prompt.

Open the Windows Firewall and create an exception for port 22/tcp. Thanks to Marcel
Hoyer
for the command line equivalent:

Press Ctrl + D or execute logout to end the session and you’ll be back on your machine’s prompt.

Creating Your SSH Identity

The next steps to create two SSH identities. The first is required to access the soon-to-be Git server, the second
will be used to install and update Gitolite. Execute the following commands on your local machine.

We’re about to generate a private and public key pair for you that will be used to authenticate SSH connections.
Execute ssh-user-config

Type and confirm a passphrase. You can omit the passphrase if you want, but that makes you less secure when you
loose your private key file.

*** Query: Do you want to use this identity to login to this machine? (yes/no)

Type no. (Unless you want to remotely log in to your workstation with that key. Don't worry, this can
be enabled later.)

*** Query: Shall I create an SSH2 DSA identity file for you? (yes/no)

Type no.

*** Info: Configuration finished. Have fun!

Repeat the steps above using ssh-keygen -f ~/.ssh/gitolite-admin. We need that key for the
installation process.

Making the SSH Server Aware of Your SSH Identity

In order to be able to log-in to the Git server as the git user using your gitolite-admin SSH
identity, execute ssh-copy-id -i ~/.ssh/gitolite-admin git@git-server.
This adds the gitolite-admin public key to the list of authorized keys for the git account.

Installing Gitolite

Upgrades to newer versions of Gitolite are easy and run like the first-time installation. That is, you can just
repeat the process outlined below, probably with a new Gitolite version. This installation method requires a SSH
login, but we’ve just set-up things this way.

Before proceeding, we need to copy the non-admin public SSH key to the server.

Press the letter O (uppercase this time) to enter Vim’s insert mode on a new line before the current
line.

Type the following into the text file: $ENV{PATH} = "/usr/local/bin:/bin:/usr/bin";

Press ESC to leave Vim’s insert mode.

Type :w and hit Return to save the file.

Apply any changes to the well-commented
configuration you want to
make.
You can navigate using the cursor keys, and enter insert mode by pressing i. Leave insert
mode by hitting ESC.

Type :wq and hit Return to save the file and exit Vim. To dismiss any changes made in the
last step and exit Vim, type :q! and hit the Return key.

Leave the SSH session by pressing Ctrl + D.

Once the installation is finished, you can clone the gitolite-admin repository to your desktop.

$ git clone git@gitserver:gitolite-admin.git

To add repositories or change permissions on existing repositories, please refer to the
Gitolite documentation. The process uses
Git itself, which is awesome:

Make changes to your copy of the gitolite-admin repository in your home directory.

Commit changes locally.

Push to the Gitolite server and let it handle the updated configuration.

If you ever want to update or manage the Gitolite server, you can still SSH into the server with

$ ssh -i ~/.ssh/gitolite-admin git@gitserver

Wrapping Up

This guide as been pretty long, longer than I wish it had been. Following
Shannon Cornish’s example, I wanted
it to be rather too verbose than too short. At least, I did appreciate the detail of Shannon’s instructions when I
installed Gitosis back in December. I’ve just begun to grasp the power of Unix – leveraging a set of tiny programs to
orchestrate a system.

With the setup you have now in place, you can do anything you like – it’s a complete Git server. However, if you want
to publish your server on the internet there’s more you will want to take care of. I will go into that in a future
post, detailing some of Cygwin’s security features that helped us reduce the number of attacks on our server. Also, I
will take a look at how you can enable the Gitweb
Repository Browser using the lighttpd web server.

A couple of days ago Hadi Hariri posted his set of MSpec (Machine.Specifications) templates for ReSharper. ReSharper’s templating system helps you type less repeated code. On top of that, ReSharper templates are much richer when compared to what’s built into Visual Studio. Plus, you edit them with a decent editor instead of hacking XML files.

Like Hadi, I also created a couple of templates specific to MSpec over the course of the last year or so and found them often to reduce the amount of text I have to write. ReSharper Templates are divided into three categories, with at least one MSpec template in each.

Legend

foo denotes an editable part of the template

| denotes where the cursor will be put upon expansion

File Template

Basically, this is just a new C# file with a single MSpec context in it.

About two years ago I quit the pain of CruiseControl.NET’s XML hell and started using JetBrains TeamCity for Continuous Integration. Whilebeing a bit biased here, I have to admit that every JetBrains product I looked at is absolutely killer and continues to provide productivity on a daily basis.

I’ve been a fan of Continuous Integration ever since. I figured the next step in improving our practice was not only to automate building/compiling/testing the application, but also deploy it either by clicking a button or based on a schedule. For example, updates to this blog’s theme and the .NET Open Space web sites are automated by clicking the “Run” button on my local TeamCity instance.

Compare that button click to what we are forced to do manually for some projects at work. Every time we roll out a new version someone will:

Build the deployment package with TeamCity.

Download the deployment package, which is usually a ZIP containing the application and database migrations.

RDP into the production server.

Upload the deployment package.

Shut down the web application, Windows services, etc.

Overwrite the binaries and configuration files with the current versions from the deployment package.

I believe you can imagine that the manual process outlined has a lot of rope to hang yourself with. An inexperienced developer might simply miss a step. On top of that, implicit knowledge of which files need to be edited increases the bus factor. From a developer and business perspective you don’t want to deal with such risks. Deployment should be well documented, automated and easy to do.

Deployment Over Network Shares Or SSH

When I first looked into how I could do Continuous Deployment there were not many free products available on the Windows platform. In a corporate environment you could push your application to a Windows network share and configure the web application through scripts running within a domain account’s security context.

A different story is deployment over an internet connection. You would want to have a secure channel like a SSH connection to copy files remotely and execute scripts on the server. This solution requires SSH on the server and tools from the Putty suite (i.e. psftp) to make the connection. I had such a setup in place for this blog and the .NET Open Space web sites, but it was rather brittle: psftp doesn’t provide synchronization, integration with Windows services like IIS is not optimal and you’re somewhat limited in what you can do on the server.

MSDeploy

Last year, Microsoft released MSDeploy 1.0 which was updated to version 1.1 last week. MSDeploy is targeted to help with application deployment and server synchronization. In this article, I will focus on the deployment aspects exclusively. Considering the requirements for deployment, MSDeploy had everything I asked for. MSDeploy either

runs as the Web Deployment Agent Service providing administrators unrestricted access to the remote machine through NTLM authentication, or

runs as the Web Deployment Handler together with the IIS Management Service to let any user run a specified set of operations remotely.

Both types of connections can be secured using HTTPS, which is great and, in my opinion, a must-have.

I won’t go into the details of how MSDeploy can be set up because these are welldocumented. What I want to talk about what concepts we employ to deploy applications.

The Deployment Workflow

With about three months of experience with MSDeploy under our belts, we divide deployments into four phases:

Initial, minimal manual preparation on the target server

Operations to perform in preparation for the update

Updating binaries

Operations to perform after the update has finished

The initial setup to be done in phase 1 is a one-time activity that only occurs if we decide to provision a new server. This involves actions like installing IIS, SQL Server and MSDeploy on the target machine such that we can access it remotely. In phase 1 we also create web applications in IIS.

Further, we put deployments into two categories: Initial deployments and upgrade deployments. These only differ in the operations executed before (phase 2) and after (phase 4) the application files have been copied (phase 3). For example, before we can update binaries on a machine that is running a Windows service, we first have to stop that service in phase 2. After updating the binaries, that service has to be restarted in phase 4.

Over the last couple of weeks, a set of operations have been identified that we likely execute in phase 2 and 4.

Operation

Description

During Initial Deployment

During Upgrade

Before Or After Deployment

Set-WebAppOffline

Shuts down a web application by recycling the Application Pool and creating App_Offline.htm

No

Yes

Before

Set-WebAppOnline

Deletes App_Offline.htm

No

Yes

After

Create-Database

Creates the initial database

Yes

No

After

Update-Database

Run migrations on an existing database

No

Yes

After

Import-SampleData

Imports sample data to an existing database for QA instances

Yes

No

After

Install-Service

Installs a Windows service, for example one that runs nightly reports

Yes

Yes

After

Uninstall-Service

Stops and uninstalls a Windows service

No

Yes

Before

It’s no coincidence that the operations read like PowerShell Verb-Noun cmdlets. In fact, we run operations with PowerShell on the server side.

The deployment directory that will be mirrored between the build server and the production machine looks like the one depicted in the image to the right.

The root directory contains a PowerShell script that implements the operations above as PowerShell functions. These might call other scripts inside the deployment directory. For example, we invoke Tarantino (created by Eric Hexter and company) to have our database migrations done.

Rake And Configatron

As you might remember from last week’s blog post we use Rake and YAML in our build scripts. Rake and YAML (with Configatron) allow us to

build the application,

generate configuration files for the target machine, thus eliminating the need to make edits, and

formulate MSDeploy calls in a legible and comprehensible way.

Regarding the last point, please consider the following MSDeploy command line that synchronizes a local directory with a remote directory (think phase 3). PowerShell operations will to be performed before (-preSync, phase 2) and after the sync operation (-postSyncOnSuccess, phase 4).

What I Haven’t Talked About

What’s missing? An idea that got me interested was to partition the application into roles like database server, reporting server, web application server, etc. We mostly do single-server deployments, so I haven’t built that yet (YAGNI). Eric Hexter talks about application roles in a recent blog entry.

Another aspect where MSDeploy unfortunately doesn’t shine is error handling. Since we run important operations using the runCommand provider (used by -preSync and -postSyncOnSuccess) we would want to fail when something bad happens. Unfortunately MSDeploy, to this day, ignores errorlevels that indicate errors. So we’re back to console redirection and string parsing. This functionality is already in my MSDeploy helper for Rake, so you can rely on it to a certain degree. Manually scanning log files for errors, at least for the first couple of automated deployments is recommended, though.

Since we’re leveraging PowerShell on the server, why should we have to build the PowerShell script handling operations ourselves? I can imagine deploying the PowerShell-based PSake build tool and a PSake build script containing operations turned build targets. This will allow for common build script usage scenarios like task inspection (administrators would want that), having task dependencies, error handling and so on.

Wrapping Up

In this rather long post, I hope I could provide you with information how MSDeploy can be used to deploy your applications automatically. For us, over the last couple of weeks, MSDeploy in combination with our Rakefiles has helped us tremendously deploying an application that’s currently under development: The pain of delivering current versions to the customer has gotten a breeze.