icingadb/RELEASE.md

Release Workflow

Table of Content

• 1. Preparations
  • 1.1. Issues
  • 1.2. Backport Commits
  • 1.3. Authors
• 2. Version
• 3. Changelog
• 4. Git Tag
• 5. Package Builds
  • 5.1. RPM Packages
  • 5.2. DEB Packages
• 6. Build Server
• 7. Release Tests
• 8. GitHub Release
• 9. Chocolatey
• 10. Post Release
  • 10.1. Online Documentation
  • 10.2. Announcement
  • 10.3. Project Management

Preparations

Specify the release version.

VERSION=1.0.0

Add your signing key to your Git configuration file, if not already there.

vim $HOME/.gitconfig

[user]
        email = noah.hilverling@icinga.com
        name = Noah Hilverling
        signingKey = "CE23E835630F89D9"

Issues

Check issues at https://github.com/icinga/icingadb

Backport Commits

For minor versions you need to manually backports any and all commits from the master branch which should be part of this release.

Authors

Update the .mailmap and AUTHORS files:

git checkout master
git log --use-mailmap | grep '^Author:' | cut -f2- -d' ' | sort | uniq > AUTHORS

Version

Update the version in version.go

Changelog

Edit CHANGELOG.md, choose the most important issues and summarize them in multiple groups/paragraphs. Provide links to the mentioned issues/PRs. At the start include a link to the milestone's closed issues.

Git Tag

git commit -v -a -m "Release version $VERSION"

Create a signed tag (tags/v) on the master branch (for major releases) or the support branch (for minor releases).

git tag -s -m "Version $VERSION" v$VERSION

Push the tag:

git push origin tags/v$VERSION

For major releases: Create a new support branch:

git checkout master
git push

git checkout -b support/1.0
git push -u origin support/1.0

Package Builds

mkdir $HOME/projects/icinga/packaging
cd $HOME/projects/icinga/packaging

RPM Packages

git clone git@git.icinga.com:icinga/rpm-icingadb.git && cd rpm-icingadb

DEB Packages

git clone git@git.icinga.com:packaging/deb-icingadb.git && cd deb-icingadb

Branch Workflow

Checkout master and create a new branch.

• For releases use x.x as branch name (e.g. 1.0)
• For releases with revision use x.x.x-n (e.g. 1.0.0-1)

Switch Build Type

Edit file .gitlab-ci.yml and comment variable ICINGA_BUILD_TYPE out.

variables:
  ...
  #ICINGA_BUILD_TYPE: snapshot
  ...

Commit the change.

git commit -av -m "Switch build type for $VERSION-1"

RPM Release Preparations

Set the Version, revision and %changelog inside the spec file:

sed -i "s/Version:.*/Version:        $VERSION/g" icingadb.spec

vim icingadb.spec

%changelog
* Fri Mar 13 2020 Noah Hilverling <noah.hilverling@icinga.com> 1.0.0-1
- Release 1.0.1

DEB and Raspbian Release Preparations

Update file debian/changelog and add at the beginning:

icingadb (1.0.0-1) icinga; urgency=medium

  * Release 1.0.0

 -- Noah Hilverling <noah.hilverling@icinga.com>  Fri, 13 Mar 2020 10:50:31 +0100

Release Commit

Commit the changes and push the branch.

git commit -av -m "Release $VERSION-1"
git push origin 1.0

GitLab will now build snapshot packages based on the tag v1.0.0 of Icinga DB.

Package Tests

In order to test the created packages you can download a job's artifacts:

Visit git.icinga.com and navigate to the respective pipeline under CI / CD -> Pipelines.

There click on the job you want to download packages from.

The job's output appears. On the right-hand sidebar you can browse its artifacts.

Once there, navigate to build/RPMS/noarch where you'll find the packages.

Release Packages

To build release packages and upload them to packages.icinga.com tag the release commit and push it.

RPM/DEB:

git tag -s $VERSION-1 -m "Release v$VERSION-1"
git push origin $VERSION-1

Now cherry pick the release commit to master so that the changes are transferred back to it.

Attention: Only the release commit. NOT the one switching the build type!

Build Infrastructure

https://git.icinga.com/packaging/rpm-icingadb/pipelines https://git.icinga.com/packaging/deb-icingadb/pipelines

• Verify package build changes for this version.
• Test the snapshot packages for all distributions beforehand.

Once the release repository tags are pushed, release builds are triggered and automatically published to packages.icinga.com

GitHub Release

Create a new release for the newly created Git tag: https://github.com/icinga/icingadb/releases

Hint: Choose tags, pick one to edit and make this a release. You can also create a draft release.

The release body should contain a short changelog, with links into the roadmap, changelog and blogpost.

Post Release

Online Documentation

Only required for major releases.

Navigate to puppet-customer/icinga.git and do the following steps:

Testing

git checkout testing && git pull
vim files/var/www/docs/config/icingadb-latest.yml

git commit -av -m "icinga-web: Update docs for Icinga DB"

git push

SSH into the webserver and do a manual Puppet dry run with the testing environment.

puppet agent -t --environment testing --noop

Once succeeded, continue with production deployment.

Production

git checkout master && git pull
git merge testing
git push

SSH into the webserver and do a manual Puppet run from the production environment (default).

puppet agent -t

Manual Generation

SSH into the webserver or ask @bobapple.

cd /usr/local/icinga-docs-tools && ./build-docs.rb -c /var/www/docs/config/icingadb-latest.yml

Announcement

• Create a new blog post on icinga.com/blog including a featured image
• Create a release topic on community.icinga.com
• Release email to net-tech & team

Project Management

• Add new minor version on GitHub.