Appli rewrite & Big Bang Release
Hi,
In my company (large bank), we have some new projects which are good candidates for incremental release, but we also have some rewrite of old legacy junk.
In case of rewrite, what kind of pattern do you use to avoid Big Bang release after several quarters of work.
Yours
Olivier
Is the rewrite to be done from scratch, or is it a technical uplift of the existing legacy system? Also is there a legacy DB, the content or schema of which must be preserved?
Well, all the options are there, but I think mainly about rewrite from scratch and with a new DB (we will use some ETL to convert the datas)
Is it possible to rewrite components from scratch, and release them on a sprint by sprint basis? You'd need to discuss this with the PO to find out the business value of doing so, as well as finding out if it is architecturally possible. Standard GOF patterns such as bridge and adapter may be of use.
Is it possible to rewrite components from scratch, and release them on a sprint by sprint basis?
Well, it is actually my question ;-)
Sorry for not being clear enough. When I asked for patterns, I didn't have design-pattern in mind but instead organization -pattern or project-pattern.
The business value will be hard to define, but in term of risk-reduction and knowledge acquisition, the sprint by sprint releases are very useful.
I wonder how when can avoid big-bang production release. For instance, we can release in pre-production sprint by sprint, but is there a better solution ?
The distinction between production and pre-production environments doesn't have to be black-and-white. It may be possible to target early adopters for certain increments, or a similarly narrowed audience.
This is a Lean Startup technique which allows delivery risk to be sandboxed, while still permitting a degree of feedback and some measure of control over the accumulation of technical debt.