Releases in Ultralight
Managing software releases for medical devices presents unique challenges due to the critical nature of healthcare technology. The stakes are incredibly high - software bugs or inconsistencies could directly impact patient safety and treatment outcomes.
Regulatory requirements from bodies like the FDA add layers of complexity, demanding rigorous documentation, validation, and traceability for every software change. This makes the release process significantly more involved than software development in less-regulated domains.
A robust release management system is essential to navigate these challenges, ensuring that all changes are properly tracked, validated, and compliant with regulatory standards while maintaining the rapid deployment capabilities needed for modern software development.
See the Software Parts documentation for more.
Release
A Release is responsible for compiling documentation and orchestrating a production release for a suite of Software Part Versions.
A Release can be linked to Change Orders (COs), and closure of those COs will gate closure of the Release.
Software Part Versions can be added to the Release for traceability, and Technical Approval of those SW Part Versions will also gate closure of the Release.
Workflow Diagram
Setup Steps
Within Ultralight
Follow the setup guide
The goal with configuring your Software Part Version form is for you to specify the fields that every software part should have. For example, potential fields could be a “release tag”, “change impact” etc
Within your VCS (GitHub, GitLab etc)
In your VCS, set up the Ultralight GitHub Action/CLI to trigger in a manner that supports your existing workflow.
The GitHub Action/CLI will allow you to pass parameters (e.g. which software parts are being updated, which Release the Pull Request is related to) to the GitHub Action or CLI via the Pull Request Description
Run npx ultralight-core --help on how to use the CLI, or the GitHub Action documentation on how to use the GitHub Action.
Ongoing Workflow
1. Create Release
Create a Release in Ultralight.
You can fill out the Release Form and link COs in parallel with Step 2, below.
2. Create/Update Pull Request
Create a pull request. Populate the PR description with the Release(s) that should track these changes, and SW Part(s) that are being changed.
SW Part Versions will be automatically created for the SW Parts that were mentioned in the PR Description, and will be added to the Release(s).
As the PR is updated, the latest commit hash will be updated in Ultralight, and changes to the PR Description will also modify the relevant Release and SW Parts/Versions.
3. Finalize Release Documentation
Get Approvals for the SW Part Versions in the Release.
A future enhancement will allow approvals from your VCS to substitute for in-app Approval.
Complete COs in Release.
Complete Release Form.
4. Merge PRs
[Optional] You can set up a merge block as part of your CI to ensure that required documentation is complete before merging a PR.
To ensure that Ultralight captures each PR in a tracked repository, a PR will be blocked from merging if it is not included in at least one SW Part Version in at least one Release.
By default, a PR can merge if
All SW Part Versions that contain the PR have been approved
At least one Release containing the PR is ready to be closed (i.e. Release Form complete, COs complete, SW Part Versions with Approval)
The default merge block behavior will be circumventable with PR-specific flags included in the PR description. There will be flags to:
Only require the software part version to be approved in-app in Ultralight (no checks on the Release status)
Skip the approval on the Software Part Version altogether (to be used sparingly)
[Else]
Just merge the PR!
5. Close Release
Close Release, Release and included SW Part Versions become immutable.
Voila! You’re all done
You can use previously released SW Part Versions in subsequent Releases, but will not have to go through the Technical Approval process for those previously released versions.