Earlier today I asked the question I know it's a bit of a religious debate, but control name prefixes (txt, lbl); useful practice or the devil's work? and was a little surprised by the result. Actually, what surprised me was the unanimous “devil’s work” response when I expected some balanced arguments!

What am I talking about? I’m talking about names that look like this:

<asp:Label runat="server" ID="lblFirstName" />
<asp:TextBox runat="server" ID="txtFirstName" />

And why am I talking about it? Because FxCop doesn’t like it very much:

The individual words that make up an identifier should not be abbreviated and should be spelled correctly.

Microsoft goes into more detail in rule CA1704 but the bottom line is simply that they believe names should be spelled correctly and abbreviations kind of play havoc with that.

<< Part 4: Continuous builds with TeamCity

In the first four parts of this series we got config transforms playing nice, command line builds and packaging ticking along, Web Deploy happily receiving our application and TeamCity continuously building the entire solution on every commit. The last thing to do is to harmonise everything so that we can actually automate the deployment.

<< Part 3: Publishing with Web Deploy

Part 5: Web Deploy with TeamCity >>

Over the last three posts in this series, we got to the point where all the Microsoft bits are working really nicely together. Config transforms, packaging and Web Deploy are great stable mates in the world of web application deployment.

The bit that’s missing though is automation. Actually there are several bits missing but automation is the common solution. Deployment by developers directly from Visual Studio or command line with MSDeploy works fine most of the time but has a few flaws we’re simply not going to be able to overcome without a build and deployment server. In all likelihood, your existing release process looks something like this:

The problems with this are numerous:

1. Access rights – you’re giving the developer too much if they can directly invoke Web Deploy either with their own credentials or other credentials they know. They will bend to temptation and circumvent release procedures, even though it’s normally well intentioned (just had to turn off custom errors for a moment…).
2. Auditability – well, you’ve got none. You have no way of automatically capturing when, what and who. You could have a dozen releases in a day and be none the wiser because if it’s not automated, the information is inevitably not recorded or done so poorly.
3. Rollback – you know how rollback is most commonly done? Copy the target folder and rename it “old_MyWebApp”, publish the new app then if it breaks, copy the old files back over. I’d bet my bottom dollar that in lieu of a build and deploy environment, this is your rollback strategy. Either that or pulling a previous revision from VCS and repeating a manual deploy which can be both time consuming and error prone.
4. Version control – if you’re not deploying directly from your VCS, what confidence do you have that released source code is retrievable or reproducible? You’re (hopefully) not publishing all your source code to the target environment so short of some emergency reverse engineering, a developer could easily release code you’re never going to be able to reproduce.

I’m sure there are other good reasons but that’s a good kick-off for the moment.

<< Part 2: MSBuild and deployable packages

Part 4: Continuous builds with TeamCity >>

In the first two parts of this series we got config transforms working and the web app successfully bundled into a nice self-contained deployable package. Next up: get the thing to publish.

For the most part, the vast majority of web app deployment has historically been done by pushing the entire site out over either UNC or FTP, a practice which has a series of fundamental shortcomings that set deployment up for potential failure. To begin with, by default neither protocol is encrypted. Yes, there’s SFTP and FTPS but it’s not often you see these applied, particularly not as a standard offering by hosting providers. Remember, your connection strings and other potentially sensitive information (beyond just the code!), is being sent across the wire in plain text.

Then there’s the issue of the content; an awful lot of web content is bloated HTML, CSS, images and JS files. Pushing it all out on every publish is a very time consuming exercise when in reality, most deployments beyond the first one usually only include small change sets.

Finally, the traditional tools available for publishing via these channels tend to only push files out, they don’t remove files from the target. Refactor your app to change the file structure and publish via the traditional way and there’s a very good chance you’re going to end up with a whole bunch of rogue files in the target that simply shouldn’t be there anymore.

So the old way of doing things is usually insecure, very slow and frequently leaves the target website in a mismatched, Frankenstein kind of state of different versions. None of this is very desirable!

<< Part 1: Config transforms

Part 3: Publishing with Web Deploy >>

In the first part of the series we looked at config transforms and how we’ve moved on from the bad old days of manual Web.config configuration at release time. Now let’s take a look at how we can incorporate this into a nice clean deployable package with the rest of the application.

Many people, me included at one stage, have only ever been familiar with the concept of .NET compilation as a result of building within Visual Studio. Keep in mind though that Visual Studio is no more than an IDE. Ok, it’s a particularly good IDE but it doesn’t have a monopoly and compilation and actually creating object code from C# (or that other one).

Once we start moving towards compiling on a build server, there’s no concept of Visual Studio (it won’t be installed on the machine) and we need to be able to run builds from the command line. This is why we now need to start getting a bit intimate with MSBuild.

Part 2: MSBuild and deployable packages >>

If you publish a web application using CTRL-C and CTRL-V, you’re deploying it wrong.

If you manually run an Xcopy command, you’re deploying it wrong.

If you use an FTP client to move your files to a remote server, you’re deploying it wrong.

If not everyone is following exactly the same release process, you’re deploying it wrong.

If publishing involves any manual handling of Web.config, you’re deploying it wrong.

This might seem a little sensationalist but after Scott Hanselman set a high “doing it wrong” bar in his excellent Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong video, he made it pretty clear just how wrong many people have been doing deployment.

To be fair, there really haven’t been a lot of alternatives. Some of the “wrong” scenarios above have only been satisfactorily addressed in the latest generation of tools. But now that they have, the excuses for “deploying it wrong” are running out.

This entire series is now available as a Pluralsight course.

And also as a free eBook.

If you’re anything like me (and if you’re reading this, you probably are), your browser looks a little like this right now:

A bunch of different sites all presently authenticated to and sitting idly by waiting for your next HTTP instruction to update your status, accept your credit card or email your friends. And then there’s all those sites which, by virtue of the ubiquitous “remember me” checkbox, don’t appear open in any browser sessions yet remain willing and able to receive instruction on your behalf.

Now, remember also that HTTP is a stateless protocol and that requests to these sites could originate without any particular sequence from any location and assuming they’re correctly formed, be processed without the application being any the wiser. What could possibly go wrong?!