Powered by Twitter Tools

Powered by Twitter Tools

Currently working with a company in Norwich, to improve their software delivery processes.

Much of this process was developed whilst I had the pleasure of working with Philip Fitzsimons, but I thought I’d tackle the topic from the perspective of a Software Quality manager and use the DC blog to record the journey.

This project has the following broad aims:

1. Reduce defects
2. Improve reliability
3. Improve productivity
4. Promote team synergy

Most software development is done by a team, not a lone programmer working into the early hours.

Teams often vary in size, but typically consist of specialists

covering the full gamut of the programming, and making effective use of this pool of resource is often the most complicated aspect of software delivery.

Powered by Twitter Tools

Powered by Twitter Tools

I’ve opened my articles up to comments as I’m very lonely! Not many people take CI seriously, we seem to be far and few between. I’m hoping with my blog that I’ll find like minded developers with a keen interest in software quality, build management and agile development. I can’t wait to put our collective heads together and build better CI solutions.

My build pipelines, consist of three core technologies. TFS, MSBuild and Powershell.

I love TFS, it has a great API and has enabled me to implement some very esoteric build scenarios. I like many aspects of TFS, such as its workspace management, it’s build controllers and build management. That said, I think MSBuild is horrendous, and TFSBuild justs rubs salt into the wound. This is why my CI solutions (aka Pipelines) take what I consider to be the best bits of TFS, and the rest is used sparingly, or not at all.

I’ve found that learning Powershell was one of the best investments of effort I’ve made in recent years. So much so that I’ve almost entirely substituted MSBuild and TFSBuild for Powershell scripts. This is why virtually all of my posts on this topic will be about how cool Powershell is, and look what it did for me today!

Powershell orchestrated builds can be run on the local developer machine as well as remotely on a TFS build agent, which is great news! It means developers working on the code base can run their builds instantly on their local environments and get very fast feedback. I know TFS has private builds but it’s no where near as quick as running the build locally. The primary motivation for local builds is principally feedback time, its very very fast. As a build and release manager, it is my responsibility to maintain a healthy code base and to stop the developers from doing anything that might jeopardise the stability and security of the software contained within. Because my developers can run their builds locally, there is simply never-ever-ever going to be an acceptable excuse for checking in code that will break the build. If they do, I shoot them, and I’m not kidding. However, foam Nerf darts are only intended to focus peoples minds on the seriousness of contaminating the code base, I’m not out to hurt anyone!

I like to keep as close to the Agile and CI principles as possible, so I tend to recommend using branches only sparingly. For every-day business-as-usual story development, I want the developers to be checking into main trunk. If they’re working on a spike, some experimental feature, a major refactor, then I’ll insist on a branch being used. Its been my experience in the past that teams can become too dependent on branches, branches become too numerous, too distant from main and has the unsettling effect of fragment the code base. I’m not against using branches, I just feel we should use them sparingly.

The other reason I love Powershell is that enables me to build pipelines for some very complicated build scenarios. I’m currently working on a pipeline that will build and deploy an entire platform consisting of over 100 projects in 24 solutions with some circular inter-dependency. Each project has its own unique quality thresholds, build configurations and deployment requirements. I shudder to think how awful it would have been to orchestrate this build using MSBuild.

On the topic of speed, another area where Powershell shines its ability to run parallel jobs on distributed environments. This has enabled me to parallelise many parts of my builds, reducing unit-testing times for instance from 15 minutes to 4, which is great, because fast feedback is very important. At some point in the future I’m going to investigate taking this one step further and using some of the insanely-powerful and under utilised desktop computers that are in the building. For now however, I’m happy that Powershell has enabled me to run most aspects of my build pipeline in parallel, and reduced the overall build times from 100 minutes to 18.

What I don’t use Powershell for is managing the build workspaces, versioning or build management. This is what TFS does wonderfully.

So, from here on in, my posts will be all about the code!

Thanks for reading.

My blog is mostly going to be focused on CI, as sloppy programming and quick-n-dirty fudges drive me insane! If its worth doing, its worth doing right!

So, all that remains to be said is thank-you for reading my blog.