Users of the Spryker Commerce OS can already tell you a thing or two about what we call “Atomic Releases”. You may wonder, how can you make the most out of constant introduction of updates, and new features? Spryker’s Atomic Releases might just become your favorite, loyal companion on the road to happy customers and better shop performance.
A lot has already been said about this very Atomic Release Cycle. Spryker CTO, Fabian Wesner conducted a comparison between approaches to release cycles to help you gain an understanding of what makes Spryker’s release process different from the likes of IBM, SAP Hybris, Magento and OroCommerce. Does the technology serve you? Or are you a captive audience? The choice is either to get what you want when it is ready right away or be forced to wait for another party to finally release a feature you have long been waiting for. The price tag is the potential income lost waiting to get your hands on that feature.
Let's begin with what you can expect from us. We have a series of resources and methods we use to ensure that you, as a customer can smoothly update and benefit from new features and advancements. Each of the following points lean heavily on the principle of leveraging clarity, as a means to support releases.
- Clarity begins with strict semantic versioning. Semantic versioning helps you to predict the type, nature and compatibility of new upgrades to your project. Based on the version numbers, you can identify if a release is a feature or a patch. In rare cases where it is necessary, there are also backwards compatibility breaking releases which are a version that has incompatible API changes.
- Clear dependencies: All modules are clearly defined and have detailed required dependencies and constraints. Behind the scenes we constantly analyze and check dependencies to see how we can effectively keep dependencies at a minimum by merging, separating and creating connector modules when possible, without affecting the balance of the modules and maintaining compatibility with previous versions.
- Spryker Academy is updated almost every day. However, twice a month we issue a release update to the Spryker Academy where features are versioned and detailed release notes, migration guides, prepared scripts and suggested tools are created for the specific release to support a smooth and uneventful update.
- Professional community support. Our Forum is the intermediate step for getting live help and answers from Spryker developers and users. This is ideal in cases where releases are made available even before the information is in the academy. The Forum is also a useful resource for everyday issues and questions that may arise.
- We provide Unit, Functional and Acceptance tests for each separate module. The Spryker development environment is shipped with a test infrastructure. It helps projects keep tests updated, easily write, own and fully apply TDD (Test Driven Development) methodology.
- Security Releases: These are separate releases that have high importance. These releases are targeted towards resolving security vulnerabilities that our team has detected and solved. These releases require that you take immediate action in order to resolve the issue as soon as possible. We provide a separate dedicated mailing list for these releases. Make sure that your team subscribes to these mails with their company mail address as only customers can receive these emails.
Tips and Best Practices
Knowing what you have
Atomic Releases mean dependencies, so in many cases in order to work with a certain feature or functionality you need to use more than one module and share modules with others. To manage these dependencies we use the popular PHP dependency manager, Composer. To check what you have installed you can use the composer.lock file, which reflects the real status of your installation. During an update, you can generate a general composer output, which will tell you exactly, which versions have been installed or updated. Read more about this here.
Manage the updates, don’t leave it to updates to manage you
Properly managed updates mean that you have a strategy in place that complements the Atomic Release process. This strategy should naturally blend in with your company’s team processes and business requirements. From our experience it only requires consistency and minimal resources to make sure that the code is always up to date and free from instabilities and vulnerabilities. Ideally you should frequently check for updates but, in the real world, it is not always possible. Therefore, we recommend that you assign when planning at least one day a month for a developer maintained updates. A single day is enough to ensure that you incorporate all updates and security patches. Again, the more frequent you update, the better. Regularly checking our release notes (you can easily subscribe to them) will help you to understand which releases will bring business value to your company.
Keep your code lean
The first guideline is; keep your code lean. Know what you have and take what you need. Once you have taken a module keep on following the release notes for minor releases and patches and incorporate them once they come out. This method of continuous updates should help if not completely prevent the likelihood of incompatibility and breaks in your project.
To automatically take updates for modules that you are certain can be updated unequivocally, you can simply prefix the modules in the composer.json file with a ^ and they will be automatically updated with minors and patches.
Timing is everything here, and we have learnt that experienced teams will never take updates on the day of a release.
The only exception to this guideline is, if you have extended modules in your project. By overwriting classes that are behind the module’s API you have created your own modified version of the module that has not been pre-tested with the updates. This obviously is not an issue and just a scenario that should be handled differently. Our recommendation is to lock down to a specific minor version of the module. In this case use the tilde “~” instead of the caret “^” in your composer.json file for the extended modules. This way you protect yourself from automatically getting minor updates that could conflict with your extensions as we only guarantee compatibility with extended modules in patch releases. This way you will give you the time to evaluate the updates and make an informed decision based on the unique confines of your project, before you take the update.
If you want to lock-down a specific version of a module, just prefix it in the composer.json file with a ~.