CIGitWindows
インフラCI

インフラCI実践ガイドを試してみる⑧【インフラCIを循環させる(前半)】

スポンサーラベル
CI
2020.07.05

購入した書籍「インフラCI実践ガイド」を試した際のメモの続きです。

インフラCI実践ガイドを試してみる⑦【CIのパイプライン(後半)】
購入した書籍「インフラCI実践ガイド」を試した際のメモの続きです。第7章のCIのパイプライン後半になります。7.2 さまざまな問題を検知する7.3.1 規約「...
syachiku.net

第8章のインフラCIを循環させる仕組みになります。第8章もボリュームがあるので前半と後半に分けます。今回は前半です。

8.1 サイクルを構成する要素

インフラCIの要素はPDCAである。

変更要求を取り入れるための計画(Plan)を行い、それに基づいた構成定義ファイルを作成(Do)して、さらにパイプラインで自動テスト(Check)を行い、成果物をレビュー(Action)する。

パイプラインはCheckを担当する機能、ほかにPlan/Do/Actionに相当する機能について抑えるポイントについて解説されてます。

8.1.1 要求を分解し作業を明確化する

「一斉変更ではなく小刻みな変更」が必要で、要求された内容を適切な粒度へと分解し、作業を明確化することが重要です。

8.1.2 チームでサイクルを回すための仕組み

一人でインフラ構築と変更を実施しているならば、パイプラインさえきっちりくみ上げておけば事足りるケースは多い。

チームで作業するうえで重要なのは「コミュニケーション手法」を統一する仕組み作りです。

コミュニケーション手法の統一のために以下の方法を利用する

  • Plan – チケット
  • Do – ブランチ
  • Check – パイプライン
  • Action – マージリクエスト

8.2 インフラCIの実践

演習を通じてサイクルの開始から終了までを試してみます。

操作するユーザを管理者(root)と開発者(user)で使い分けていきます。

各作業フェーズごとの役割は以下のようになります。

作業フェーズ管理者(root)開発者(user)
Plan変更要求を受けて、適切な作業粒度に分割したうえでチケットを起票する。このチケット担当者へ割り当てる
Doチケットで作業を確認する。最新のコードを取得して作業ブランチを作成
Checkブランチで開発した内容をプッシュしてパイプラインを起動する
Actionパイプラインの結果を確認してブランチのマージリクエストを行う
マージリクエストされた内容をレビューし、問題がなければマージを行う。合わせてチケットをクローズする。

8.2.1 要求をチケットへ起票する

新規チケットの作成

管理者(root)がチケット(Issue)を作成します。

割り当てられたチケットと作業内容の確認

開発者(user)でログオンして割り当てられたチケットを確認します。

