In our work, we have several different .net applications that share a lot of base functionality. We've built these applications using a clean n-tier architecture, but we've hit that moment where we realize that we've re-implemented the same functions several different times. Obviously this violates DRY, and we would like to correct that. We're already using Nuget to some success for common glue code (wiring up IoC, logging, settings), but we also would like to share our data and business layers between all our applications. The idea is that the UI would only deal with the parts of the business layer it actually needs.
This seems like a straight-forward problem at first, but ongoing development could provide some pitfalls and we're not sure how to proceed. Let's say we make our One Business Layer to Rule Them All. For brevity, I'll call it "Foundation." We port our applications to use the Foundation, and everything is runnding great. The Foundation is distributed to light UI layers via nuget, and we're looking good. But then we start adding features to our applications, and we run into trouble.
Let's say we're working on Project A and we add a new feature that requires changes to Foundation. We make the changes to foundation (Foundation-A) and push them out to the nuget feed as an unstable package. Project A gets the latest nuget package, and all is good. Meanwhile, another developer is working on Project B. He gets the latest Foundation from source control, but takes it from a stable branch, so that it doesn't have Project A changes in it. He makes changes and created Foundation-B. And all is good. But then we discover that Foundation-A and Foundation-B implementation functionality that could actually share code, so we combine them. Meanwhile Foundation-C is floating out there with it's own changes. Eventually, Foundation-B is ready for production, so we push it out. But then we need to update Production A, B, & C with the new foundation, so we update the nuget packages and deploy (as long as nothing breaks).
This seems like it could work, but we're worried about working with different database schemas and keeping everything synchronized between the various branches of the Foundation repository as well as the Project A, B, and C repositories. It seems like it will probably take a lot of manual work, which opens up the possibility for errors. I would like this as automated as possible.
Here's the stack we're using: C#, TFS with Continuous Integration, Nuget. Our applications are all various types of ASP.NET applications. We're willing to look at different SCM's if it will make things easier.
I'm looking for ways to keep Nuget sane with our different source code branches. We don't want to accidentally push development code into production because we reference the wrong Nuget Package.