Views: 1957
Number of votes: 4
Average rating:

Episerver updates are released weekly

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.

Thanks for the reminder! I'm guilty of spreading that misconception - most notably here:

Don't quite know how I arrived at that - reading the update list from 2015 now, it's clear that UI and Core updates were released weekly even then.

I'll update my blog post, and will be sure to spread the good (correct!) word!

@Arild: I was certainly not out to point fingers in any direction. And it is not a big deal. I'm glad the information is correct in more places now, thanks!

@Kashif: I'm not familiar with the issue you link to but in general terms we always strive to reproduce the bugs we get reported in an automated test wherever possible, so that we can verify consistently that the bug is fixed and that it does not get reintroduced. We do this for performance issues as well. Still, for any of a number of reasons it might not be water tight.

I'll ping some people to get responses to your specific questions but I know some of the ones previously involved are still out of office for summer vacations (as am I), so you might not get a response immediately. Meanwhile I suggest you open a support case about the performance issue, making it possible for you to share copies of your database and code with our support engineers so we can reproduce your issues and figure out what the previous fixes are missing.

Please login to comment.