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:
- 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.
- 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.
Thanks in advance.