Best practice for managing large numbers of BE and FE libraries with separate versioning

[Trey Hecht]

We have a setup internally where we have built a large number of libraries that are in-use by our client-facing applications 20-30 for the backend and 5-10 for the frontend.

Currently, all of the issues for these are stored in a single umbrella project. This causes issues with understanding which release certain issues were completed in. I'm trying to understand what the best practice for this sort of thing would be. Should I be creating individual projects for each library and manage their issues and releases there? Should I create smaller buckets for FE and BE libraries and manage the releases with labels and components?

If anyone has any similar experience with the issue it would be appreciated to understand how others are doing it.

[Nic Brough -Adaptavist-]

I think we need to know a bit more about what you mean by library, BE, FE, and your product(s).  We can't really talk about structures without a broad understanding how those things interact.

[Trey Hecht]

So, we have around 14 "products" that are client facing that our customers purchase. Each of these has their own Jira project and works well.

The issue that I am running into is that our core platform team builds libraries for both backend (Java) and frontend (JavaScript) that our product teams use. Each library has its own versioning and release process and we are struggling with the best way to track releases for each library. Some of the solutions that I can think of are:

• Having a Libraries project and just managing each library release there (lib1-1.0.0, lib2-1.2.3, etc.), but this would cause us to lose reporting capabilities like earliestUnreleasedVersion()
• Creating individual projects for each library and having the releases managed there, but this comes with issues for the product teams knowing which project to route tickets to among other things.

Examples would be a backend library that contains all our of base functionality, one for handling messaging from one microservice to another, one for access, etc. On the frontend side, some examples would be one for all of our shared UI components, one for our common UI functionalty (session management, etc.), and one for developer experience and efficiency.

[Nic Brough -Adaptavist-]

>Each library has its own versioning and release process

That pretty much tells me each library should have its own project.  I don't think your product teams should struggle with where to place issues - "I need library X to do something" or "I found a bug in library X" - it goes in the project for library X