Skip to content

Commit 67af9da

Browse files
docs: add a release process document
This is based on the process followed to create the recent release and should serve as a guide in case someone else does a future release. Signed-off-by: John Mulligan <[email protected]>
1 parent d3873ad commit 67af9da

File tree

1 file changed

+186
-0
lines changed

1 file changed

+186
-0
lines changed

docs/release-process.md

Lines changed: 186 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,186 @@
1+
# samba-operator Release Process
2+
3+
## Preparation
4+
5+
The samba-operator project has a dedicated branch, called `release`, for
6+
release versions. This is done to update files, in particular the tags of the
7+
default containers in `internal/conf`, that control dependencies. Tags are
8+
applied directly to this branch and only this branch.
9+
10+
11+
Prior to tagging, we must update the `release` branch to "contain" all the
12+
latest changes from the `master` branch. We do this by merging `master` into
13+
`release`.
14+
Example:
15+
16+
```
17+
git checkout master
18+
git pull --ff-only
19+
git checkout release
20+
git pull --ff-only
21+
git merge master
22+
# resolve any conflicts
23+
```
24+
25+
Now we need to update the versions of the containers that the operator deploys
26+
by default. Edit `internal/conf/config.go` to update the versions of
27+
the samba-server, samba-metrics, and svcwatch containers if there are new
28+
released versions for these images.
29+
30+
> [!IMPORTANT]
31+
> The projects that the samba-operator includes/depends on must be released
32+
> *before* the samba-operator. As a policy the "SINK" team releases the projects
33+
> as a group. See the section below for guidance with regards to these projects
34+
> and version numbers.
35+
36+
The direct dependencies of the samba-operator are container images from the
37+
samba-container, svcwatch, and smbmetrics projects. These projects also have
38+
dependencies. The resulting recommended release order for these projects are:
39+
1 [sambacc](https://github.com/samba-in-kubernetes/sambacc) - a dependency of samba-container
40+
2 [samba-container](https://github.com/samba-in-kubernetes/samba-container) - a dependency of samba-operator and smbmetrics
41+
3 [smbmetrics](https://github.com/samba-in-kubernetes/smbmetrics) - a dependency of samba-operator
42+
4 [svcwatch](https://github.com/samba-in-kubernetes/svcwatch) - a dependency of samba-operator
43+
5 samba-operator
44+
45+
When selecting a project for release, if we plan on releasing operator v0.6 we
46+
first release, for example, samba-containers v0.6, and so on. If a project is
47+
unchanged we do not need to make a release and the older version number will
48+
continue to be used. If we do need to make a release that was not part of the
49+
previous group we may *skip* version numbers. For example if component X was
50+
released as v0.3 in along with samba-operator v0.3 but was unchanged for
51+
operator v0.4 we would release it as v0.5 along with samba-operator v0.5 if a
52+
release is needed for that project.
53+
54+
Once the dependency image tags have been updated, commit the change. For example:
55+
```
56+
git commit -s -p -m 'release: use v0.5 tag for samba-server and samba-metrics images'
57+
```
58+
59+
Run `git push` to push the change to the release branch on GitHub, initiating
60+
a CI test run. Verify the release branch build passes the tests.
61+
62+
In the meantime, edit the file `config/manager/manager.yaml` to bump up
63+
the version of the operator image tag (to match the upcoming tag). This file
64+
is used when deploying the operator and must be configured to deploy
65+
the intended release version. Commit the change with a command like so:
66+
```
67+
git commit -s -p -m 'release: use v0.5 tag for samba-operator by default'
68+
```
69+
70+
### Tagging
71+
72+
Assuming the CI has passed the tests, apply a new tag to the `release` branch:
73+
```
74+
git tag -a -m 'Release v0.5' v0.5
75+
```
76+
77+
This creates an annotated tag. Release tags must be annotated tags.
78+
79+
### Build
80+
81+
With the tag recorded in git we can now build the final image for this release.
82+
This tag and the corresponding hash will be recorded in the binary that is
83+
built.
84+
85+
It is very important to ensure that base images are up-to-date.
86+
You can either purge your local system of cached container images or
87+
inspect the `Dockerfile` and purge or explicitly pull each base image.
88+
89+
Run `make image-build`.
90+
91+
Verify that the tag was properly recorded by the binary in the container.
92+
* Run `podman run --rm -it quay.io/samba.org/samba-operator:latest`
93+
* The operator will fail to start because it is not running in Kubernetes.
94+
However, all you need to verify is that the first log line, with
95+
"Initializing Manager", contains JSON values that have the correct tag in the
96+
"Version" field.
97+
98+
99+
For the image that was just built, apply a temporary pre-release tag
100+
to it. Example:
101+
```
102+
podman tag quay.io/samba.org/samba-operator:{latest,v0.5pre1}
103+
```
104+
105+
Log into quay.io. Push the images to quay.io using the temporary tag. Example:
106+
```
107+
podman push quay.io/samba.org/samba-operator:{latest,v0.5pre1}
108+
```
109+
110+
Wait for the security scan to complete. There shouldn't be any issues if you
111+
properly updated the base images before building. If there are issues and you
112+
are sure you used the newest base images, check the base images on quay.io and
113+
make sure that the number of issues are identical. The security scan can take
114+
some time, while it runs you may want to do other things.
115+
116+
117+
## GitHub Release
118+
119+
When you are satisfied that the tagged version is suitable for release, you
120+
can push the tag to the public repo:
121+
```
122+
git push --follow-tags
123+
```
124+
125+
Draft a new set of release notes. Select the recently pushed tag. Start with
126+
the auto-generated release notes from GitHub (activate the `Generate release
127+
notes` button/link). Add an introductory section (see previous notes for an
128+
example). Add a "Highlights" section if there are any notable features or fixes
129+
in the release. The Highlights section can be skipped if the content of the
130+
release is unremarkable (e.g. few changes occurred since the previous release).
131+
132+
Each release provides a YAML file that can be used to deploy the operator
133+
on a Kubernetes cluster. Generate this file by running:
134+
```
135+
# replace example version with correct version number
136+
kustomize build config/default/ > samba-operator-v0.5-default.yaml
137+
```
138+
139+
Prepare a "downloads" section for the release notes.
140+
Use the following partial snippet as an example. The container details must
141+
reference the image that was pushed to quay.io in an earlier step.
142+
```
143+
## Download
144+
145+
The samba-operator image can be acquired from the quay.io image registry:
146+
147+
* By tag: quay.io/samba.org/samba-operator:v0.5
148+
* By digest: quay.io/samba.org/samba-operator@sha256:040307f53c3f3fd6a5935306f9898858b6c46b7e9c2ae46244e79c2bc42fef0d
149+
150+
### Deploying the operator
151+
152+
This operator can be deployed using the example file samba-operator-v0.5-default.yaml file, attached to this release. Example:
153+
154+
kubectl apply -f samba-operator-v0.5-default.yaml
155+
156+
This is equivalent to checking out the v0.5 tag from the git repository and using the default configuration. Example:
157+
158+
git clone -b v0.5 https://github.com/samba-in-kubernetes/samba-operator
159+
cd samba-operator
160+
kubectl apply -k config/default
161+
162+
```
163+
164+
The tag is pretty obvious - it should match the image tag (minus any pre-release
165+
marker). You can get the digest from the tag using the quay.io UI (do not use
166+
any local digest hashes). Click on the SHA256 link and then copy the full
167+
manifest hash using the UI widget that appears.
168+
169+
Update the "Deploying the operator" section to use the correct version number
170+
and ensure that the YAML file is uploaded to GitHub.
171+
172+
Perform a final round of reviews, as needed, for the release notes and then
173+
publish the release.
174+
175+
Once the release notes are drafted and then either immediately before or after
176+
publishing them, use the quay.io UI to copy each pre-release tag to the "latest"
177+
tag and a final "vX.Y" tag. Delete the temporary pre-release tags using the
178+
quay.io UI as they are no longer needed.
179+
180+
181+
## Announcements
182+
183+
As the samba-operator is typically the final release in the group of "SINK"
184+
projects that are released now is a good time to announce the releases.
185+
Currently the team sends email to the `samba` and `samba-technical` lists at
186+
lists.samba.org. See the list archives for previous examples.

0 commit comments

Comments
 (0)