番号(#1)を覚えておきます。

ブランチの作成

ファイルをGitからCloneして、開発者(user)の設定を行います。

[root@infraci root]# mkdir ~/user && cd ~/user
[root@infraci user]#　git clone http://192.168.33.10/root/ketchup-vagrant-ansible.git
[root@infraci user]#　cd /ketchup-vagrant-ansible
[root@infraci ketchup-vagrant-ansible]# git config --local user.name "user"
[root@infraci ketchup-vagrant-ansible]# git config --local user.email "user@exsample.com"
[root@infraci ketchup-vagrant-ansible]# git config --local push.default simple

ブランチを作成します。

[root@infraci user]# cd ~/user/ketchup-vagrant-ansible/
[root@infraci ketchup-vagrant-ansible]# git checkout -b dev/issue/1
Switched to a new branch 'dev/issue/1'
[root@infraci ketchup-vagrant-ansible]# git branch
* dev/issue/1
  master

演習では、ブランチ名のルールを「<対応課題>/<チケット分類>/<チケット番号>」としてます。

ブランチでの変更を実施

7章で実施した内容をまとめて変更します。ファイルの編集部分は割愛します。

結果としては以下3ファイルを編集されたことが確認できます。

[root@infraci ketchup-vagrant-ansible]# git status
# On branch dev/issue/1
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   hosts/ketchup/inventory
#       modified:   hosts/ketchup/test_inventory
#       modified:   roles/nginx/templates/ketchup.conf.j2
#
no changes added to commit (use "git add" and/or "git commit -a")

変更をブランチへコミットする

ローカルブランチに修正部分をコミットします。

その後git logやgit showコマンドで変更部分を確認しています。

[root@infraci ketchup-vagrant-ansible]# git commit -a -m "change ketchup port 80 to 8080" -m "Fixed #1"
[root@infraci ketchup-vagrant-ansible]# git log

commit 3d6f7e5647f27d41cdd76cdd827e588fabbe2f60
Author: user <user@exsample.com>
Date:   Thu Jun 25 17:22:06 2020 +0900

    change ketchup port 80 to 8080

    Fixed #1

[root@infraci ketchup-vagrant-ansible]# git show  3d6f7e5647f27d41cdd76cdd827e588fabbe2f60
commit 3d6f7e5647f27d41cdd76cdd827e588fabbe2f60
Author: user <user@exsample.com>
Date:   Thu Jun 25 17:22:06 2020 +0900

    change ketchup port 80 to 8080

    Fixed #1

diff --git a/hosts/ketchup/inventory b/hosts/ketchup/inventory
index 06d00e3..5da36ee 100644
--- a/hosts/ketchup/inventory
+++ b/hosts/ketchup/inventory
@@ -10,7 +10,7 @@
 [all:vars]
 ketchup_host=192.168.33.12
 ketchup_nginx_host=192.168.33.13
-ketchup_port=80
+ketchup_port=8080

 [vagrant:vars]
 ansible_connection=local
diff --git a/hosts/ketchup/test_inventory b/hosts/ketchup/test_inventory
index d9620dc..70b502a 100644
--- a/hosts/ketchup/test_inventory
+++ b/hosts/ketchup/test_inventory
@@ -10,7 +10,7 @@
 [all:vars]
 ketchup_host=192.168.33.14
 ketchup_nginx_host=192.168.33.15
-ketchup_port=80
+ketchup_port=8080

 [vagrant:vars]
 ansible_connection=local
diff --git a/roles/nginx/templates/ketchup.conf.j2 b/roles/nginx/templates/ketchup.conf.j2
index 3af539e..cac3948 100644
--- a/roles/nginx/templates/ketchup.conf.j2
+++ b/roles/nginx/templates/ketchup.conf.j2
@@ -6,6 +6,6 @@ server {
     proxy_set_header X-Real-IP $remote_addr;

     location / {
-        proxy_pass    http://{{ ketchup_host }}/;
+        proxy_pass    http://{{ ketchup_host }}/:{{ ketchup_port }};
     }
 }

8.2.3 パイプラインの起動

ブランチをGitlabへプッシュする

今回作成して修正したブランチ「/dev/issue/1」をリモートのブランチとして登録します。

[root@infraci ketchup-vagrant-ansible]# git push origin dev/issue/1
Username for 'http://192.168.33.10': user
Password for 'http://user@192.168.33.10':
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (10/10), 771 bytes | 0 bytes/s, done.
Total 10 (delta 6), reused 2 (delta 0)
remote:
remote: To create a merge request for dev/issue/1, visit:
remote:   http://192.168.33.10/root/ketchup-vagrant-ansible/merge_requests/new?merge_request%5Bsource_branch%5D=dev%2Fissue%2F1
remote:
To http://192.168.33.10/root/ketchup-vagrant-ansible.git
 * [new branch]      dev/issue/1 -> dev/issue/1

リモートにプッシュするとパイプラインが起動しています。

そのcommitした際に追加した”Fixed #1″のコメントのおかげで、パイプラインやIssueなどと紐づけが作られており、互いに関連のある作業であることがわかりやすくなってます。

8.2.4 マージリクエストとレビュー

マージリクエストの作成

パイプラインも成功したら開発者(user)はマージリクエストを作成します。

AssigneeにAdministratorを指定します。

他にも便利な機能としてタイトルの先頭に「WIP:」(Work In Progress)という文字列を付与しておくと、途中まで開発したコードのレビューを依頼しつつも、このコードはmasterへのマージが行えない状態になります。

コードの状態を確認

管理者(root)でログオンしなおしてマージリクエストについて確認します。

マージする前に今のコードがどうなっているか確認します。

マージリクエストのレビュー

管理者(root)は内容に問題がないことを確認したらマージします。

マージ後のパイプライン確認

マージ後には管理者(root)で2つの確認を行います。

1つ目は先ほどのマージによってパイプラインが起動しており、成功するか確認します。

もし、ここでパイプラインが失敗したら「Revert(元の状態に戻す)」ボタンでマージ前の状態に本番を戻すことができます。

それから開発者にやり直しのために差し戻しを行って、再度サイクルを回すという流れになります。

マージ後のチケット確認とクローズ

もう1つの確認は更新作業をおこなったチケットがクローズされ、作業の完了がメンバー全員に共有されているかです。

今回は以上となります。

インフラCI実践ガイドを試してみる⑨【インフラCIを循環させる(後半)】
購入した書籍「インフラCI実践ガイド」を試した際のメモの続きです。今回は第8章のインフラCIを循環させる仕組みになります。第8章の「インフラCIを循環される仕組みの」後半になります。...
syachiku.net
スポンサーラベル

コメント