We have a centralised business application framework, and it contains all our business logic and provides access to all our back-end systems. It is accessed by a number of different programs and clients through remoting.

When we need to do a change in a certain part of the program, we currently have to retest all our different programs and clients. Even assuming we extend our automated testing, we feel that there is no way we can be certain that upon releasing a new version of our application framework all the different programs will work correctly after that change without also manually retesting all these programs.
Every time we release a new version of project C, we have to test program A and B as well for unintended changes.

Preferably, we would move to a release system where upon releasing project C, we only have to retest program C, and not A and B for possible breaking changes that we overlooked.

The idea lives to duplicate our centralised business application framework, one for each sub-project. It would mean for that when we release a new version of program C, we will provide a private version of the application framework. Upon release of program C, nothing will have changed for application A and B, they still communicate with their private application framework - so they do not need to be retested.

I came up with the following pro's and con's:

Con's:

We'll have our framework hosted n times for each project

We'll get confused in what version / project what bug is solved.

With a major fix / change, we will have to re-release all n versions of the application framework.

Pro's:

Significantly cuts down on testing

"Certainty" that no unintended changes are released for different projects.

I must admit I am not a fan of the private copies-approach, but I fail to provide a better alternative, or better arguments against this.

Has anyone been in a similar situation, and how was it handled? Is the above approach of "private frameworks copies" a solid / accepted approach? Any advice is welcomed.

1 Answer
1

Your framework, like any library code, should be a separate, versioned, project. And each app should be dependent upon a specific version of the framework.

Whenever you make changes to the framework, its version should change, and the new version should be made available in addition to the old version(s) still being available for the other apps.

You can then switch over each app as desired or needed to a new(er) version of your framework. And you can "decommission" a version when not a single app still has it as a dependency.

Yes, there will be duplication, but with a correct folder structure and some configuration in the apps the duplication can be limited to the deployed/deployable files. All other dupplication should be in your version control system (which I do hope you use...).

Just look at your framework as another framework like .Net. My hosting provider happily makes version 2.0, 3.5, 4.0 ... available and which one is used for my site is defined by a configuration setting which can be different from the configuration settings of any other sites hosted by the same server.

With regard to your con's:

I don't see multiple hosted versions as a problem. If anything it makes dependencies a lot more explicit and allows you to develop the framework with confidence.

Whether or not you get confused in what version/project a bug is fixed depends entirely on your bug tracking system. Plus the framework should be its own project. I didn't mention this above because to me it is so obvious that I didn't anticipate anybody having/changing it as part of another project.

Yep if a fix is important enough to be applied to older versions, you will indeed have to fix all previous (and following) releases. But that is a good thing. It will make you think twice about whether something is worhty of being "hot-fixed" (requiring changing all currently maintained releases) or just something that the other apps can get when they switch to a newer version of your framework.

Thanks, excellent points and comparison with different framework versions. I guess I didn't look at it that way because of it being exposed over remoting as services. It looked weird to me that we're actually exposing different versions of the same services, but if its accepted - great :-)
–
JonasSep 5 '11 at 11:41