トップ > Ansible > Ansible Collectionメンテナの日常(リリース編)

Ansible Collectionメンテナの日常(リリース編)

Ansible

みなさん今日もメリークリスマス｡昨日に引き続きRed Hatのさいとうです｡Ansible Advent Calendar 2024の､12月5日の記事をお届けします｡

ansible.posix collection version 2.0.0 をリリースしました

僕はサポートチームに所属していますが､表の仕事の障害解析の合間にアップストリームのメンテナの仕事もしています｡こういう境遇の人をRed Hatではよく見かけます｡

Red Hatは､一般社会的には謎に包まれているとはいえオープンソースソフトウェアカンパニーですから､所属している部門や､就いている職種にかかわらず､アップストリームへの貢献が自由として認められています｡日常業務とアップストリームの仕事をどのようにバランスするかという点については､ある程度は当人にまかされているとはいえ､ちゃんと表の仕事もしないといけません｡僕の場合は､表の仕事がAnsible Automation Platformの障害解析､アップストリームのメンテナのほうが裏の仕事という感じです｡

そんな裏の仕事で､さきほど(2024年12月5日)､Ansible Collectionの1つである､ansible.posixのバージョン2.0.0をリリースしました｡

今日は､昨日の投稿で､アップスチームへのコードコミットにチャレンジしようと思ってくれたあなたのために､知っておいてもきっと損はしないAnsible Collectionのリリースプロセスについてご紹介しようと思います｡

Ansible Collectionのリリースタイミング

Ansible Collectionのリリースタイミングは､基本的にメンテナの判断にまかされています｡Ansible Coreとリポジトリが分けられたのも､メンテナの都合で自由にリリースできるようにしようという配慮からです｡そのような背景から､数多くあるAnsible Collectionには､それぞれ独自のリリースポリシーがあります｡ここから先は､ansible.posixコレクションの場合のお話です｡

ansible.posixコレクションの場合は､現状だと年に1回や半年にに1回といった定期的なリリースは行っておらず､いい感じにマージされたPull Requestが溜まってきたタイミングで､アクティブなメンテナ間で話しあってリリース時期を決めています｡決定したら､リリース日とバージョンを含めて以下のIssueで広く伝えられます｡

希に､不適切なバージョニングなどの理由で､Ansible Communityから修正したリリースを求められる場合もあります｡この場合は緊急リリースとなります｡僕は2回ほど経験しました｡

バージョニング

バージョンについては､昔はフンイキで決めていた(当時もバージョニングの理由はそれなりにありました)のですが､現在では以下のガイドラインに従っています｡

これに従わない異端なAnsible Collectionは､Ansible community packageから除外されて､広義のAnsible(※1)には収録されなくなります｡どの世界でも異端児は住みにくい世の中ですが､最終的にこのようなガイドラインがあることで､メンテナの仕事がやりやすくなり､またAnsible Communityによるガバナンスが効くことで品質の高いリリースに繋がり､最終的に利用者がハッピーになっているように感じます｡

いま､Ansible Collectionを使っていてあまり幸せじゃないひとがいたら､このガイドラインがなければもっと幸せじゃなかったはずです｡いや本当に｡

※1:狭義のAnsibleはAnsible Coreです

リリース前日までの準備

リリース日とバージョンが決まれば､あとはそれにしたがってプロセスを淡々と進めることになります｡

  • メジャーリリースの場合: 昨日の記事で紹介したbreaking_changesとremoved_featuresをできるだけ詰め込まないといけませんから､マージ前のPull Requestのオーナーに必用な修正をお願いしたり､レビュアのchange requestに反応がないけど重要なPRをメンテナが強制的に修正してマージしたりして進めていきます｡間に合わなければ､次のメジャーバージョンアップまで積み残すことになるからです｡
  • マイナーリリースの場合: マイナーバージョンアップはゆるゆると準備できます｡よほど重要だったり深刻だったりするbugfixesã‚„minor_changes以外は積み残しても､次回のマイナーリリースはいつでもできます｡

リリース前日

リリースを担当するメンテナは､以下の流れでリリースコミットを作成します｡以下は僕の作業手順ですが､きっともっとかっこいい方法があるはず｡

1. changelog fragmentsからCHANGELOG.rstを生成するためのantsibull-changelogコマンドをインストールする

antsibull-changelogはchangelog fragmentsからCHANGELOGを生成してくれるイカしたやつです｡

% pip install --user antsibull-changelog
2. ローカルにリリース用のPull Requestを作成するための作業用ブランチを作成する

アップストリームのansible.posixをforkしてチェックアウトし､リリース用のローカルブランチ(release_2.0.0)を作ります｡

% git checkout -b release_2.0.0
3. galaxy.ymlのversionをリリースバージョンに変更する

Ansible Collectionのバージョンは､リポジトリのトップレベルディレクトリにあるgalaxy.ymlで定義されています｡これをリリースするバージョンに変更します｡

---
namespace: ansible
name: posix
version: 2.0.0   # <= ここ
readme: README.md
authors:
  - Ansible (github.com/ansible)
description: Ansible Collection targeting POSIX and POSIX-ish platforms.
license_file: COPYING
tags: [posix, networking, shell, unix]
dependencies: {}
repository: https://github.com/ansible-collections/ansible.posix
documentation: https://docs.ansible.com/ansible/latest/collections/ansible/posix/
homepage: https://github.com/ansible-collections/ansible.posix
issues: https://github.com/ansible-collections/ansible.posix
4. リリースコミット用のchangelog fragmentファイルを作成する

