At work at the moment we are going through the process of verifying the binaries and their call-trees on one of the production servers that’s been on a delta-upgrade-cycle-only release plan for a long time (delta-upgrade-cycle-only: the process of only releasing changed files to a live environment and never doing a full refresh).
I don’t agree with the philosophy of delta-upgrade-cycles-only. I think you should periodically do a full system refresh on every live system, and it should be an integral part of software develpoment and release process.
More often than not, people don’t do this because it’s too hard to either know what’s out there on their live server, or to deploy the full system with any confidence. Those reasons just aren’t good enough. Continuing on with delta-upgrades only treats the symptom, not the cause.
So in the mean time much pain for us as we ensure that the series of binaries and configuration files on this live server haven’t strayed too far from the “ideal” in our Continuous Integration system. I remembered recently that I happend to have a Pro License to the tool NDepend lying around unused, so we’ve decided to put it to use in the process of our analysis. More on that tool when we’ve put it through it’s paces.
What’s the point of this rant?
The whole point of Continuous Integration is that you are always able to reconstruct/test/verify your fully integrated system directly from your development environment. This panacea is actually achievable (I’ve done it before) in a new software team on a new clean project. But the hardest part of adopting Continuous Integration is jury-rigging it to existing build and deployment systems on legacy platforms. Finding the compromise between practicality and delivering a functional system, and idealism and tearing the whole system down and starting from scratch is a very delicate operation indeed.
Gee I wonder which system that is….