Skip to main content

Release Process

info

For Gitflow & Versioning, refer to its respective page.

Once the approved changes on the main branch are synced to the HP Telvie repository, the following step is to trigger the Azure pipelines to both generate the msix files and deploy the web changes to its respective URL.

info

The Github action that syncs Accedo repo to HP repo can also be fired manually

MSIX build

A new MSIX build is needed when the app had any Electron changes (any files from the electron/ folder) or any build/native app configuration changes

In addition to generate the MSIX, this new electron version needs to be added in Control, along with its checksum. Otherwise, attempting to open the application will end up in a corrupted error modal.

Please refer to the Integrity documentation for this.

Azure pipelines

The HPTV+ Pipeline will generate msix builds with the given environment.

Succesful jobs will upload the MSIX file in a Sharepoint folder. The file name will list the version and environment to avoid confusion.

Distribution

In addition to uploading the MSIX files in Sharepoint, since most of the team does not have access to that folder, we upload the files in drive. The Confluence page contains the link and changelog of electron changes.

Web deployments

A new deployment is needed when the app had any web changes (any files from the elevate/ folder).

Azure pipelines

There is one pipeline per environment, for each HP managed environments (ITG, STG, Production). You can trigger each of them depending on the environment desired.

info

Once the pipeline finishes, it takes ~5 minutes to see the changes reflected.

Castlabs Electron Fork

This project uses the Castlabs Electron for Content Security (ECS) fork instead of the official Electron package. This fork includes built-in support for Widevine DRM, which is required for playback of protected content.

Why Castlabs Instead of Official Electron

The official Electron build does not include Widevine CDM support out of the box, making it unsuitable for applications that need to play DRM-protected content. The Castlabs fork addresses this by:

  • Pre-integrating Widevine CDM support
  • Providing VMP (Verified Media Path) signing capabilities through EVS
  • Handling the legal requirement that Widevine CDM must be downloaded dynamically at runtime

The dependency is configured in electron/package.json:

"electron": "github:castlabs/electron-releases#v39.2.7+wvcus"

Version Lag Implications

Castlabs releases typically lag one to two minor versions behind the official Electron releases. This has the following implications:

  • Chromium Version: The embedded Chromium engine will also be behind the latest stable release. This may affect:

    • Access to the newest web APIs
    • CSS feature support
    • JavaScript engine optimizations
    • Security patches (though critical security fixes are typically backported)
  • Electron Features: Newer Electron APIs and bug fixes may not be immediately available

  • Node.js Version: The bundled Node.js version in the main process may also lag behind

Periodic Update Task

Keeping Electron updated should be treated as a recurring maintenance task. Recommended practices:

  1. Monitor Castlabs Releases: Periodically check the castlabs/electron-releases repository for new versions

  2. Review Changelogs: When a new Castlabs release is available, review both:

  3. Update Process:

    • Update the version tag in electron/package.json
    • Test DRM playback functionality
    • Verify VMP signing still works
    • Update electron-edge-js if required (must match Electron major version)
    • Run full regression testing

When updating Electron, ensure compatibility with:

  • electron-edge-js: Must match the Electron major version (e.g., Electron 39.x requires electron-edge-js 39.x)
  • @electron/packager: May need updates for newer Electron versions
  • @electron/rebuild: Required for native module compatibility