Using private NuGet repository and Jenkins to handle dependencies

Question

I am experimenting with using a private NuGet repository and jenkins to deal with dependencies.

Let's say we have exe A and libraries B,C and D.

Exe A depends on library B which depends on C and D.

On push of code changes to B,C or D jenkins builds and publishes a separate NuGet package for B,C and D to our private repository. All well and good.

I would like to be able to have any changes pushed to C trigger a nuget update and build of B and then A.

The problem is is that the nuget update causes edits of the packages.config file in the dependent project. This change happens in the jenkins workspace for that project.

This edit, in my mind, should be pushed to the SCM. Which would then cause a jenkins build ad infinitum.

So:

A: Am I doing it right?

B: Is there a way for this to work?

Answer 1

I would like to be able to have any changes pushed to C trigger a nuget update and build of B and then A.

I wouldn't.

When you change C, you shouldn't care about B or A, since those are not your dependencies. This way, you know for sure that no matter what changes you bring to C, every other project which relies on C will still continue to work.

If, later, developers (including yourself) who work on B decide that they want to benefit from the new features provided by the newer version of C, then it's their job to update the version of their dependency. This way, they know exactly that, for instance, moving from 4.0.13 to 4.0.14 led a given integration test to fail.

There are four problems with your approach:

• It doesn't scale. Yes, it might work on a tiny project where A depends on B which depends on C and D. With four components, it could be usable. But what if you have two hundred components, and you're modifying a core library on which virtually every other piece of software relies?

• It's counter-intuitive. You have to know your dependencies, not who depends on you.

• It makes it virtually impossible to make large-scale changes. Imagine that instead of moving from 4.0.13 to 4.0.14, you're moving from 4.0.13 to 5.0.0, while rewriting half of the interfaces. The next time you make a commit, a few thousand tests fail simultaneously, and every other developer stares at you waiting for you to fix that ASAP.

• It introduces a useless distinction between the private and the public packages. Do you think that developers of Entity Framework or Json.NET would also fix your code which is not compatible with their latest changes?