この記事はAnsible Advent Calendar 2020第1日目の記事になります。
今回はansible-lintとyamllintはAnsible Playbook / Roleを作成する際に開発サイクルの中のどこで実行されるべきか考えてみたいと思います。
開発サイクルの各linter実行ポイントの定義
今回は以下の実行ポイントをあげます。
- クライアントサイド（開発者個人のマシーン)
- CIサーバ
スコアの説明
ansible-lint、yamllintをそれぞれのポイントで実行する際の実行のしやすさを点数化します。点数計算の基準となる指標は以下の通りとします。
- 強制力
- Shift left度
- 保守性
強制力
linterを利用することを開発者に強制しやすいかどうか。
例えばIDEやエディターでlinterを実行する場合は各個人でlinterをインストールする必要が出て来ます。そのため開発者のスキルにより強制できない場合があります。
一方CIサーバ側に組み込む場合はほとんどの場合は必ずlinterを強制する事ができます。
A: 強制力が高い
.
.
.
F: 強制力が低い
Shiftleft度
開発ライフサイクルの早い段階でlinterを実行できるかどうか。
例えばIDEやエディターでlinterを実行する場合git commit前にlinterがコードの異常を検知する可能性が高くなります。
一方CIサーバ側で実行する場合はgit push後になり異常検知が遅くなります。
A: 検知の位置が速い
.
.
.
F: 検知の位置が遅い
保守性
linterのバージョンアップ、設定ファイルのアップデート等に追従できるか
例えばIDEやエディターでlinterを実行する場合はlinterのバージョンアップは各開発者任せになります。そのため開発者のスキルレベルによってはバージョンアップの追従等が困難になる可能性があります。
一方CIサーバ側で管理する場合はCIサーバの管理者側の裁量により行えるため保守が容易になると考えられます。
A: 保守しやすい
.
.
.
F: 保守しにくい
スコア化
実際にこれらの要素と指標を点数化すると以下の通りになります。
| 実行ポイント | 強制力 | Shiftleft | 保守性 |
|---|---|---|---|
| クライアントサイド | F | A | F |
| CIサーバ | A | F | A |
チーム全体の技術力が上がればlinterを開発サイクルの速い位置で実行出来るため試行回数が上がり開発速度が上がると考えられます。
ただし仮にチームに技術力が足りなくても最後はCIツールで解決出来ると言う側面もあります。
チームの技術力によりLinterの実行ポイントを徐々に左側（開発サイクルの初期の方）へ動かしていくとよいでしょう。
具体的なCIパイプラインの組み方
そうは言ってもクライアント側でのlinterの処理結果に関係なくCIサーバ側でlinterを必ず実行するパイプラインを組んでいるチームは多いと思います。なのでCIサーバにlinterを組み込むケースをいくつか考察してみます。
チームのスキルレベルがあまり高くない
パイプラインを直列に組むと良いです。ただしCIクレジット節約のためCIが実行されている間は次の処理が実行されないように排他ロックを掛けます。
| メリット | メンバーのスキルが高くなくても良い |
|---|---|
| デメリット | CIの実行時間が長くなる |
チームのスキルレベルが高い
パイプラインを並列に組みます。ただしCIクレジット節約のためCIが実行されている間は次の処理が実行されないように排他ロックを掛けます。
| メリット | CIの実行時間が短くなる |
|---|---|
| デメリット | クライアント側でlintの不具合の検知に失敗すると待ち時間が発生する |
CIリソースを札束で買える（富豪開発環境が用意できる）
パイプラインを並列に組みます。またAWS EC2での開発ならインスタンスがいくつも起動出来るようにMolecule側で設定します。
| メリット | CIの実行時間が短くなる、待ち時間が発生しない |
|---|---|
| デメリット | 金銭的に負担が大きい |
結論
CIにリソースを突っ込めるチームが一番強く最終的に時間は金で解決出来ると言う事が分かりました