Ah, automation. Any time I find myself doing the same thing more than once, I get the inclination to bundle it all up into something that can begin happening with a single click. Or even better, with no clicks.

I’ve been writing a lot on continuous integration lately, primarily using TeamCity to execute tasks on the change of source code, on a nightly basis and on demand. I’ve automated deployment of websites with web deploy, deployment of databases with RedGate, code quality with NDepend, code statistics with StatSVN and application security with Netsparker.

Recently I’ve begun using WCSA or in non-acronym terms, the Web.Config Security Analyser. This little beauty let’s you feed in a Web.config then it comes back and tells you everything you’ve done wrong in the world of security configuration. I talked a little about Web.config security in OWASP Top 10 for .NET developers part 6: Security Misconfiguration but there’s a lot more to it than just the old custom errors, debugging and tracing.

Since the Web.config tends to change a bit over time and poses a potentially serious security risk if it’s implemented poorly, inspecting it is ripe for automation.

Banks don’t get it. Telcos struggle with it. Airlines haven’t got a clue. That’s right folks, its password time again.

Earlier in the year I wrote a little post about the who’s who of bad password practices. I named, I shamed and I got a resounding chorus of support. The point was made.

But it still bugged me. Why were our banks and airlines so consistently forcing us to choose poor passwords? Why do they constrain our length, discriminate against our character types and in some cases, even discard the entire alphabet? I mean there must be a reason, right?

So I asked each one of them.

Let’s assume you log onto a bunch of different websites; Facebook, Gmail, eBay, PayPal probably some banking, maybe a few discussion forums and probably much, much more.

Do you always create unique passwords such that you never use the same one twice? Ever?

Do your passwords always use different character types such as uppercase and lowercase letters, numbers and punctuation? Are they “strong”?

If you can’t answer “yes” to both these questions, you’ve got yourself a problem. But the thing is, there is simply no way you can remember all your unique, strong passwords and the sooner you recognise this, the sooner you can embrace a more secure alternative.

Let me help demonstrate the problem; I’ll show you what happens when you reuse or create weak passwords based on some real world examples which should really hit home.  I’ll also show you how to overcome these problems with a good password manager so it’s not all bad news, unless you’re trying to remember your passwords.

I must have struck a chord with the folks at Red Gate recently when I wrote about Automated database releases with TeamCity and Red Gate. Inadvertently, I managed to get this post out right in the final stages of their work on SQL Source Control 2 which added the ability to version static data. This was pretty opportune timing and caused me to rewrite – and significantly simplify – a fair swathe of the post.

Clearly the post was a glowing endorsement of their tools, and rightly so. In conjunction with TeamCity, they’ve helped me to fill a fairly gaping hole in the CI process and bring the DB up to a first class citizen with the application tier. They asked me if I’d like to contribute the article to Simple-Talk and it’s largely consistent with the original. It’s now online here:

Continuous Integration for SQL Server Databases

If you’re not versioning your databases or if you’re still manually releasing them or writing laborious change scripts, this is worth a read. Once you go down the DB CI path, looking back at the way things used to be is just downright scary!

So I went along to the ThoughtWorks quarterly update on Continuous Delivery today. This took the form of a panel discussion with Martin Fowler, Evan Bottcher and Neal Ford. Smart guys, interesting topic and tantalising banner ad:

The good news is that I didn’t hear anything that sounded too foreign. Either they were principles I’d written about, experienced firsthand or at least had a good understanding of. Usually it was all three but hearing the words from these guys in a very candid fashion is a great endorsement of the beliefs.