One of the drawbacks to looking a bit like Methuselah (‘And all the days of Methuselah were nine hundred sixty and nine years:’) is that young developers keep trying to explain terms like NOSQL, Test Driven Development (TDD), Continuous Delivery (CD) or Version Control Systems (VCS) to me as if I’m a strange time traveller from the steam age. Even back in the seventies, we did this stuff, even though the tools were more primitive, and we didn’t have the same level of missionary zeal towards the techniques. All that has changed since then are the names and the number of evangelists gathered around each technique.

I find it amusing that database developers are often portrayed as primitive folk, like hunter-gatherers, who have never even heard of new-wave development techniques such as Agile, DevOps and Continuous Delivery. Database Developers seem to have a characteristic streak of independence. Sure, there are a few luddites in every trade but most of the other SQL Server Developers that I know understand this stuff and if it is to their advantage will use it, even if not in quite the same way that the C# procedural devs would want.

Take Continuous Integration, for example. I do it because I can then prove that the database in development is deployable. I like doing a daily build of a SQL Server database during development. I do a build on a clean VM from whatever is in source control, using PowerShell scripts that are also in source control. The main aim is to make sure that what is on my development server and what is built are one and the same thing, and that everything works the same way.

This may seem pretty simple, but if you have, for example, CLRs, PowerShell jobs, and SSIS Custom components to deal with, and you have scheduled jobs, alerts and maybe elaborate access-control mechanisms, then it can get more interesting. There can be even more complexity in the build, but I imagine that the average DBA could cap my experiences. If the development team can prove that the scripts in source control can build the whole lot onto a fresh database Server and can then run a battery of integration tests to prove that it all works then they are also able to prove that what they are developing can be deployed and that there is no technical debt that would delay a deployment. By comparing the development server with the integration build, you can also prove that what is in source control is up-to-date. In fact, you can look pretty smug when someone from central IT comes around and says that what you’ve developed is not deployable.

I’m interested in understanding the range of techniques that are being used for doing this sort of work. For example, I now use PowerShell as the automation tool. Does anyone use build servers? Do you consider this exercise unnecessary, or too lax, and if so, how do you approach deployment issues?

Phil Factor.

PS. Apologies for the 'slim' edition of this week's newsletter. This was due to difficulties with both our news aggregator (see http://www.forbes.com/sites/jaymcgregor/2014/06/12/feedly-goes-down-again-in-second-ddos-attack/) and with our own DBW administration tool.