IaC本10章
IaC本の読書メモ
序章
- IaCを成り立たせているのは、ソフトウェアの実行基盤(システム、デバイス)もソフトウェアとして扱うこと
- そうするとソフトウェア開発のプラクティスを注入できる
- この章のプラクティスのテーマは、システムに品質を組み込むこと
- CI/CDの原則を利用して説明する
10.1 システムの品質
- 優れたプラクティスからは、品質の高いコード・システムが生み出される
- 品質には機能的要件も大切だが、変化を許すかも重要
10.1.1 品質の低いシステムは変更が難しい
- 単純な変更を加えたくとも、理解しにくいコードであるとコストがかかる
- インフラも多くの人の手が加わることで複雑怪奇に
10.1.2 高品質システムは従来よりも簡単かつ安全に変更できる
- コードを見て変更側かかるようなもの。変更を確認するツール、テストも必要
10.1.3 インフラの品質の着目点
- Iacを実施しても、定義ファイルに手動変更が入ったりツールの使用が誤っていると脆弱なインフラになる
- 品質の着目点を、ツールと定義ファイルにシフトすること
10.1.4 高速フィードバック
- 高品質システムの要は、変更に高速にフィードバックできること。構成変更の旧戻しがすぐにできるか
- オンプレでこれはどう実現しよう。。。
- 破壊的な変更を実施したときに問題点を早く見つけられることも重要(CI/CDの意義)
- テストで事前回避できたらベスト
10.2 インフラストラクチャー管理のためのVCS
10.2.1 VCSで管理すべきもの
基本なんでもVCSで管理すること
10.3 継続的インテグレーション
10.4 継続的なブランチのテストは継続的インテグレーションではない
- 多くの変更をしてからマージをする形だとテストが頻繁に行われない
- 継続的インテグレーションでは全員が自分の変更後トランクにコミットし、完全に統合された行動ベースに対してテストを実行する
- これだとコンフリクト起こしまくるのでは？(概念を理解できていないだけかも)
10.4.1 ビルドエラーの原因の究明
- ビルド、テストによるエラーは直ちに対応する必要がある(ライン停止状態)
- エラーを起こした人は修正するか、変更をリバートする必要がある
- 放置した状態に慣れてしまうとビルドテストから何も得られなくなる
- 次節(10.4.2)でも赤いテストを無視するな、冪等でないテストは改修せよという話
10.4.3 インフラストラクチャのためのCI
- ブランチを作らず、個々のコミットテストが走るようにすること
- 統合的なデリバリーのため
10.5 継続的デリバリー(CD)
- CDを支える考えた方は、デプロイできるインフラの構成要素を継続的にチェックする
- CDはインテグレーションの段階の問題を解決するために使う
10.5.1 インテグレーションの段階の問題点
- コンポーネントのIFが適切に定義されているから、デプロイがばっちりというのは虚構
- 大切なのは、本番と同様な環境で継続的にデプロイし続けること
- これは体感としてみんな持っていそう
10.5.2 デプロイメントパイブラインと変更パイプライン
- アプリのデプロイと同様に、インフラのデプロイも開発環境でデプロイ・テストしないと本番INさせない
- 本ではインフラのパイプラインを変更パイプラインと呼ぶ
- パイプラインが徐々に複雑さを上げながらテストする
- これは単体、ユニット、結合テストと概念は一緒ですね
- 本番と全ての工程を揃えることで、問題に早く気がつけるようになる
- CDプロセスにも手作業の承認を組み込むことができる
- ポイントは人間の関与を変更の評価やトリガだけに制約すること
- これはシステムの要件によって変わってくるように感じました。どう自動化に落とし込むか。
10.5.3 継続的デリバリーは継続的デプロイではないということ
- CDへの誤解にテスト PASS = 本番への適用というものがある
- コミットで本番に適用されるものあるが、多くは本番Readyな状態になったことを示す
- 本番に送り込むかの判断は人間がやってもいいが、プロセスはツールが行う
- この状態を作ることで、技術的にはOKだがビジネスとしてリリースするか判断する猶予ができる
10.6 コードの品質
時間と共に成長するコードベースを、どのようにメンテナンスするか
10.6.1 クリーンコード
- 良いシステムを産むために必要なものは単純さ
- 将来の変更をやシナリオを今からスコープに入れる必要はない。変更しやすことが大切
- 必要とされる物だけを作る
10.6.2 プラクティス：技術的負債をマネジメントせよ
- 技術的負債は、システムの変更コストやユーザ体験に悪影響を及ぼす
- 問題点や欠陥は見つけ次第、修正する習慣を身につける
10.7 大きなインフラストラクチャ変更の管理
- 変更は小さく実施することが鉄則だが、ADのインフラをリプレースするような時には難しくなる
- アジャイルのやり方を適用するには、分割して小さな変更に落とし込むこと
