# 20ex1. DevOpsの実践 ________________________________________ 答えが分からないものを模索しながら作り続ける世界に我々は突入した https://www.publickey1.jp/blog/22/12022.html 開発スピードの速い企業は品質が高く、遅い企業は品質が低い https://www.publickey1.jp/blog/22/22022_1.html フルスタックエンジニアから「フルサイクルエンジニア」へ https://www.publickey1.jp/blog/22/32022.html 自動テスト文化を根付かせる王道と、邪道を教えよう https://www.publickey1.jp/blog/22/42022.html 『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 (1) https://twop.agile.esm.co.jp/how-did-we-embrace-changes-as-developer-8794826bc515 ________________________________________ ## 0. 前提知識要約 ________________________________________ ### 0.1. 目標と指標 目標 1. 目標を掲げる 2. 「面倒」の「排除」を大切にする。「面倒」はチャンス 指標とそれに対する目標 1. リードタイム(開発開始からリリースまでの期間) - 3日以内(単機能に絞った開発開始~テスト完了マージまで) 2. 本番環境へのデプロイ頻度 - 週1 3. MTTR(不具合発覚から収束するまでの期間) - 3日以内 4. 変更失敗率(本番デプロイに対するロールバック・緊急メンテナンス・緊急修正の頻度) - 15%以下 指標に強く相関するもの 1. 入場容易性 - 新規者が容易に開発環境を構築できる - 新規者が容易に開発環境にて動作確認できる - 新規者が容易に開発作業に参加できる 2. テスト容易性 - テストの大半を統合環境(テスト環境)を必要とせずにローカルで実施できる 3. デプロイ容易性 - 単機能単位で改修&リリースできるようにする - アプリケーションを、それが依存する他のアプリケーションサービスからは独立した形でデプロイまたはリリースできる ________________________________________ ### 0.2. 原則と基盤 CIの原則 - 「品質」の概念を生産工程の最初から組み込む - 作業は(小さい)バッチ処理で進める - 反復作業はコンピュータに任せ人間は問題解決に当たる - 徹底した改善努力を継続的に行う CIの技術基盤 - 包括的な構成管理(全部バージョン管理) - 継続的インテグレーション(いつでもテストし、いつでもテストを改善していく) - 継続的テスト(自動テスト) ________________________________________ ### 0.3. 良いテスト 良いテスト自動化とは - 信頼性の高い自動テストを備えること - テストの罠に陥らないこと - 保守性や可読性、理解容易性や変更容易性の高いテストが必要 - 開発者主体で受け入れテストを作成・管理し、手元の開発環境で簡単に再現・修正できること - QAチームは無意味 - E2Eレベルを作成も開発者が行うと良い影響が多い - 変更容易性が上がっている テストコードを根付かせるには - 教育する - 実際のプロダクトコードに対して実施研修する - 評価対象にする テストの罠 - テストコード範囲が不明確・冗長・複雑だと、それ自身がコストになる - 不安定さ、遅延、複雑、保守のしづらいテストスイートは役立たずになる - 駄目なテストスイート(辛いテストコード)は、テストスイートが全くない場合よりタチが悪い ________________________________________ ## 1. 実践 ________________________________________ ### Lv.1 プロジェクト単位で独立した管理 ```text 1. 全てバージョン管理、単一源に - ソースコードのバージョン管理、単一管理 - 全ての資料のバージョン管理、単一管理 2. 脱メール - 対外issue管理(Redmineなど) - 対外プロジェクトチャット(SlackチャンネルまたはGoogle Chatグループなど) - 社内タスク管理(小規模ならスプレッドシートで十分) - 社内プロジェクトチャット(Skypeグループなど) ※ 社内コミュニケーションと、対外コミュニケーションは「見た目」を別にしたほうが良い ``` ________________________________________ ### Lv.2 いつでもすぐに動かせるコード ```text 3. Git文化の浸透 - featureブランチ&マージ文化。細かく開発、即座にビルド - 機能境界が分かりやすい設計 4. 開発環境の個人環境化、開発環境構築手順の簡易化・自動化・ソースコード内化 - 結果的にちょっとした画面の実動作確認も容易になる ``` ________________________________________ ### Lv.3 単機能/不具合修正をリリース出来る仕組み ```text 5. 小さなバッチサイズ(作業の細分化・単機能化) - 待ちに対して別の作業をしてはいけない - 待ちを減らす方法を考える - マルチタスクは悪い考え - 「始めることをやめよ、終えることを始めよ」 6. 開発環境、受け入れ環境、本番の3環境の常設 - 開発環境はDB含めローカル環境だとより良い - 受け入れ環境はいつでも触れるようにしておくと良い ``` ________________________________________ ### Lv.4 費用対効果の高い手順化 ```text 7. Lv.5 の前段階として手順化や整備 - ビルド手順・パッケージング手順の明確化・単純化 - ソースレベルでパッケージング・デプロイしやすいフォルダ構成等にあらかじめしておく、など - デプロイ先の環境ごとのパラメータの明確化 - スモークテスト手順の明確化 ``` ________________________________________ ### Lv.5 費用対効果の高い自動化 ```text 8. ビルド自動化 - UAT/本番等のターゲットに対する設定切り替えのワンボタン化 - 手動調整の禁止 - コピペだけでデプロイ出来る状態にするまでを自動化 9. デプロイ自動化 - サーバ停止 & コピペ & サーバ再起動 をバッチで自動化 - リリース後のスモークテスト(接続テスト等)の自動化 10. チケット管理の自動化 11. 勤怠管理の自動化 ``` ________________________________________ ### Lv.6 さらに高度なDevOps ```text 12. メンバーの作業の可視化(現在の作業中のタスクの明確化/割り込みの禁止の明確化) - タスクが明示されて適切に消化できるなら、本来は楽しいはずなのだ 13. DBマイグレーションをデプロイ自動化に統合 14. 全資料のプレーンテキスト化、差分表示可能化 15. オンプレからクラウドへの移行 16. インフラ基盤のコード化(IaC) - インフラをペットから家畜へ 17. TDDの実現 18. TDDとCIの統合 ```