購入した書籍「インフラCI実践ガイド」を試した際のメモの続きです。
今回は第8章のインフラCIを循環させる仕組みになります。第8章の「インフラCIを循環される仕組みの」後半になります。
8.3 チケットの管理
先ほどの演習でチケットを中心にして変更作業が回っていました。
このような仕組みを「課題管理システム(ITS: Issue Tracking System)」と呼びます。
8.3.1 ITSとVSCの連携
チケットとコミットはツールが勝手に連携してくれるわけではありません。
演習でコミットメッセージにチケット番号を含めたように、作業者が意図的に連携させる必要があります。
チケットとコミットを対応させて開発を進めるやり方を「チケット駆動開発(TiDD : Ticket-Driven Development)」と呼びます。
チケット駆動開発を実践するひとつのポイントは「チケットが存在しないコミットは禁止する(No Ticket, No Commit」ということです。
8.3.2 チケットの粒度
適切な粒度でチケットを起票することが重要です。
参考までにスクラムで用いられるチケット粒度の考え方について紹介します。
エピック(Epic)
エピックとは、組織横断のプロジェクトや、インフラの要件定義といったある程度上流に近い部分で発生する課題です。
システム変更としてはあまり詳細まで固まっていないことが多く、チケットを起票することはありません。
- サービスのセキュリティ監査への対応を行う
- 現在のデータ解析基盤を改修して、より高速な分析が行えるようにする
- 新規の支店の開設のためネットワーク環境を整備する
ストーリー(Story)
ストーリは、具体的な機能要求やシステム要件に近い課題です。
スクラムではユーザーに価値を提供するためのユーザーストーリーとも呼ばれます。
チケットとして起票が可能となってきます。目安としては1人の担当者が調査を含めて、2,3日程度で1回目のパイプラインが起動できるくらいの作業範囲です。
- セキュリティ診断ツールで発見された脆弱性に対応する
- データベースサーバーのチューニングを行う
- 支店とデータセンターのネットワークを接続する
タスク(Task)
タスクは作業そのものを示します。
タスク単体ではユーザーへの価値を提供するものではありません。
ただし、実際の活動は機能のコード化やテストなどの個々の変更作業を示すため、まさにチケットとして起票することが望まれる粒度です。
- Webサーバーへパッチの適用を行う
- データベースソフトウェアの設定パラメータを変更する
- データセンターのネットワーク機器に新支店へのルーティングを追加する
8.4 ブランチの管理
8.4.1 ブランチの適用
サーバー側に無秩序にブランチを作ってしまうと、どれがリリース可能な本番用ブランチで、どれがチケットに対応しているブランチなのか、分からなくなってしまいます。
事前にチームメンバー内でブランチの利用方法と命名規則を決めておく必要があります。
リリースブランチ(統合ブランチ)
演習ではmasterブランチをリリースブランチとしています。
トピックブランチ(機能ブランチ)
演習では「dev/issue/1」としてブランチを作成しました。
注意としてあまり巨大な変更を含めてしまうと、別のトピックブランチの変更の間に競合を発生させやすくなり、マージする際の手間が大きくなります。
8.4.2 マージリクエスト
GitHubではプルリクエストと呼ばれる機能で、あるブランチの差分を別のブランチに統合する機能です。
8.4.3 ブランチ戦略
ブランチの作成ルールには、ブランチ運用を統一するために提唱された「ブランチ戦略」というものがあります。
書籍の演習ではGitLab Flowに沿ったブランチの管理を行っています。
- Git Flow -> developやhotfix、releaseなどのブランチ
- Gitlab Flow -> masterブランチからproductionブランチに変更を流しあんがら品質を上げる戦略
- Github Flow -> masterブランチとfeatureブランチの2種類だけ
8.5 レビューの重要性
8.5.1 レビューの目的
レビューには2つの目的があります。
- 成果物の品質を高めるためのレビュー
- 知識の共有を促進するためのレビュー
8.5.2 レビューの観点
レビューで品質をい高めるためには、積極的な議論が必要です。そして議論を行うには「ネタ」が必要です。このネタとする題材こそが、レビュー担当者が見つけるべき指摘事項になります。
ルールに関する指摘
プロジェクトの初期段階ではすべてのルールを揃えることは難しいので、徐々にLintツールで組み込んでいく運用になります。
- Ansibleのタスク名の命名方法(名前だけを見てやっていることが理解できるか）
- コミットメッセージの書き方(必要な情報が含まれているか)
- チケット番号の埋め込み忘れなどの情報連携の不備
- パイプラインやブランチの命名規則
- 危険な処理や禁止コマンドの指摘
実装に関する指摘
- 実装の適切さ
- 処理の不備、想定漏れ
- 新たに実装した処理のテストの漏れ
- テストの不足、パターン漏れ
プロジェクト内での連携に関わる指摘
- 再利用を促進するための指摘(すでに別の場所で同じような処理がある、汎用化できる処理など)
- 処理の順番や依存関係の不備に関する指摘
- チケットサイズ
プロジェクトの背景や環境に関する指摘
- プロジェクトのポリシーに反した実装など
- 本番環境ではアクセスできないリソースへのアクセスや権限の利用
- 外部との連携を行う箇所で、連携側の仕様変更に伴う指摘
- 現在のセキュリティルールでは実施してはいけない処理
8.6 サイクルの再確認
再度実習となります。途中までは今までと同じなのでポイントだけ記載します。
実施した内容としては既存のブランチの確認した後に、masterブランチに変更して、最新の状態を取り込みます。
[root@infraci ketchup-vagrant-ansible]# cd ~/user/ketchup-vagrant-ansible/
[root@infraci ketchup-vagrant-ansible]# git branch
* dev/issue/1
master
[root@infraci ketchup-vagrant-ansible]# git checkout master
Switched to branch 'master'
[root@infraci ketchup-vagrant-ansible]# git pull origin master
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), done.
From http://192.168.33.10/root/ketchup-vagrant-ansible
* branch master -> FETCH_HEAD
Updating 86ebc72..6a823de
Fast-forward
hosts/ketchup/inventory | 2 +-
hosts/ketchup/test_inventory | 2 +-
roles/nginx/templates/ketchup.conf.j2 | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)新しいトピックブランチ(dev/issue/2)を作成します
[root@infraci ketchup-vagrant-ansible]# git checkout -b dev/issue/2
Switched to a new branch 'dev/issue/2'
[root@infraci ketchup-vagrant-ansible]# git branch
dev/issue/1
* dev/issue/2
master修正をおこなってCommitします。
もし、CommitメッセージにFixedのチケット番号追加を忘れてしまったら、–amendオプションを使うことで直前のコミット操作をやり直せます。
[root@infraci ketchup-vagrant-ansible]# vi roles/ketchup/templates/config.json.j2
[root@infraci ketchup-vagrant-ansible]#
[root@infraci ketchup-vagrant-ansible]#
[root@infraci ketchup-vagrant-ansible]# git commit -a -m "enable ketchup backup"
[dev/issue/2 d53493d] enable ketchup backup
1 file changed, 1 insertion(+), 1 deletion(-)
[root@infraci ketchup-vagrant-ansible]# git show
commit d53493d12bc0bbe02016b114745a453597529a06
Author: user <user@exsample.com>
Date: Thu Jun 25 22:49:32 2020 +0900
enable ketchup backup
diff --git a/roles/ketchup/templates/config.json.j2 b/roles/ketchup/templates/config.json.j2
index 5c6898b..5c36b89 100644
--- a/roles/ketchup/templates/config.json.j2
+++ b/roles/ketchup/templates/config.json.j2
@@ -6,7 +6,7 @@
"path": ""
},
"backup": {
- "enabled": false
+ "enabled": true
},
"themes": {
"path": "themes",
[root@infraci ketchup-vagrant-ansible]#
[root@infraci ketchup-vagrant-ansible]#
[root@infraci ketchup-vagrant-ansible]# git commit --amend -m "enable ketchup backup" -m "Fixed #2"
[dev/issue/2 938a285] enable ketchup backup
1 file changed, 1 insertion(+), 1 deletion(-)
[root@infraci ketchup-vagrant-ansible]# git show
commit 938a285145fddd796de3b54d8faf87e5da887d56
Author: user <user@exsample.com>
Date: Thu Jun 25 22:49:32 2020 +0900
enable ketchup backup
Fixed #2
diff --git a/roles/ketchup/templates/config.json.j2 b/roles/ketchup/templates/config.json.j2
index 5c6898b..5c36b89 100644
--- a/roles/ketchup/templates/config.json.j2
+++ b/roles/ketchup/templates/config.json.j2
@@ -6,7 +6,7 @@
"path": ""
},
"backup": {
- "enabled": false
+ "enabled": true
},
"themes": {
"path": "themes",
[root@infraci ketchup-vagrant-ansible]#8.6.3 作業の検証とレビュー依頼
変更がおわったら開発者(User)としてgitからpushして、パイプラインが完了していることを確認します。
Gitlabからマージリクエストを行います。
8.6.4 依頼内容の確認
管理者(root)でログオンしてマージリクエストをレビューします。主な確認ポイントは以下の4つです。
- 作業のトリガーとなったチケット
- マージリクエストのメッセージ
- パイプラインの結果
- 変更内容
差し戻し
8.6.5 追加実装と確認、再レビュー依頼
開発者(User)でログオンすると、管理者からのフィードバックが届いているので、指摘された内容を確認して対応をしていきます。
指摘への対応をマージリクエスト
指摘されたのではテストの実装不足なので、テストを追加して、再度Gitへプッシュします。
[root@infraci ketchup-vagrant-ansible]# vim roles/ketchup/tasks/unit_test.yml
- name: Count the number of backup files
shell: find {{ ketchup_home }}/{{ ketchup_data_dir }}/backups -type f | grep -e '[0-9]\{8\}-[0-9]\{6\}.bak' | wc -l
register: test_backup_file_num
- name: Check th number of backup file is 1
assert:
that:
- ( test_backup_file_num.stdout | int ) == 1
msg: "Ketchup backup file is not exist or remaining old file"
[root@infraci ketchup-vagrant-ansible]# git commit -a -m "added the unit test code of ketchup backup" -m "Fixed #2"
[root@infraci ketchup-vagrant-ansible]# git push origin dev/issue/2パイプラインが成功されたことを確認します。
マージリクエストのなかでも、起動したパイプラインが確認できます。
Gitlabではマージリクエストの元のトピックブランチへ追加のプッシュが行われると、このマージリクエストに関連したパイプラインとして扱ってくれます。
DiscussionタブからReplyをして再レビューを依頼します。
CIを実践しようとして失敗ケースとなった特徴的な事実を挙げます。
- CIを回したことがないプロジェクトメンバーへのケア不足
→CIの概念、考え方や様々な記法などを教育しながらCIを回していくのはかなりの困難が伴います。 - CIを回すことの重要性をプロジェクトマネージャやメンバーが理解していない。
- プロジェクト内のチームごとに使うツールや環境が違う
→プロジェクト横断的なツールの統一や、ルール、プロセスの標準化が必要 - CI環境を構成するツール選定に夢中
コミットメッセージとチケット番号
演習では情報連携を確認するためにすべてのコミットメッセージにチケット番号を埋め込んでます。
しかし、実際に運用をすると開発者もレビューする側も手間がかかります。
今回の実習ではマージリクエストにチケット番号が埋め込まれていれば、関連するコミットをたどることができます。
8.6.6 再レビューの実施
同じ流れになっているので割愛します。
8.7 演習環境のクリア
書籍の通りに実施します。
8.8 まとめ
この演習を終えたことでインフラCIの最初から最後までを体験したことになります。
サイクルを煩わしく感じた方は、従来の自由度が高い方法から制限されたプロセスを強制されたことに対しての感想ではないでしょうか。
しかし、この手法に慣れてしまうと、もはや差作業に戻れなくなるほどにインフラCIは効果を発揮します。
インフラCIのプロセスに従って作業を行うことで、一定の品質が担保され、情報共有の方法が標準化され、従来とは比較にならないほど作業の効率化が実現できます。
インフラCIを現場に浸透させて、全体的な品質向上と効率化をぜひとも図りたいですね。
今回は以上となります。
コメント