antsibull-changelogコマンドで生成されるCHANGELOG.rstとchangelogs/changelog.yamlに､これからリリースする2.0.0のエントリを追加するために､fragmentファイル(changelogs/fragments/2.0.0.yml)を作成します｡内容は以下のような感じのリリースの概要説明文です｡

release_summary: |-
  This is the major release of the ``ansible.posix`` collection.
  This changelog contains all changes to the modules and plugins
  in this collection that have been added after the release of
  ``ansible.posix`` 1.6.2
5. CHANGELOGを生成する

antsibull-changelogコマンドを実行します｡

% antsibull-changelog release --reload-plugins

このコマンドは､changelogs/fragments/ディレクトリ配下にある全てのfragmentファイルを削除して､以下の2つのファイルを生成します｡

  • CHANGELOG.rst
  • changelogs/changelog.yaml

これが､このリリースのCHANGELOGとなって､みなさんに見える形になるわけです｡

CHANGELOGの生成時にchangelogs/fragments/ディレクトリ以下にあるfragmentファイル群を削除してくれるので､リポジトリとしてはchangelog fragmentsが綺麗な状態で次のリリースを迎えられます(※2)｡なかなか便利でよくできてる｡

※2:このクリーニングの設定はchangelogs/config.ymlでkeep_fragments: falseとなっていれば有効化されています｡

6. リリースコミットを作ってpush!

リリースコミットを作って､Upstreamからforkしたoriginにpushします｡

% git remote -v
origin  [email protected]:saito-hideki/ansible.posix.git (fetch)
origin  [email protected]:saito-hideki/ansible.posix.git (push)
upstream        [email protected]:ansible-collections/ansible.posix.git (fetch)
upstream        [email protected]:ansible-collections/ansible.posix.git (push)
% git commit -a -m "Release 2.0.0 commit" --signoff
% git push origin release_2.0.0
7. リリースコミットのPull Requestを作成する

pushしたら､Draft Pull Requestを作って､自動テストがひと回りして成功するのを待ちます｡この待ち時間は結構気持ち的に落ち着かない｡

無事に自動テストが通ったら､Ready for reviewをポチッとして､僕以外のアクティブなメンテナを指定してReview Requestを送ります｡2人以上のApproveが貰えたらマージプロセスに入ります(俺的ルール)｡

8. リリースコミットのマージ

ansible.posixコレクションのマージプロセスは､特にややこしいことはなく､メンテナがmergeitラベルをPull Requestに付与することで､botが発動してマージプロセスを実行してくれます｡ここでも自動テストが走ります｡ここが一番気持ち的に長い｡ときどきコケて絶望します｡

9. Upstream側にtagを切る

マージされたらUpstream側にtagを切ります｡完了までもう少し｡ここから先は､もう理不尽にコケるところはないので気楽な作業です｡

$ git checkout main
$ git pull
$ git tag -a 2.0.0 -m "Release 2.0.0"
$ git push upstream 2.0.0
10. リリースを作成する

リリースアーカイブをGitHubのダッシュボードから作成します｡

Press `Draft a new release`
Release title: Release 2.0.0
Describe for release:
~~~
ansible.posix version 2.0.0:

* [CHANGELOG](https://github.com/ansible-collections/ansible.posix/blob/2.0.0/CHANGELOG.rst) for all changes
~~~

リリースを作成した時点で､Community Galaxyにリリースが反映されます｡この時点から､一般ユーザがansible-galaxy collection install ansible.posixコマンドでインストールできるようになります｡

ansible.posixはRed Hatが公式にサポートしているコレクションですから､Red Hat Hybrid Cloud Consoleでもアーカイブが提供されています｡こちらの反映時には厳格なテストが行われるので､即反映とはなりません｡長くて数日かかります｡Red Hatさんちゃんとしてる｡

11. Ansible Communityにリリースアナウンス

もうちょっとだ｡Matrixにある､Ansible CommunityのAnsible Socialチャンネルで､newsbot宛てにリリースを伝えます｡

@newsbot: ansible.posix 2.0.0 has been released.
This release includes two break fixes for options in the firewalld module. Additionally, please note that the Skippy plugin has been removed. You can see more details in changelog.

これで､Ansible Communityからのnews letterにリリースが掲載されます｡

12. リリース完了!

ansible.posixリポジトリのRelease plan #149でもリリースをアナウンスします｡

リリース完了! 世界のどこかにいるAndresson007とmaxamillionの2人に感謝｡いつもレビューありがとう! :)

まとめ

これが僕がメンテナになってから､有識者に聞いたりドキュメントをかき集めたAnsible Collectionのリリースプロセスの流れです｡

メンテナガイドみたいな､まとまったドキュメントがあると思ってたんだけどなぁ.....なってみたら､この世にそんな都合の良いものはなかったっていうよくある話でした｡community.generalは､もっとかっこいい方法を持ってるらしいと風の噂に聞いたので､今度聞きに行ってみようと思います｡

ドキュメントがなければ､自分で作ればいいっていうのは､昨日のお話の､いっそ自分でコードを修正しちゃったほうが速いっていうのと通じますね｡あれ通じないかな｡あったほうがいいよなやっぱり｡

それではみなさん､今日もHappy Automation!

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。