Managing Helm chart updates for self-hosted RPI v7 deployments

Overview

For self-hosted customers running RPI v7, we recommend a disciplined approach to managing updates to our published Helm charts. This ensures stability, clarity, and control over software version changes introduced through chart updates.

• Refer to our GitHub readme for more information about deploying RPI in Kubernetes using Helm.

• Refer to the RPI Admin Guide for additional information about deploying RPI.

• If you are upgrading from RPI v6.x to RPI v7.x, please refer to the Upgrade to RPI v7.x section.

Recommended update process

If you need to modify the official Helm chart to suit your environment (e.g., to support unique configuration constraints) we recommend that you follow this process:

1. Fork the Upstream Helm Chart Repository
   Clone and maintain a fork of our public Helm chart repository in your own Git environment. This allows for custom changes while keeping a clear path to integrate upstream updates.

2. Regularly Rebase Against Upstream
   Periodically, use git rebase to incorporate changes from the upstream chart into your fork. This is the primary mechanism to stay up to date with new releases and template updates.

Updates to the Helm chart typically include references to the latest version of the software; only accept image tag updates in alignment with organizational policies.

3. Review the Changes
   After rebasing, Kubernetes administrators should:

   • Review the output to understand what has changed in the deployment, particularly if core templates were modified.

   • Evaluate the implications of these changes for your environment. This step may reveal configuration shifts, deprecations, or newly required values.

   • Optionally use helm template to generate the rendered Kubernetes manifests from the updated chart.

4. Test in Lower Environments First
   Always apply changes in a non-production (e.g., staging) environment before promoting them to production. Perform smoke tests to ensure application behavior and infrastructure compatibility.

5. Promote to Production
   Once validated, apply the updated chart to your production environment.

Why git rebase?

Using git rebase (as opposed to merge) allows you to clearly track upstream changes and resolve conflicts in a controlled manner. This approach ensures a linear commit history and makes it easier to isolate and audit local modifications.

Understanding the impact of changes

While git rebase is the technical mechanism for consuming updates, understanding their implications requires human oversight. Not all changes are self-evident. Kubernetes administrators should review diffs during git rebase to understand the changes and use helm template for further analysis as needed. This step ensures that changes—especially those involving new image tags or core template logic—are fully understood before they reach production.

Best practices summary

1. Fork the upstream chart.

2. Rebase regularly.

3. Review changes with helm template.

4. Deploy to lower environments first.

5. Smoke test before production deployment.

6. Automate where appropriate, but keep human review in the loop.

We do not provide training on git rebase. It is assumed that teams managing Kubernetes infrastructure have the necessary Git proficiency. Refer to GitHub docs for details.