Product Release and Support Strategy for Software-as-a-Service
The Release strategy for our Software-as-a-Service solutions ensures continues support.
Redwood provides at least one service pack update per year.
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 <major_version>.<minor_version>.<service_pack>.<patch_level>. For update schedules, only the <major_version>.<minor_version>.<service_pack> part is relevant.
Continuous Support
Redwood provides at least one service pack update per year. Redwood provides patches as it sees fit for stability of the environment. This ensures that you have continuous support and get the latest functionality.
Figure 1: Release Schedule
Planning Service Packs
Up to two service packs can be released every year.
Figure 2: Service Pack planning
- 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