Hyperscience releases patch versions to provide application and security fixes for on-prem and SaaS instances. Applying these patches helps keep your instance secure, reliable, and up to date.
A patch applies targeted updates without moving your instance to another platform release or SaaS innovation release. For example, patching from v43.0.7 to v43.0.8 applies the fixes included in v43.0.8 without requiring you to update compatible flows or models.
This article explains the benefits of patching, when patches become available, what to consider before patching, and how to update your Hyperscience instances to a patch release version.
Benefits of patching
Patching can help you keep your instance healthy by:
Resolving or preventing known application issues.
Addressing security issues.
Improving application reliability.
Providing a more up-to-date baseline for troubleshooting.
Review the release notes before you apply a patch
They describe the included updates and identify any considerations for your instance, flows, or models. See relevant information for your instance version in Release Notes.
Patching by deployment type
The patching process differs for on-prem and SaaS instances. See the table below:
Deployment type | Patching managed by | Notes |
|---|---|---|
Customer | Hyperscience provides the approved patch Bundle, checksum, release notes, and supporting documentation. Your organization applies and validates the patch. Validate the flows and models used in critical business processes in your testing instance before patching your Production Instance. | |
Hyperscience | Hyperscience schedules and deploys all patches. See Patch a SaaS instance. |
Patching cadence
Hyperscience generally releases scheduled patches every three weeks. All patches undergo testing, security review, and approval before release.
Hyperscience may release off-cycle patches to address critical customer issues or security vulnerabilities. A patch already on the schedule may also ship earlier than planned when a critical issue requires it. Non-critical fixes normally follow the scheduled patch cadence.
The inclusion of a fix in a specific patch is not confirmed until Hyperscience finalizes the updates. Review the release notes for a complete list of the fixes included in each patch.
When an issue affects multiple supported versions, Hyperscience may include the fix in separate patches for those versions. Availability depends on the affected version, its support status, and whether the fix applies to that version.
Support and patch availability
Patch availability depends on your deployment type, the support status of your version, and the update included in the patch. To learn more, see Hyperscience Release Model.
Patch availability
Confirm patch availability with your Hyperscience representative before scheduling a production change. A scheduled date may change to accommodate a critical issue or release concern.
Patch a SaaS instance
Hyperscience manages patching for SaaS instances. You do not download patch bundles, schedule maintenance, or run any patching steps.
Hyperscience applies patches proactively during a dedicated maintenance window. Your testing and production instances are patched in the same window.
Patches typically do not require customer action or affect service availability. When a patch requires action from your team or affects availability, Hyperscience communicates the details through the established release notification process.
To see the fixes included in a patch applied to your instance, review the release notes for your version.
Contact your Hyperscience representative with questions about patch timing for your instance.
Patch an on-prem instance
The Hyperscience Application and Trainer come bundled in a single archive file named hyperscience-trainer-x.x.x.tgz, where x.x.x is the version number.
Patching follows the same steps as an upgrade
However, during patching, you do not need to upgrade your flows or retrain your models unless the release notes state otherwise.
Hyperscience Support provides the download link for the latest patch applicable to your instance in your Support ticket. Use the link in the ticket to download the approved patch bundle.
Patch bundles are cumulative. The latest patch contains the fixes included in the preceding patch versions for the same release. You do not need to apply each intermediate patch separately. For example, you can patch directly from v43.0.1 to v43.0.08 without applying v43.0.2 to v43.0.8 individually.
Review the release notes associated with the patch to confirm:
The target patch version.
The fixes included in the patch.
Compatibility considerations.
Required actions.
Contact Hyperscience Support if you are unsure which patch applies to your instance.
Patch the testing instance
Download the approved version bundle from the link in your Support ticket.
Expand the bundle in a dedicated folder.
Copy the
.envfile from the current version directory to the new version directory on each application machine.Run
run.sh initon one application machine.Run
run.shon all application machines.Complete the required trainer update. Follow the steps in the Upgrade the trainer section of the Technical Upgrade Instructions article.
Validate the testing instance
Confirm that:
The expected patch version is running.
All required services are healthy.
Users can access the application.
Critical flows and models operate as expected.
Required integrations operate as expected.
The issue addressed by the patch no longer occurs, if applicable.
Patch the production instance
After the testing instance passes validation, follow your organization’s change-management process and repeat the patching steps in the production instance.
Validate the production instance
Repeat the required health checks and business-process validation in the production instance. Delete the bundle after completing the validation.