Continuous Integration

Edit (6 Oct 2020): It looks like the WCSA website has disappeared since originally writing this article and the domain is now parked on a porn site. The Google Code archive still exists so the blog post is still relevant, just be conscious that this project has obviously gone unloved for some time now and make take you to unexpected places. 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 happenin...

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 [https://www.troyhunt.com/2011/02/automated-database-releases-with.html]. 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 po...

So I went along to the ThoughtWorks quarterly update on Continuous Delivery [http://www.thoughtworks.com/events/thoughtworks-quarterly-briefing-continuous-delivery] today. This took the form of a panel discussion with Martin Fowler [http://martinfowler.com/], Evan Bottcher [http://evan.bottch.com/] and Neal Ford [http://nealford.com/]. 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’...

Databases have long been the poor cousin of the application tier when it comes to many of the processes we take for granted in the .NET world. Source control management, for example, is near ubiquitous for application files and there are several excellent VCS products which make versioning a breeze. Continuous integration is another practice which although not as common, is still frequently present in a robust application lifecycle. Of course the problem is that database objects don’t exist as...

Late last year I got all excited about continuous deployment with TeamCity when I wrote a five part series [https://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html] on using it in conjunction with web deploy. I then went on to write about Continuous code quality measurement with NDepend and TeamCity [https://www.troyhunt.com/2010/12/continuous-code-quality-measurement.html] and Continuous project statistics with StatSVN and TeamCity [https://www.troyhunt.com/2010/12/continuous-proj...

Yesterday I wrote about Continuous code quality measurement with NDepend and TeamCity [https://www.troyhunt.com/2010/12/continuous-code-quality-measurement.html] where I looked at nightly builds that assessed code quality using the very excellent NDepend. These reports are great and it’s easy to configure but you need to make both a dollar investment in the software and an education investment to really understand the metrics and how they relate to code quality. What’s nice about StatSVN [http:...

I love a good set of automatically generated code metrics. There’s something about just pointing a tool at the code base and saying “Over there – go and do your thing” which really appeals to the part of me that wants to quantify and measure. I think part of it is the objectiveness of automated code analysis. Manual code reviews are great, but other than the manual labour issue, there’s always that degree of subjectiveness the human bring with them. Of course code reviews are still important, b...

<< Part 4: Continuous builds with TeamCity [https://www.troyhunt.com/you-deploying-it-wrong-teamcity_25/] 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. Breaking down the build and deploy processes First...

<< Part 3: Publishing with Web Deploy [https://www.troyhunt.com/you-deploying-it-wrong-teamcity_24] Part 5: Web Deploy with TeamCity >> [https://www.troyhunt.com/you-deploying-it-wrong-teamcity_26/] 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 a...

<< Part 2: MSBuild and deployable packages [https://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_11.html] Part 4: Continuous builds with TeamCity >> [https://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_25.html] 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 historica...