Tag: TeamCity

Posted on
by

UPDATE: The book I mentioned, Continuous Delivery with Windows and .NET, by Chris O’Dell and Matthew Skelton, can be found here.

On a lovely warm Thursday evening in May I returned to the speaker’s floor and presented a great session on Continuous Integration, Delivery and Deployment, to a fantastic group of developers at DevSouthCoast in Southampton.

The main takeaways from the session are all about how easy CI, CDel and CDep can be to get going, as well as how you can start the process off for free using popular, industry-used products. One of the most exciting parts of this session for me is that everything about the session is live. Using two VMs I replicate a standard setup – installing and configuring the applications right there on the session floor. Whilst the progress bars load I talk about how the applications I’ve chosen will help the process flow and what they bring to the Continuous party,
Continue reading →

Posted on
by

“Once in every show there comes a song like this..”
Spamalot

My personality means I am always wanting to push myself further by learning new things, pushing my boundaries and taking on new challenges. This was, in part, the reason why I took on the challenge of presenting at DDD events many years ago and a major part in the difficult decision to leave my current position as Development Director at Morning Data. It is an inevitable decision once you realise you’re not pushing yourself as much as you should, much like the inevitable emotion-rousing song in musical theatre.

When I joined the company back in February 2003 I was the very first employee and the first to introduce the company to the world of the Microsoft .NET Framework. Bring us forward to the current day and I leave the company as their Development Director having risen through the roles of Senior Developer and Head of Development. I leave behind me a fantastic team of excellent, talented, first-rate developers and co-workers whom I have had the pleasure of calling my colleagues and will continue to call my friends.

With the company we broke the golden rule of rewriting software and successfully proved that it is possible if managed and handled properly within the team. Between us we introduced Continuous Integration, Build Radiators, Continuous Deployment, Unit Testing, TDD, Kanban boards, morning stand-ups, the infamous WAT board and as much agile as we could stomach. The company is now poised for many, many great things and wish them all the success in the world. For me its onto a brand new challenge and it all starts tomorrow.

Posted on
by

If you’re using TeamCity as your Continuous Integration tool then you will be glad to know there’s a really easy way of getting a Build Radiator set up – and it’s very a quick job too, thanks to TeamCity doing most of the hard work for you by making a status page available.

The status page contains all the information we need for a basic Build Radiator but as it stands the default status page isn’t much to look at. With the help of a bit of jQuery to apply some jiggery-pokery and a little bit of CSS we can turn the text-heavy page into a starter for your own Build Radiator.

Continue reading →

Posted on
by

I love Build Radiators. The ability to pass information to a team of developers easily and immediately is far and above one of the most important things any CI method needs to do. (Apart from manage the whole Continuous Integration model)

Ever since we plugged in the Continuous Integration tool that is TeamCity I have been totally immersed in the world of Build Radiators, otherwise known as Build Status Screens or Build Notifiers (or the big red light that flashes whenever a build fails).

Continue reading →

Posted on
by

The speed at which a rewrite project goes is often a very big factor in deciding whether or not it will be successful, and it’s often one of the most overlooked elements of a rewrite project.

Speed influences so many factors of a rewrite project it’s difficult to list them all in one article so for now we’ll approach them one at a time. In this post I’m going to look at the speed at which a rewrite might adopt new tools into their overall build process, but the same core message applies to almost every aspect of a rewrite, and I’m hoping that the title of this post indicates what I’m trying to get to…

Developers on a rewrite project should do it slowly.

Continue reading →