AI OnAI Off
| Views: | 34858 |
| Number of votes: | 15 |
| Average rating: |
EPiServer Continuous Release Process
Jun 19, 2014
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.
Why?
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.
Versioning
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].[Minor].[Patch].[Build]
- 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".
Upgrade strategy
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.
Pre- production
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.
Post-production
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.
Pros
- 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.
Cons
- 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.
Pros
- 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.
Cons
- 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.
Documentation
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.
When?
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!
Comments
Please login to comment.
Good article and good to see that EPiServer is going the nuget and xcopy/webdeploy way so it is more inline with the way the .net world is heading is great!
But...
There is one major thing though that makes Continuous Integration and Continuous Deployment near impossible and that is your database schema upgrades. Requiring us to export some sql files and run a bat/exe deployment script to keep different environments up to date when we update the nuget packages is a complete disaster. These schema upgrades should be part of the EPiServer platform itself so it automatically upgrades to the schema version needed by the assemblies referenced through the nuget packages, just like the database updates itself with properties for pagetypes and commerce meta models.
As it is right now we have to extract the sql with Export-EPiUpdates and make custom upgrade code that runs before EPiServer starts (static constructor in global.asax for instance) that can keep the current platform updated. Manually updating the databases on all environments(prod,uat,test,qa and so on) and for each developer is a nightmare right now.
Fix this and we are setup for proper CI and CD and xcopy/webdeploy.
Excellent news.
However I agree 100% with Thomas. The database schema changes are a hassle. Next step should be to investigate how that can be streamlined more.
Thanks for your input!
We realize that supporting automatic schema udpate is something that will make life easier when doing continuous deployment and rest assured that our intent is to continuously improve the platform as well as the supporting tools. The first increments have been about making the entire platform releasable purely as NuGet packages which is where we are right now. Based on feedback (as in this case) we will decide where we go from here.
Automatic schema upgrades from code can be problematic, if you have accumulated lots of data, which could make the upgrade code timeout.
For example, some of the latest upgrades modify the DynamicDataStore, which depending on your application could be small or huge.
It would still be necessary to have the manual upgrade option, if for some reason you cannot use the automatic.
When(/if) we introduce automatic schema updates that will not be at the cost of manual upgrades. We need to support both in that case. As I said automatic upgrades can simplify continuous deployment considerably and that is something we want to promote. However, there will always(?) be situations where manual upgrades are prefered/required and we will continue to support that.
I've published a blog post on how to include these schema changes as part of your automated deployment process:
http://robertlinde.se/post/episerver-sql-scripts-and-continuous-integration-with-octopus-deploy
I have upgraded a commerce site from 7.5 to 7.9.0 It is still in development. You can find my experience http://world.episerver.com/Blogs/K-Khan-/Dates/2014/7/EPiServer-Commerce-Upgrade-strategy-in-light-of-ECRP/