|Number of votes:||4|
Every now and then I see the claim that Episerver releases product updates every two weeks. This isn't quite correct, and the truth is even better: We release updates every week!
This is probably nothing new for anyone who updates frequently and sees the new versions pop up on the NuGet feed. But since the two week misconception pops up again and again I wanted to set it straight.
I don't know where this claim originally came from, the article outlining our continuous release process, posted years ago, mentions weekly updates. But with a little detail on how we work you will see where the two weeks are in the process, possibly giving rise to this misconception.
We have a continuously running planning process where we research and design features, triage bugs and reprioritize the development backlog. The dev teams pick features/bugs from the backlog and implement/fix them. Automated builds, tests and metrics continuously run on the code being committed. Our QA teams pick up and verfy the built packages give thumbs up/down for release.
Because of the high level of automation, the cadence of this dev-QA-release pipeline is only limited by the time it takes to develop something, perform any manual verification necessary, and smoke test the package as a whole for side-effects. However, for the sake of completeness and consistency (and frankly, sanity) we do not pass every package built from development to QA. Instead, we aggregate the features and fixes completed within a week and branch off a release candidate (prerelease) which QA go on to verify. With the release window coming up once a week, this on average gives QA one week to verify the package and for dev to fix any issues found by QA.
Here you have the two weeks - it is the "delay" from start of a development cycle to the first possible release window for that code after verification. But of course the dev team isn't idle while while QA are verifying a package. They are already working on the next set of features/fixes to be passed to QA the following week, which is why a new version of the same package can be released every week.
Finally, the delay for fixing a high priority bug can be even shorter as a fix can be developed and included late in the dev week, closing in on a one week round trip time.