Every rewrite project has opportunities in it. Opportunities to improve your development process, your build and deployment strategies, your third party tools and libraries, even our choice of language can come under scrutiny (except for when you have to move because of the language you were using!)
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.
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).
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.
There’s no better feeling in the world than coming into the office from a long weekend away to find that your Build Server has disappeared without trace.
Okay, so maybe there are better feelings in the world, but they don’t come close to the joy of finding that the database used by TeamCity saves very little other than user profiles and related settings, and that nearly all the really important stuff is saved elsewhere.