はじめてのPHPプロフェッショナル開発 ch14 継続的インテグレーション
なぜ継続的インテグレーションが必要なのか
継続的インテグレーションとは
- CI: Continuous Integration
- コードに変更を加えた際に、自動的にビルドやテストを行う取り組み
- ビルドの実行
- テストやその他の検査の実行
- mergeやデプロイを行った際に問題が生じないかというチェックを完全に自動化
- 属人性を拝する
- 不確実性を排して、安定的な開発とサービス提供を行っていく
- XP: Extreme Programmingの手法の一つ
- デプロイも行うものをCD: Continuous Delivery | Continuous Deployment とも
- Continuous Deliveryは、「機能は完成しているがまだDeployしない」という選択肢も残すものを言うらしい?
- Continuous Delivery vs Continuous Deployment
- DeploymentならばDeliveryするが、逆は成り立たない
- Continuous Deliveryは、「機能は完成しているがまだDeployしない」という選択肢も残すものを言うらしい?
- 結局、「デプロイを行っても問題ない」という判断のためにCIを回すので、CI/CDとひっくるめられること多し
CIによって得られるもの
- Continuous Integration
- 「統合」
- masterブランチへのmergeと考えて差し支えない
- 何か壊れたときの原因特定コストを大幅に抑制できる
- masterブランチから派生して新しくコードを書く時、「問題ない状態からスタートしている」ことが保証される
- 何か壊れたら「最近自分が書いたどこか」のせい
- 最低限の品質保証を均質的に可能にする
- 開発者個々人の技量等によらない
- 「忙しいから省力化」等が挟まれることもない
Economics of Test Automation -- 自動化テストの経済性
- テスト自体はプロダクトコードではない
- テストにコストを割くのは効率的なのか??
- 古典名著「xUnit Test Patterns」
- 「最初のうちはコストが高くつく」
- 「しっかり書かれた自動化テストは、プロダクトコードの開発を効率化し、テスト自体にかける実装コストを逓減していく」
- 開発が続くにつれて元を取れる
- 前提
- 自動化して、定期的・高頻度でテストが実施されること
- テストコード自体の品質にも気を遣うこと
- 「さもないと、テスト自体をメンテナンスし続けるコスト」がかさむ
CIツールとは
- 大まかな機能
CIツールの種類、選び方
オンプレミス | クラウド(汎用) | クラウド(目的特化) | |
---|---|---|---|
環境構築の自由度 | 自由自在 | 低い | 低い |
運用コスト | 高い | フリー | フリー |
例 | jenkins | CircleCI, TravisCI | Codecov, Scrutinizer |
- オンプレはH/W, M/W, 言語バージョン等自由自在、クラウド型は制約あり
- 反面、それ自体が運用コストや導入障壁になるため、良し悪し
- 目的特化型: 利用者がタスクを定義しない
CIを利用してみる
Travis CIとは
- クラウド・汎用型CIツール
Travis CIの導入
Travis CIのジョブについて〜ライフサイクルと.travis.yml
ジョブの実行結果(Passed, Faied, Errored)と内容の確認
- すでにCircleCIの使用経験があり、視座が広がらなそうなので略
- 暇な時に触ってみよう