This question already has an answer here:
Are there any industry standards or best practises on how to manage a rapidly changing code base?
The types of applications I am developing always have a custom aspect to them. So there will always be some code written which is client specific for every project.
The method we are using now is as follows:
Several 'CORE' projects exist in isolation from one another, each core project is a class library which is capable of running on its own, or with dependencies on other core modules.
All of these core modules are documented (Sandcastle) and NuGet packages created for them, which are served up via a private NuGet feed.
When a customer purchases the software we create a customer specific project which implements the bespoke code that they require, and pulls in the NuGet packages from the core libs as needed. The build of this project is what is provided to the customer, and each customer project has it's own Git repository.
This has worked fine for a year or so, but I feel that as we add features to the core libraries the number of nuget packages is growing quite quickly.
Is there a better method of organising code, whilst making sure there are not seperate version of the same code lying around?
I know in this stackoverflow post it states that:
Google manages to keep the source code of all its projects, over 2000, in a single code trunk containing hundreds of millions of code lines, with more than 5,000 developers accessing the same repository.
But this seems like it produce problems for us, due to having bespoke deployments.
Any ideas or comments on what I am doing wrong?
The problems I foresee going with the google way are mainly to do with release management and build issues. We use continuous integration, so that every commit a build will be triggered and test automatically run. If we use one all encompassing repo I am not sure what effect this will have on the build and test servers. Will it have to build every customers project?
Or would there be a branch per customer? In which case is this any better than a repo per customer?