EPiServer Continuous Release Process
|Number of votes:||15|
The market moves at Internet speed and we know how important it is for our customers to be able to get results quickly from their online business. Agility is a cornerstone in our business value, and as a result, we have now entered a new era for our delivery processes and shifted to something that we call continuous release process.
Our vision is to deliver updates to our main products as well as deploying updates to our multi-tenant services on a weekly basis. The updates will include both fixes and new features and the result is a radically shortened time to market. I think the benefits are apparent, both for partners that get access to new improved versions immediately, and for customers that can add new functionality to their solutions as they hit the market.
We simply want to add customer value faster, and by continuously delivering small incremental improvements we can:
- Get new features and fixes out as soon as they are ready.
- Respond quicker to feedback from our user and developer community.
In the past, our timeframe for new feature releases in core products could have been one year or longer. This meant that on average, a new feature was queued 6 months, which is not really "Internet speed". As you know, this meant a lot of code in different parts of the system was added or changed during this time, which inevitably lead to a full regression QA round. We will continue with regression tests (more automated and less manual) to ensure high quality software, but we will now pull in new features and fixes while managing to a reasonable development/QA ratio.
Deployment and delivery
For our hosted services like EPiServer Find, the updates will be deployed in our multi-tenant environments and will not require any extra effort from partners and customers. For on-premise software, all updates will be delivered as NuGet packages via nuget.episerver.com. You may have already seen releases that we have made so far during 2014. If not, I encourage you to have a look at the releases here.
We are moving towards a simplified Xcopy deployment and away from MSI-based installation. This is already available for EPiServer CMS (see update 16 – New Visual Studio Extension) and will be available for EPiServer Commerce in the near future. Until it is available, you will need to run the initial setup via Deployment Center when installing EPiServer Commerce.
Our vision is that our partners and customers, should be able upgrade to the latest version at any point in time. We have included setup and upgrade support in every weekly NuGet delivery to support this process.
We understand the importance of ensuring that you can track what you download and which version you are using. We will follow the industry standard of semantic versioning according to semver.org to handle dependencies in the NuGet packages.
- Major – incompatible API changes
- Minor – added functionality in a backwards-compatible manner
- Patch – backwards-compatible bug fixes
- Build – incremental build number within the version
It is important to mention that incompatible changes that comes with a major version will be documented to guide affected development projects to take the right course of action. Also worth mentioning is that the change itself may be small and have no impact on your solution. Note that version numbers will only have a technical meaning, for instance "EPiServer.CMS.Core 8.x.x" should not be compared to marketing names like "EPiServer 7" or "EPiServer 7.5".
The upgrade strategy for a solution should be agreed between the partner, taking the customer's goals and needs into consideration. However, from our perspective, we want to deliver maximum value for the software subscription by releasing platform features and fixes as frequent as possible. At the end of the day, the customers' willingness to upgrade the EPiServer platform in production environments is due to our success in continuously deliver software that adds business value. We have outlined some scenarios and recommendations on deployment strategies below.
For ongoing development projects we recommend always integrating updates as they become available on nuget.episerver.com. This will ensure that when the site is ready to be deployed to acceptance test/production, the site is running on the latest versions of the EPiServer platform.
After the site is live in a production environment we see two main upgrade strategies described below.
1. Continuous deployment approach
This approach will get the maximum benefit from the continuous release process by having access to new features and fixes as soon as they become available. It will require you to have full or partial automation of the entire deployment chain to be successful.
- Features and fixes are available to the customer as soon as they are released.
- Any non-backwards compatible changes (major versions) will in most cases be fairly small in each increment and therefore easy to manage.
- No additional process is required for maintenance as fixes are continuously deployed.The packages are cumulative, meaning you may skip s few updates without needing to backtrack.
- The customer UAT (User Acceptance Testing) process may not be aligned with a continuous deployment approach.
2. Traditional deployment approach
This approach leaves the upgrade frequency of the EPiServer platform entirely up to the partner or customer and is probably driven by specific feature and fixes wanted or needed by the customer. Each upgrade is treated as a traditional upgrade project. As mentioned above, the EPiServer update packages are cumulative, but the longer you wait between upgrades, the more likely it is that major changes have been introduced, which mayresult in a larger upgrade project similar to previous platform releases.
A separate maintenance strategy for the EPiServer platform is needed for the traditional deployment approach, as fixes are not continuously deployed to production. If an issue is found and verified in the EPiServer platform, you should do the following:
- Upgrade your staging environment to the latest minor version within the same major version to see if the issue has been resolved in a later minor version.
- If the issue is not resolved, you may browse the release notes and see if the issue has been resolved in a later major version. If so, go through the change log up to that version and consider whether an upgrade is a reasonable effort.
- If the upgrade is considered to be too big or the issue hasn't been resolved in any update, you may contact support for a possible workaround.
- If no workaround is applicable, you may request a hotfix within your current major version which will be triaged by the development team. There are mainly two criteria for approving or declining a hotfix: 1) The actual impact for the customer and 2) identified regression issues for the fix. If the hotfix is declined, the issue will be treated as a bug that will be prioritized for the next update.
- The strategy is likely to be similar to how you are maintaining an EPiServer solution today, and hence does not require any changes in deployment processes or tools.
- Upgrades of the EPiServer platform are seldom done which over time might include many incompatible changes, and will thus become a larger upgrade project (similar to previous platform releases from EPiServer).
- The customer is not able to take advantage of new features in the platform as quickly as in the continuous deployment approach.
Release notes for the most recent and previous updates can be found in the Release note section on EPiServer World. The SDK will be continuously updated within minor versions, where new features are tagged with the version in which they appeared. A new SDK version will be added for every major version.
We have already started the continuous release process. Since the EPiServer 7.5 release, we have released 20 updates. Please visit the Releases section on EPiServer World to check it out!