How do you maintain a common library used by different clients?

Question

I am part of a software deveopment team. Originally there were just 2 of us, and two applications. To ease our job we create a set of libraries, handling stuff like GUI, database access, calculation, business rules etc, so that we can reuse them in our applications without implementing them twice.

Now the team grew, 6 people and ~5 applications (and growing). The applications use the same library, which are great because we don't have to develop and maintain the same thing more than once. I and the other initial guy developed and are mostly responsible for the library, but other people have access to the code and occasionally update it to fix bugs and add improvements.

But soon we notice that the more we grow and the more people can modify the code, there is a risk that "improvements"/"bug fixes" that someone does can unintentionally break someone else's application which depends on the old behavior. On the other hand, assigning one guy to maintain the libraries and make sure modifications won't break anything is not practical because there are many applications, and possibly many improvement requests to be done, and he can't be sure of everything either.

How do teams normally manage situation like this? Perhaps by implementing rules on allowed modification? Defining behaviours that shouldn't be changed? There are a lot of libraries in the internet used by a lot of people, for example open-source/free to use libraries like Apache, Castle, etc. How do they make sure that changes won't break existing client codes?

Answer 1

You create a public API and version it. The consumers ( the other projects ) get to follow the API and you get to unit test it thoroughly.

Also it is a good practice to do code reviews. They should be done by you and the other core developer whenever something is about to change in your common library code.

Before any changes are to be included either you or the other core developer must sign off the code. Then and only then should the change be merged into the trunk.

Be careful of changes that break unit tests on the public side of the api, in that case you should change the api's version. A good idea is to follow semantic versioning like it is suggested in the comments.

Be strict about this.

Answer 2

I suggest that you add unit tests for this shared library. This will help you decide on the expected behavior and will alert you if this behavior ever changes due to a bug fix or a code improvement/refactor. I would not worry too much about different applications that use the library expecting different behavior from it if you spend the time to clearly define what that behavior is.

Answer 3

I like Thanos' answer. Additionally, at my work, we use git repositories to manage our code libraries. It puts the code under version control, essentially, so that if damaging changes are ever made and pushed out to everyone else, it's easy to roll it back, find the problem, fix it, and re-deploy.

But, fortunately, it will detect conflicts, or collisions in modified files, for you so that you can review each change (called the "delta") as it goes up to the repo.

To know more, you'd like Pro Git, which is free to read online.