How to identify what projects have been affected by a code change

Question

I have a large application to manage consisting of of three or four executables and as many as fifty .dlls. Many of the source code files are shared across many of the projects.

The problem is a familiar one to many of us - if I change some source code I want to be able to identify which of the binaries will change and, therefore, what it is appropriate to retest.

A simple approach would be simply to compare file sizes. That is an 80% acceptable solution, but there is at least a theoretical possibility of missing something. Secondly, it gives me very little indication as to WHAT has changed; It would be ideal to get some form of report on this so I can then filter out irrelevant (e.g. dates/versions copyrights etc..)

On the plus side :

1. all my .dcus are in a row - I mean they are all built into a single folder
2. the build is controlled by a script (.bat)(easy, for example, to emit .obj files if that helps)
3. svn makes it easy to collect together any (two) revisions for comparison

On the minus side

1. There is no policy to include all used units in all projects; some units get included because they are on a search path.
2. Just knowing that a changed unit is used/compiled by a project is not sufficient proof that the binary is affected.

Before I begin writing some code to solve the problem I would like to ask the panel what suggestions they might have as to how to approach this.

The rules of StackOverflow forbid me to ask for recommended software, but if anyone has any positive experiences of continuous integration tools that would help - great

I am open to any suggestion or observation that is relevant in this context.

Answer 1

It seems to me that your question boils down to knowing which units are contained in your various executables. Since you are using search paths, it will be hard for you to work this out ahead of time. The most robust way to find out is to consult the .map file that the compiler emits. This contains a list of all units contained in your executable.

Once you know which units are contained in each executable, you need to know whether or not anything has changed in those units. That information is contained in your revision control system. Put this all together and you have the information that you need.

Of course, just because the source code for a unit has changed, you might argue that re-testing is not needed. Perhaps the only change made was the version, or the date in a copyright label or some such. But it is asking too much to be able to ask a computer to make such a judgement. At some point you need a human to step up and take responsibility.

What is odd about this though is that you are asking the question at all. It seems to me to be enormously risky to attempt partial testing. I cannot understand why you don't simply retest the entire product.