CI/CD Pipelines for https://github.com/thanos-io/thanos/
Understanding the continuous integration and deployment processes used in Thanos, including automated testing, building, and deployment.
What is CI/CD Pipelines?
CI/CD pipelines refer to the continuous integration and continuous delivery processes used in software development. In the context of the Thanos project, these pipelines automate the building, testing, and deployment of new releases.
Why is CI/CD Pipelines important?
CI/CD pipelines are essential for maintaining a stable and reliable software project. They enable regular and automatic builds, ensuring that any changes made to the codebase are tested and validated before being released. This helps to catch and address issues early, reducing the risk of introducing bugs or regressions into the production environment.
Insights
Thanos follows a regular release schedule, aiming for one release every six weeks. The project uses a release shepherd for each minor release, who is responsible for performing the releases and announcing them on all communication channels.
The following table lists the most recent releases, their first release candidate dates, and the corresponding release shepherds.
| Release | Time of first RC | Shepherd (GitHub handle) |
|---|---|---|
| v0.34.0 | 2024.01.14 | @MichaHoffmann |
| v0.33.0 | 2023.10.24 | @MichaHoffmann |
| v0.32.0 | 2023.08.23 | @saswatamcode |
| v0.31.0 | 2023.03.23 | @fpetkovski |
| v0.30.0 | 2022.12.21 | @bwplotka |
| v0.29.0 | 2022.10.21 | @GiedriusS |
| v0.28.0 | 2022.08.22 | @yeya24 |
| v0.27.0 | 2022.06.21 | @wiardvanrij and @matej-g |
| v0.26.0 | 2022.04.29 | @wiardvanrij |
| v0.25.0 | 2022.03.01 | @bwplotka and @matej-g |
| v0.24.0 | 2021.12.22 | @squat |
| v0.23.0 | 2021.09.02 | @bwplotka |
| v0.22.0 | 2021.07.06 | @GiedriusS |
| v0.21.0 | 2021.05.28 | @metalmatze and @onprem |
| v0.20.0 | 2021.04.23 | @kakkoyun |
| v0.19.0 | 2021.03.02 | @bwplotka |
| v0.18.0 | 2021.01.06 | @squat |
| v0.17.0 | 2020.11.18 | @metalmatze |
| v0.16.0 | 2020.10.26 | @bwplotka |
| v0.15.0 | 2020.08.12 | @kakkoyun |
| v0.14.0 | 2020.07.10 | @kakkoyun |
| v0.13.0 | 2020.05.13 | @bwplotka |
| v0.12.0 | 2020.04.15 | @squat |
| v0.11.0 | 2020.02.19 | @metalmatze |
| v0.10.0 | 2020.01.08 | @GiedriusS |
| v0.9.0 | 2019.11.26 | @bwplotka |
| v0.8.0 | 2019.10.09 | @bwplotka |
| v0.7.0 | 2019.08.28 | @domgreen |
| v0.6.0 | 2019.07.12 | @GiedriusS |
| v0.5.0 | 2019.06.31 | @bwplotka |
Thanos participates in various mentoring programs, including LFX Mentorship, Google Summer of Code, and Red Hat Beyond, to foster community growth and development. Follow us on Twitter https://twitter.com/ThanosMetrics for updates on application processes and announcements.
Creating a new release
To create a new release, follow these steps:
- Create a branch based on the release branch. You will use this branch to include any changes that need to happen as a part of ‘cutting’ the release.
git checkout <release-branch>
git checkout -b <your-branch-name>
Update the CHANGELOG file. Note that
CHANGELOG.mdshould only document changes relevant to users of Thanos, including external API changes, bug fixes, performance improvements, and new features. Do not document changes of internal interfaces, code refactorings and clean-ups, changes to the build process, etc. Format is described inCHANGELOG.md.Double check and update the CHANGELOG file.
a. Check for backward compatibility:
i. For versions after
v1+.y.z, double check if none of the changes break API compatibility. This should be done in PR review process, but double check is good to have.ii. For
v0.y.z, document all incompatibilities in changelog.b. Double check metric changes:
i. Note any changes in the changelog.
ii. If there were any changes, update the relevant alerting rules and/or dashboards since
thanos-mixinis part of the repository now.c. (Applies only to minor, non-
rcrelease) Update website’s hugo.yaml to have correct links for new release (add0.y.z: "/:sections/:filename.md").d. (Applies only to minor, non-
rcrelease) Update tutorials:i. Update the Thanos version used in the tutorials manifests to use the latest version.
ii. In case of any breaking changes or necessary updates, adjust the manifests so the tutorial stays up to date.
iii. Update the scripts/quickstart.sh script if needed.
Set the version in
VERSIONto reflect the tag you are going to make.Open a PR with any changes resulting from the previous steps against the release branch and ask the maintainers to review it.
For more information, refer to the following resources:
- Getting Started
- Design
- [Blog posts](docs/getting-started.md
