Give me Stable Releases Episerver
This is a request to take Episerver to the next level with stable releases.
Published 24th of February 2019
For +5 years now Episerver has embraced a continuous releases approach when releasing bug fixes and features, meaning releases coming once a week. This is great! The pros are obvious:
- Shortened time to market
- Features and fixes out as soon as they are ready
- Respond quicker to feedback
I´ve filed a dozen of bugs during the years, and when I get feedback just after a day that the bug fix will be released next Monday, I get really impressed. True story at its best.
Cons with Episerver Continuous Releases as it is now
When you have a major large solution – multisite CMS with Commerce – upgrading packages do almost always mean getting new bugs. And if you are fast on updates, you will most probably be the one debugging for hours and doing the job with/for Episerver developer support.
Before upgrading, you’ll need to take this into consideration:
- Upgrades are a risk
- How it will affect your solution
- What new bugs will we get
- Upgrades can be costly
- Customer frustration
I´ve been questioned by site owners and steering committees wondering if whether Episerver being the right system due to all the bugs. That bad!
Stable releases
Stable releases are releases that as far as possible doesn’t include bugs.
A stable release has been run usually in solutions as alpha and beta versions.
How to combine Continues Releases with Stable releases?
I do recommend my customers to update Epi Packages every three-four month because you don´t want/need to always be on latest version from a cost perspective nor be too far after.
But what if Episerver could pin-point some versions on their main product packages every year that will only get updated with bug fixes?
Example: Last versions before major versioning should always be upgraded with known bugs. And not features or major underlying hidden changes (cause it do happen, Episerver calls it “changes in internal apis”).
Meaning if version 12.18.2 is the latest version before 13.0 – if a bug exists and is found in 12, it should be fixed to that stable version. e.g. 12.18.3 and 13.0.1 and so forth until Episerver pin-points a new stable version, e.g. 13.6. And then probably the last version of 13.
This sure means Episerver needs to maintain two versions in their code base and Continuous Deployment/release life cycle. Some will say that is not possible, but the advantage will be greater and worth it in my honest opinion.
Advantages
- You would be confident going to a stable release
- Cost effective for customers
- Customer confident with Episerver being best choice
- Partners can focus on building awesome solutions and not debugging errors for Episerver
Make a difference – what’s your story?
The purpose with this blog post is to make an opinion and influence decision makers at Episerver. If you agree and have a story to tell, I’ve filed this as a feature request in Epi world forum, give a +1 or comment.
Read further
- https://world.episerver.com/articles/Items/EPiServer-Continuous-Release-Process/
- https://world.episerver.com/articles/Items/episerver-releases/
About the author
Luc Gosso
– Independent Senior Web Developer
working with Azure and Episerver
Twitter: @LucGosso
LinkedIn: linkedin.com/in/luc-gosso/
Github: github.com/lucgosso