Product Release and Support Strategy for Software-as-a-Service
The Release strategy for our Software-as-a-Service solutions ensures continues support.
In addition to the normal service packs, security fixes and patch versions will be provided as required.
The Update process is completely automated including all agents, and customers can change the schedule of the update process within certain boundaries.
Upgrades are communicated to the General- Notifications/Reports contacts in the SaaS portal and made available on the dashboard.
Version Numbering
A version numbering is as follows <year>.<service_pack>.<patch_level>.<hotfix>.
| Service Pack/Update | Patch Level/Patch | Hotfixes | |
|---|---|---|---|
| Description | A new service pack may include both product enhancements and fixes. Redwood provides service packs for active major versions on a quarterly basis. | A patch includes only corrections to reported issues. Patches are made available for all service packs in the production phase as required. They don’t follow a regular schedule. more details | Hotfixes are incremental and not always publicly released. |
| Example Version change | 2023.2 to 2023.3 | 2023.3.0 to 2023.3.1 | 2023.3.0.1 |
End-of-maintenance (EOM)
The end-of-maintenance date is defined as the point at which the software will no longer receive updates or bug fixes, but support will still be available to users. End-of-life happens 12 months after the release date, and notifications will be sent to users before that date.
Updates or patches for software applications that have reached their end-of-maintenance date will no longer be provided.
End-of-life (EOL) or End-of-support (EOS)
The end-of-support date is defined as the point at which the software will no longer be supported, and no further updates or bug fixes will be provided. End-of-support happens 18 months after the end-of-maintenance date as described in the documentation at the time of the release.
Planning Service Packs
Up to four service packs can be released every year.
- After a release is made available the upgrade is planned per environment with an option to change
- Development 1 week after release (ability to postpone 1 week)
- Test 2 weeks after release(ability to postpone 1 week)
- Production 4 weeks after release(ability to postpone 2 weeks)
- It is always possible to perform an update earlier than planned
Planning Finance Automation Service Packs
Figure 3: Redwood Finance Automation release planning
Planning RunMyJobs Service Packs
Figure 4: RunMyJobs release planning
Planning Patches
Figure 5: Patch planning
Environment administrators can set a patch window (day + time) for non-production and production
- Non-production will be done in the 1st week after release (no later than 7 days after release)
- There will then always be a 7-day period before production can be patched
- Production will then be scheduled at the next configured day/time (no later than 21 days after release)
Released patches will automatically roll out at the selected patch windows
Additionally, Redwood will have to do mandatory maintenance on the infrastructure, these do not contain product updates but might require a restart at a day/time defined by Redwood. This will be announced via message of the day and email.
important
Patches consist of only bug fixes and/or security updates and are crucial to ensure the security and stability of the Redwood SaaS platform.
tip
For Finance Automation environments you get the option to skip non-critical patches.
Update Process per Instance
Figure 6: Update process
FAQ
Q1: Do I need to stop my Queues before an update?
A1: almost all Definition Types are resilient to system restarts. Only JDBC and Webservice calls are synchronous. RedwoodScript is by default also synchronous, but can be made resilient with the jcsJobContext.becomeResilient api call. So only for those processes you should stop the respective queues in order to ensure that they do continue automatically after the update.
Q2: Are there other manual activities that need to take place after an update?
A1: There are no technical manual activities required. It is advised to validate the working of all components in the non-prod environments after an update to prevent surprises during the production update.
cloudTopic