Multiple apps with common code -- how to approach this?

Question

My company has two or three web apps that use a lot of common code -- a custom MVC framework, utility classes, JavaScript libraries, and so on.

We'd prefer not to duplicate all this code in each app, because we end up with several slightly different versions of it in use. But we don't want the apps to require the same exact copy of this code, because we don't want an update to one app to potentially break another.

Does anyone have any tips on dealing with this problem? I don't think I'm looking for a technical answer -- more of just a general approach.

We could make the code into a library, and allow apps to remain on an older version of the library until they're ready to upgrade. Or we could make it into multiple libraries, so we don't have to upgrade everything at once. But would it become difficult to manage the interdependencies between versions of the libraries?

Answer 1

I use SVN with svn:externals. Things you want to be stable should be in the tags folder so dependent projects don't get affected by other developments in the trunk.

Answer 2

It depends on many, many factors -- different languages have different behaviors with regards to libraries. The way I generally handle this is to have each app have a battery of tests for its external dependencies, including libraries that I've written, and to use this to keep upgrades to said libraries from breaking the app.

Any more details regarding the platform you're using? There may be specific tools that will help with your particular needs.

Answer 3

I second the SVN with svn:externals. We have a client and server that share some code. The code is maintained under the server (but could be moved out to its own repo) and the client pulls it in with svn:externals. The client trunk pulls from server trunk. But when we branch (say for release) then we peg the pulled in external at a specific rev, branch or tag. If you don't do that and you go back to an old branch and update, you may get the trunk of the shared code, which is most likely not what you want.

Answer 4

I would create one source control branch for the common code representing the latest and greatest version.

Then for each project have your own independent branch of that code where you can make quick fixes where needed or have stability when close to a release.

You may want to have a Wiki where bugs found in the common code are listed so the other users of the shared code are aware of it and get time to fix it at their leisure.

Git would work well for this since it is good at merging changes back to the 'master' branch.