Configuration Mismanagement

Yesterday the guy that leads my team asked me to do a build. We have a separate configuration management team that does the actual builds. I just needed to label some files in source control, and tell the build guys to do their thing. This should be an easy task. But I forgot the first rule of software development. Nothing is ever easy.

I got in this morning. The build was broken. So I investigated what was happening. Then I found it. We are in the middle of making some big changes in our system. Some of those changes had been committed to source control. The problem is that we use one branch for all of development. When the latest build needed to go out with a few files changed, at least one of those files had dependencies on some other in progress file changes which are not getting promoted.

Identification of the problem is usually the hardest part of fixing bugs. I got through the hard part. But how to we proceed? Yes I can manually undo the changes which were breaking the build. That did not seem right. It would make me the new source code control. This should be done by the process or the source code control software. No such luck here.

I did reach a compromise with my manager and team lead. Here is the plan. I am to analyze the in progress files which are absolutely needed to get the build to work. Then we will ship these files with the other ones which are required for this delivery. Hey. If it works, we will have been lucky this time. However the process itself is broken. If we do not fix the underlying process, we will repeat the problem over and over again.