Like many (most ?) people, we have multiple "common" libraries managing various things (business objects, utilities, external libraries...) for multiple projects (web service, admin/users site, desktop apps...).
As it's set up today, each project copies its binaries in an "assemblies" folder one level higher than the project, and they all reference binaries in this folder, rather than the project itself.
The SVN folders are a mess too, with common libraries in specific projects solutions, and services sometimes grouped, sometimes within their own folder.
Today, there is an incredibly complicated set of Jenkins jobs copying and using various projects outputs all over the place, with dependecies very hard to trace and often breaking : for instance, when I commit to the admin UI, it builds quickly, but fails because the web service hasn't finished building.
I see many problems with this organization ; among others :
- I have to respect a specific folder tree to be able to build a project, I can't just check out a single project and work on it.
- In order to build project A, I have to build project B, and before that project C, and so on and so forth. I can spend a lot of time finding out which project I'm missing to build the first one.
- The whole build configuration is stored in Jenkins, and developers do not have a direct access to it. So I cannot simply checkout a project I haven't touched before and build the whole dependency tree by running a script
I'm used to write large scripts that do everything, so It's driving me mad, but other developers are used to it, and just shrug their shoulders.
How do you configure your build system to handle your common and external libraries ?
(Update : we're using .Net, because apparently there are different solutions for different languages)
About dependency managers : nuget, npm, etc
We have thought about using an internal nuget server to store versioned DLLs, and use it to reference other projects.
The problem with this approach is the impact on the daily workflow.
Let's say I store my binaries in a nuget repository. And in order to make a new feature, I have to edit projects A, B and C. My workflow becomes a lot of waiting:
- I edit and commit project A.
- I wait for the A build to finish, and for the nuget feed to update
- I update my nuget package on B, edit, commit.
- I wait for the B build to finish, and for the nuget feed to update
- I update my nuget package on C, edit, commit.
- For my next feature, I must go back to step 1.
- Or, I code multiple features at once, and it's not very agile (and very risky).
This organization completely breaks the coding flow, and as such, is inacceptable.
Maybe I'm not thinking of the proper organization using a dependency manager? Maybe there's a better way?