Introduction to releases
Introduction to releases
All about our release notes, schedules, mechanisms and moreEVA comes with a lot of products, and not all products can be handled the same in terms of releases. In this document, we wil go over all of our release schedules, mechanisms and other important information.
Handling releases
We deliberately start with explaining how to handle releases, because this requires the most attention from a customer point of view. EVA has a lot of moving parts, and we always assume our customers fully adapt to any new version we release.
Web releases
Admin Suite, Return Portal, Digital Giftcard App, Admin 1.0.
We deploy new releases of our EVA Beyond (and by extension Main) web applications every 4 weeks. These don't have to be handled. We make sure these are updated ourselves, so these are always up-to-date.
App releases
POS, App Suite, CFD, Companion App, and the Suite Apps.
We deploy new releases of our applications every four weeks. These will show up automatically in your ABM where they are updated automatically or you do so manually, depending on your configuration. Read more about distributing apps in distributing Apps via ABM.
Backend (Core) releases
EVA Core. Technically to everything though.
We deploy a new version of EVA Core every single week. Yes, you read that right. Every week.
Although we aim to deploy our new Core versions to production environments on a predictable schedule, it's impossible to guarantee exact dates always. We value stability over speed, which means that if there's any uncertainty of a new version's impact, it won't be deployed yet. In general however, the Core drops are deployed on a pretty tight schedule.
Handling these releases isn't something you have to do when you strictly and exclusively use EVA applications. If your setup interacts with EVA Core directly however - regardless of its shape or form - then these releases should be closely monitored. Read more about this in our Core release docs.
Timeline of release cycles
Generally, we follow a four-week release cycle. This means we release a new Beyond version every four weeks, while bumping up the Main version to the previous Beyond version.
A cycle consists of 3 weeks of development and one week of internal testing and documentation, loosely followed by two weeks of customer QA.
For more information about Main and Beyond, see the following section Main, Beyond and URLs.
Weeks 1-3
The first three weeks of the release are exclusively reserved for development. During these three weeks we go nuts on the tickets that were prepared ahead of the release, to make sure we deliver them in a timely manner.
Week 4
Ahead of the fourth week, we have a release candidate for all our applications. This is however, an internal release candidate. During the fourth week, we extensively test our release candidates, while also documenting all of the changes we made.
Two weeks of customer QA
When the new Beyond version is approved by Apple, a two-week window starts during which customers can perform QA testing. Any non-critical bugs found will be fixed on the new Beyond version, while any critical bugs (if any) will be hotfixed on the current Beyond.
Overview
| When | What |
|---|---|
| Week 1 Monday | Start of new release cycle. |
| Week 3 Thursday | Cutoff for feature requests for next release cycle. |
| Week 3 Friday | New Black internal release candidate. |
| Week 4 | New Black internal acceptance testing. |
| Week 4 Friday | Version submitted to Apple for review. |
| Week 5 & 6 | Two weeks of customer QA on the new Beyond version |
As mentioned, we offer our new version to Apple for review the Friday during the internal regression week. This review can technically take up to two working days, which would result in you having your new versions available on Wednesday. Usually however, this review is passed by Monday.