CI/CD
CI
動作を継続的に確認する。
CD
ユーザに継続的に提供する。
何ができるか
- 単体テスト・環境構築・結合テスト・リリースを自動化
- ソフトウェアリリースのサイクルを早める。
- 素早くフィードバックを得られる。
- 間違いに素早く気づける。
CI/CDの大原則
自動化するための基礎を作る
適切なソースコード管理
- GitHub/git Flowで開発を行う。
- 必ずレビューを行う。
- 個人環境に秘伝のコードを置かない。
- masterに直接pushしない。
テストを書く
- Unitテストを重視する。
- 不具合を早く発見できる。
- メンテナンスコストが低い。
- テストをコメントアウトしない。(動いてない物には意味がない)
- 誰でも実行可能にする。
- 簡単に実行できるようにする。
- 何が起きるかを把握できるようにする。(状態の可視化)
CI/CDツールを利用しパイプラインを作る
- パイプライン
- ソフトウェアを安全かつ素早く利用者に届けるための一連の処理。
例
- 単体テスト
- 検証環境構築
- テスト
- 本番リリース
- 受け入れテスト
単体テスト
- モジュール/部品に対するテストを行う。
- 適切に整備し管理すれば素早くフィードバックを得られる。
検証環境構築
- 構成情報通りに環境が構築できるか確認。
- 検証環境と本番環境で差をなくせば本番の問題を事前に検知できる。
テスト
- 機能テスト・UXテスト・負荷テストなど。
- 検証環境と本番環境で差をなくせば本番の問題を事前に検知できる。
本番リリース
- 本番環境を構築。(パッケージ適用など)
受け入れテスト
- 失敗したら元に戻す。(できるだけ行わない)
- PullRequestでのテスト
- メリット
- 単体レベルでは問題がないと自信を持ってmaster,developにマージできる。
- 作業の手戻りを最小限にできる。
- レビュアーの負荷が下がる。
- リファクタリングが自信を持って行える。
- メリット
状態を適切に維持する
- 失敗を検知できるようにする。
- メールやMYMで通知されるよう設定
- 失敗したら放置せず最優先で修正
- 失敗したテストを無効化しない。
ツールの活用
綺麗な環境を作り、指定された処理を実行
- 綺麗な環境
- 他の影響を受けない環境が必要
- この環境では動く問題を回避
- 最近はコンテナ技術を使うツールが多い。
- Dockerなど
- 他の影響を受けない環境が必要
- 条件
- Githubのリポジトリにcommit
- UI上でStartボタンのクリック
- ツールでの処理の成功
- 例
- masterにマージ
- java環境でテスト(maven test)を実行
- 成功したらコードをビルドしデプロイ
まとめ
自分自身もCI/CDの経験は浅いので備忘録も含めて
同じような駆け出しの人に届けれたらいいなと思ってまとめてみました。