For deployment it is called via helmfile in combination with helm-diff to present the to be applied changes to the user. For instructions on how to deploy services and configuration changes with helmfile, see Deployments on kubernetes.
Testing a new version
If you are wondering "How do I test a new helm version before reaching production", one possible strategy could be to do the following:
1) Start working locally, importing the new version and building the new Debian package.
2) Install it, and test helm with Minikube (for example, try helm lint, helm template, helm upgrade, etc.. on some charts in operations/deployment-charts).
3) If the results are good, proceed with importing/installing/publishing on deneb/apt1001 and upgrade CI to use the new helm version (see below how to do it).
4) If CI runs fine (that involves using helm lint on all charts for example), proceed with deploying helm3 more widely (check https://debmonitor.wikimedia.org/ for more info about where to the package is installed).
Importing a new version
The packages are build using Git-buildpackage. The imported upstream tarballs should include the complete vendor directory.
- Check out the version (git tag) to import
- This drops you into a shell with the git tag checked out. Do necessary changes here and commit
glide install --strip-vendor # or go mod vendor git add -f vendor # git diff --name-status --cached | grep -v 'vendor/' # to make sure you only changed vendor git commit -m "added vendor"
- Exiting the shell will build a tarball to import
gbp import-orig /path/to/tarball.tar.xz
- Push changes (including the tag crated by gpb) to gerrit
git push gerrit --all git push gerrit --tags
- Add a debian/changelog entry (as CR)
gbp dch # Edit debian/changelog git commit git review
Building a new version
- Check out the git repo on the build host
- Build the package
BACKPORTS=yes gbp buildpackage --git-pbuilder --git-no-pbuilder-autoconf --git-dist=buster -sa -uc -us
Publish a new version
# on apt1001 rsync -vaz deneb.codfw.wmnet::pbuilder-result/buster-amd64/*<PACKAGE VERSION>* . sudo -i reprepro -C main include buster-wikimedia /path/to/<PACKAGE>.changes # Check where the package is in reprepro sudo -i reprepro lsbycomponent helm3 # Copy the package over to other distros (this is possible because they only contain static binaries) sudo -i reprepro copy stretch-wikimedia buster-wikimedia <PACKAGE> sudo -i reprepro copy jessie-wikimedia buster-wikimedia <PACKAGE>
Update CI image
We're using helm/helmfile in operations/deployment-charts to lint and verify charts.
To update the envoy version used there, bump the changelog at dockerfiles/helm-linter/changelog:
dch -D wikimedia --force-distribution -c changelog
And add the new version to
jjb/operations-misc.yaml in a second patch (example)
When this is merged and build, run CI (maybe just rebuild last at https://integration.wikimedia.org/ci/job/helm-lint/ ?) to verify the new version against our charts/deployments.