|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:
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.
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.
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.
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:
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!
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!
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.
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:
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/