Sharing code between solutions in TFS [closed]

问题:

I have a few different applications that i need to share code between to reduce maintenance. I have tried to read a lot on stackoverflow and the web in general and it is a fairly common problem; i have not found an answer i like.

Our TFS branching structure is like this. We have three branches Development, Main and Production. On the Development branch all active development is done, when we are done with developing new features, we merge it with Main, and then to production. The production branch is always the code running on the servers. If we detect bugs that must be fixed before the next iteration. The changes are done in main, and merged with Production as we deploy. The applications that need to share code do not share a common branching hierarchy or a common iteration schedule. In fact one of the applications only go through a 1month iteration once a year. (I know this differs slightly from the conventional way of doing it.

During my research i have found a few different solutions, but i have problems with all of them.

Binary sharing: One of the common ways i found was branching the compiled binary into the a folder beneath the development branch. My problem is that if we where to detect bugs in the shared code that must be fixed fast, the code in question is compiled. And if we where to fix the bugs we would get all the changes done to the shared code base.

Project sharing: My main problem here is how it can be done in an acceptable manner. My initial idea was to when a new iteration started, merge the changes from the main branch with the shared code to update it. Merge the main with the development branch to update the development branch with changes as a result of bugfixing. And branch new updates version of the shared code into the development branch. But from what i understand this is not supported by TFS because i would create nested branches.

My question is: How can i share a few common projects between solutions while keeping them in isolation and be able to fix bugs on the Main branch without worrying about the common projects having changed and therefor introducing new bugs. But still be able to fix bugs in the common project and merge those fixes back into the shared common projects.

回答1:

What I do is a version of what you called 'Binary sharing'. If you can think of your shared code as a 3rd party project, then you can apply the same rules for development that you would expect from a well run 3rd party project. That means that you should specifically version the shared code (with semVer or something similar) and maintain backwards compatibility wherever possible.

Yes, you are right, this means that if you find a bug in the shared code, you need to issue another version and then recompile the project that depends on this code.

However, it also means that if only one of the two projects dependent on the shared code needs the bug fix, only that project needs to take the new version.

Another benefit is that it is up to the project when to take the update. So you can manage the bug fixing process with more confidence.

So, to be clear, my suggestion would be to create a new TFS project for the shared code, give it all the love you would show to a 3rd party project (its own build, NuGet, etc), and then take a build assembly into a library folder for the projects that want to use it.

Hope this helps.

回答2:

Whilst the question isn't quite the same, I think that the answer maybe along the same lines as this one.

回答3:

Thank you everyone for all your help, because several of you contributed to my final solution iIhave chosen to post what I ended up doing here.

What I ended up doing was both Binary sharing and code sharing

For the projects that is often updated and with relatively fast iterations I referenced the shared projects I needed and created project guidelines to ensure that the code was backwards compatible for specific amount of time.

For the projects that was updated less frequently I branched in the compiled binary. I also created versioned the shared project and created guidelines to ensure that any backwards compatibility conflicting code resulted in an increment of the main component of the version number.