Implementing Continuous Integration with a volatile hierarchy of library dependencies

Question

Recently my company setup a build server using Bamboo and a private Nuget Feed which is populated by the successful builds being deployed from the build server.

There is a hierarchy of projects under heavy development setup for use in bamboo with a fairly simple, linear dependency graph. Before being setup on bamboo all devs had to clone the repository being worked on and all of its dependencies and make a new branch in each project. As almost all changes at this point are breaking changes, this was a bit of headache.

So now with the new tool of Bamboo in the mix, as a dev, what would my workflow look like if I needed to make some changes in Project A that will also require changes in Project C where Project B and C is dependent on A and C is also dependent on B.

  A
 | |
 | B
 | |
  C

I want to make certain all tests still pass in Project B after my changes to project A before moving on to make the changes in Project C. Are there any resources that help explain what developers workflow should be at this point? It seems he can either pull down, setup the dependencies manually and test B. Or he can setup special builds on Bamboo to handle the this intermediate state of the projects and then download the resulting nuget packages. I feel uneasy with that solution because it requires a deeper understanding by the devs of Bamboo and the build server (And I don't understand it all well at this point, to explain it all to them).

This problem compounds the more dependencies there become on a lower level library. Are there any resources that explain the accepted approach to this problem?

Answer 1

When you are working with multiple teams on multiple projects, you always had and will have most (if not all) of your troubles relating to interfacing between these projects. You can call it project/library/microservice/etc. - it's always the same as you describe. One team makes breaking changes, the other team(s) suffer.

As this problem is quite well-known, there is a simple acceptable path available. At least it's technically simple, but may involve office politics nevertheless. The basic idea is that you have clearly defined public interfaces and that a team must not make breaking changes in such an environment. Instead, your team is only allowed to break things via a standard deprecation mechanism.

In practice, this means that your outside interface of A must remain the same. This is more trouble for team A to somehow realize their change in a way that leaves the old A interface available and working as it used to. Essentially, this is the price that the company has to pay to ensure smooth operation of all other teams in presence of A's changes. A is, however, entitled to deprecate/version its interface in such a way that all other teams are informed that a certain functionality will be gone within X (this should be clear company-wide known time period. Can be days, weeks, or even months - depending on the agility of your teams).

After this period has elapsed, all other teams have had time to replace the outdated interface calls and team A is allowed to simply remove the deprecated part of the interface. Everything that breaks outside of A at that point is no longer considered team A's problem.

A best practice for working in such an environment is also for each dependency that your project has to setup a suite of tests, which ensures that a) you understand correctly how that interface is supposed to work and b) you immediately fail in case you missed the deprecation deadline and the interface is gone (as usual: fail fast is better).

Answer 2

Use a layered architecture. Place each project in a layer, where each project is dependent only on lower layer projects, so no lower layer project depends on a higher layer project. Without layers, the dependencies become unmanageable as the number of projects multiplies.

Once your architecture is layers, you test the lowest layers first, then the layer above, etc. This design has proven itself useful for decades.