We shipped a product. We then got a request to develop another product which would have its own release cycle. It was decided to start this development in the same branch as the first product we shipped, and use its core engine (with some changes to core required, and the rest written as 'extensions' mostly as separate assemblies). We then shipped this product.
At this junction, we would like to try to avoid breaking up the two products into their own development branches, and instead keep it all under same branch. In this sense, we would treat the core as an internal shared library to be consumed by the other products. Almost like a third-party library
Question 1: If we are currently developing ProductA, and need to make changes to the core engine for a new feature, do we also need to test ProductB at the same time in order to make sure no breaking changes have been made which negatively impact ProductB? Note that the two products may be in there own release cycles, however this does not mean that these cycles will not overlap in time.
I guess what I am trying to achieve is:
- Code re-use and some elegance to the design and architecture (instead of different full copies of the code with their own implementations)
- Do not branch if I do not have to
- Avoid a constant 'break-fix' cycle where making change to core breaks something for the 'other' product which we may not start on until months down the road. Finding it NOW will allow us to adjust the core so that it adapts to all other products that use it
Question 2 - Is it too much to ask that Test should treat the 'core' as a product in its own right? What types of test - basic 'smoke tests'? Integration? or should the full suite of Functional tests for each product be run each time a change to core is made?
Question 3 - Is this not something we should be asking of QA? Should this really be only handled by developers and THEIR tests (unit, maybe some integration tests)?