What's the best way to manage dependencies between versions of separate components?

Question

I ran into this problem at my old job, and now again at my present one, which means I either have extremely bad luck, or am not aware of some tool or organizational system which can solve this problem.

In both situations, the end product was comprised of several independent components, each of which communicated through an agreed interface with its neighbors. The problem is that over time, the interface will change, and then the respective components must also be updated so that everything keeps working.

That in itself is not a problem. The problem is that this makes bug tracking extremely difficult when trying to go back in the SCM history, because at some point, the component you are trying to debug will no longer be compatible with the other parts of the system and cannot be tested against them without also rolling them back.

Take the following example:

1. Say we have a client/server product, and for simplicity's sake, both start out in a fully-working state. We'll call these versions client-1.0 and server-1.0.
2. After some amount of time, bugfixes and features are made to both. Now we're at client-1.7 and server-1.2.
3. Now the interface changes in the server, so the client must also change: server-2.0 and client-1.8.
4. Now with the client at version 1.9, a bug is found, and we want to test the previous versions to see where it stopped working with the server. However, if we go back past 1.8, then the server must also be reverted.

The example scenario I give is extremely simplified, but the question boils down to this: what's the best way to enforce which versions of the client and server are compatible with each other?

I have considered doing this through documentation, but inevitably, human nature will triumph and somebody forgets to update them for either their or the other component. I also thought about doing it by having matching versions (ie, when server hits 2.0, client also gets promoted), but the problem is that the client may have other component dependencies which are unrelated to the server, so it doesn't make sense to update their versions across the board.

There has got to be some solution for solving this problem. Does anybody have any suggestions, or starting points for my research?

Answer 1

You have to setup an historized meta-label (a label referencing other labels)

It can be done either:

• through meta-data within your SCM (SVN for instance does keep an history on its metadata as well as its data)
• or through an external database registering the list of all labels currently tested and validated as "working together" (provided that list is historized as well)

The historization nature of that meta label ensure you to be able to revert to a previous coherent set of labels in order to debug a system.

Whatever solution you choose, do not forget that, once delivered in a production environment:

• you do not have your SCM in that production environment
• hence you must rely on a text file reminding you of the exact labels deployed.

That text file should be automatically generated when you build the delivery package (set of files you will deploy into production)

Answer 2

You don't seem to have a problem managing dependencies, you have a problem regressing.

Interfaces take care of dependancy abstraction, unit-tests and nightly builds take care of change control.

If you need to test a historical release, you need to be able to get that labelled version from your source repository and deploy it in a replicated, but quite separate environment. Thus this is a matter of defining release labels metadata in the the SCM and having the spare/dedicated hardware.

Answer 3

I don't know what language platform you have used, i.e., Java, C, etc. But here is some related info which makes my life easy in java.

There is a build tool called Maven which I use for my Java applications. Maven have clear dependency configuration. For example

client-1.0 depends on server-1.0 - when you will see the client-1.0 config you will notice it needs server-1.0 client-1.7 depends on server-1.2 client-1.8 depends on server-2.0 client-1.9 depends on server-2.0

Each and every version you have released will be available in your maven repository. If I want to test client-1.7 I will simply take that from repository and from the config I know it needs server-1.2 which is also available in repository. I will start my application and test.