The challenges of major releases and how we tackle them

Fabian Wesner
Fabian Wesner CTO Spryker
15. February 2017 in

Technology English

Customers are often reluctant to accept major releases as they indicate that an impactful change has occurred. According to Semantic Versioning, a major release is issued for BC (backwards compatibility) changes. In other words, implementing a major release forces customers into an unpredictable situation to plan. The upgrade effort may take 5 minutes or 5 days and it is very hard to estimate what the scope will be and when it will happen. BC breaking changes can have very tiny causes like small changes to the database, APIs or even translations can necessitate a major release. We can avoid BC breaking changes with workarounds and we usually do. However, over time these workarounds introduce redundant and unclean code into our code base.

This is why we introduced Atomic Releases as a concept  –  to find a better way to handle BC issues. The purpose of the Atomic Release concept is to gradually introduce change and only release changes to components that were actually modified. This also helps us prevent amassing changes till we are ready, allowing us to share advancements with our customers as soon as they are ready to be used. We release frequent small releases only to a part of our Core platform. Therefore, only parts of the system increment in version while the others stay the same. For example, when we release a new version of the CMS bundle, you immediately know what functionality has changed. We also update the dependant bundles if they changed too. This way, you have all the information necessary to decide if you need that update or not. You will not have to update the entire platform to implement the change and also, if you do not work with the CMS functionality, you can avoid updating entirely.

The result is a working environment that helps you not only avoid unnecessary work, but also facilitates the decision making process by indicating which functionality has changed and what needs to be updated, allowing you to control if, what and when to update.

On the other hand, upgrading to a major release must be a conscious decision and should, at the proper timing for the customer be done manually. In some cases, frequent releases can be perceived as overwhelming. A possible cause could be that release integration efforts are not always factored into project scoping, causing surprises that disrupt the project timeline. On the other hand, stockpiling changes into quarterly or bi-annually releases only results in new features waiting till the next release window comes along.

Subsequently, we devised two solutions to allow organizations more flexibility with their upgrade choices:

  1. Integration estimates for major releases.
  2. Horizontal builds. 

Integration estimates for major releases

Semantic versioning consists of patches, minor and major releases. However, internally we also distinguish between mini-major releases (~ little integration effort) and a maxi-major releases (~ higher integration effort). A typical mini-major release needs one to two hours of work, e.g. an entry into a configuration file. Whereas a maxi-major release may take up a couple of days of work to implement e.g. when data migration is necessary. When implementing a release on the customer side, only maxi-majors have an impact on work plans, which is why presenting an effort estimation can help understand the implications. This enables customers to make an informed decision when deciding if the benefit of integrating the feature is greater than the effort. As mentioned above, major releases usually consist of optional improvements. Security patches are delivered on-demand and retroactively for older versions, therefore there is no added effort to be taken into consideration.

 

Horizontal Builds

In some cases, we have the flexibility to decide between adding a new feature to a bundle or creating a new separate bundle. The distinction can be made based on the impact the change will have on an existing work environment.

For example, adding the Customer Group feature to the Customer Bundle necessitates adding a new database table to “Customer-Groups”. As its a database change it constitutes creating a major release, even if the actual upgrade only requires minimal effort. To avoid releasing major versions for small changes, when possible, we create and release a new bundle, in this case the CustomerGroupBundle to externally extend the “Customer Bundle” functionally.

The following diagrams visualise the difference between releasing a major version as opposed to releasing a minor version and an additional New bundle that helps us maintain a minor release for the original bundle.

 
 

In terms of perception, introducing change using minor releases and adding bundles is easier to accept even when in some cases the effort implementing the change is the same.

We at Spryker are committed to creating a partnership with our customers where we constantly grow and evolve together. Feel free to tell us what you think by sending your feedback.

Still got questions?
Ask the author for further information.