I am a software developer in a company who has been active for more than 40 years in B2B product development and I would like to get some advice regarding the situation I'm facing on a day-to-day basis.
The company I'm working for has actually two very active software development team: one of them is making R&D while the second one is managing production software. As new products are released, code from the R&D is transferred to production. Same when new features are required. Up to here, nothing strange.
The problem comes from the CI/CD aspects. To speed up the development process, the production team pulls code from the R&D way before any maturity is achieved and then complains when changes are introduced as the project gains in maturity.
This is emphasized even more by the fact that the R&D team has a lot of freedom and the production team applies an extremely rigid methodology. R&D side, new concepts and features are often added which result in libraries that are somewhat close to a "perpetual beta" way of doing with older concept being more stable/mature while newer concepts are often refactored with loss of retrocompatibility. Production side, they want full retrocompatibility with all products sold in the past and use a test-driven development approach. This ends up with code with literally hundreds of thousands of if-then-else statements because unit tests written 30 years ago on interfaces definitions are still enforced.
While I'm clearly not a big fan of the production approach used, I understand that having software in perpetual development is not necessarily compatible with retrocompatibility considerations which are also important.
My question is: how do you handle fast iterative development in a context where retrocompatibility is of uttermost priority ? Is maintaining white-box (code's internals) testing viable over time or should we focus only on maintaining black-box tests (i.e. only maintain input -> output tests but not details on how the code is actually implemented) ?