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.
Best Answer
Here's where your problem begins... Don't do that.
Any changes to Foundation v1.0 should inherently be valuable to all consumers of Foundation, otherwise it doesn't belong in Foundation. So, when creating the nuget package, do it as an official, stable version of Foundation (i.e. v1.1), or don't do it at all.
Project B should build its Foundation enhancements as it normally would, but (in good source management fashion) should merge in the trunk changes (v1.1) before pushing a stable Foundation (v1.2) to nuget.
Other projects which can use the Foundation enhancements can upgrade their nuget references when appropriate, or stick with the older versions if they need to.
I agree with @Giedrius; this seems to me to be more of a source control/branching issue in the sense that if the branching/merging of Foundation is handled properly, the package management issues become moot.