Recommandé
Contenu connexe
Similaire à Continuous delivery 15
Similaire à Continuous delivery 15 (20)
Continuous delivery 15
- 2. 15.1 導入 • 現場で実際に作業する人向け • 継続的デリバリーを組織内でうまく機能 されるための指針 – 構成管理、リリース管理 – リリースまで含めたライフサイクル – リスク管理手法 – リスク、アンチパターンに役立つ手法
- 3. 15.2 構成管理およびリリース管理 の成熟度モデル • モデル作ったぜ – 図 15-1
- 4. 15.2.1 成熟度モデルの使い方 • モデルを使う下記成果が得られる – 成熟度の判定 – 改善する分野の発見、改善 – 変更を実行し、計画することで劇的な変化 – 実行したら、ふりかえりで改善の余地を確認 – 上記ステップを繰り返し、経験を重ね広める • 組織の改革は大変 – インクリメンタルに進め効果を測定すること が大事
- 5. 15.3 プロジェクトのライフサイ クル • チーム – 形成期、争乱期、規範期、実行期、散会・再 形成期 • ソフトウェア – 発見期、開始期、構築期、開発・デプロイ 期、運用期
- 6. 15.3.1 発見期 • 戦略目標を立てるフェーズ • 要件を取りまとめ、順位付けする投資対 効果検討書が必要 • プロダクトオーナーが必要
- 7. 15.3.2 開始期 • コードを書き始める前のフェーズ • 要件のとりまとめや分析 • 作業の範囲、計画の概要を決める – 投資対効果検討書 – 概要レベルの機能、非機能要件 – リリース計画 – テスト戦略 – リリース戦略 – アーキテクチャ – リスク、問題点のトラッキング – 開発のライフサイクル – 全体スケジュール • 全員の顔合わせが最重要
- 8. 15.3.3 構築期 • 基本的なプロジェクトの基盤を確率する フェーズ • 1-2 週間で実施 – PC、メール、リポジトリ – バックログ作成 – ビルド、テストを含めたシンプルなプロジェ クト作成
- 9. 15.3.4 開発・リリース期 • イテレーティブでインクリメンタルな手 順での開発、リリースをするフェーズ • UAT 受け入れ試験 • スクラム失敗例 – コミットメントの欠落 – よい開発手法の虫 – イテレーティブをやる前に調整する
- 10. 15.3.5 運用期 • いままでのフェーズが全部入り • イテレーティブに開発、リリースする
- 11. 15.4 リスク管理プロセス • 主要なリスクの認識 • リスク削減戦略と管理 • 継続的なリスクの認識と管理 • 特性 – チームが状況報告する標準化された仕組み – チームの進捗状況の定期的な更新と標準準拠 – マネージャーが現状を把握できる仕組み – 外部からの定期的なリスクの監査
- 12. 15.4.1 リスク管理入門 • リスク管理の一般的なモデル – すべてのリスクを影響と可能性で分類 – 組み合わせで深刻度を判断する
- 13. 15.4.2 リスク管理のタイムライ ン • 開始、構築、開発フェーズを通して定期的に再考 する • 開始期の最後 – リリース戦略 – 構築期の計画 • 構築期の最後 – チームが開発を確実に始められること • 開発・リリースのリスクの軽減 – 開発計画を見る – ふりかえりする – 朝会する
- 14. リスク管理の実践法 • イテレーティブな開発最高！ • 問いかけリスト – 進捗状況の管理方法は？ – 不具合を出さない方法は？ – などなど • 危険な兆候を見つけることができる
- 15. 15.5 デリバリーによくある問題 – その症状と原因 • ビルド・デプロイ・テスト・リリースの 際に発生するありがちな問題 – 問題、症状、原因の tips • なぜ？を 5 回繰り返す (TOYOTA?)
- 16. 15.5.1 頻度の低いデプロイメント・ バグのあるデプロイメント • デプロイメント作業に長い時間がかか り、かつその手順が安定しない • 症状・・・ • 原因 – 自動化されていない – ハードウェアが不足している – OS の設定が正しく管理されていない – などなど
- 17. 15.5.2 貧弱な品質のアプリケーショ ン • デリバリーチームが効率的なテスト戦略 を実践できない • 症状・・・ • 原因 – テスターとチームの連携ができていない – 自動テストが不十分
- 18. 15.5.3 管理が貧弱な継続的インテグ レーションプロセス • ビルドプロセスが適切に管理されていな い • 症状・・・ • 原因 – 自動テスト、コミットステージに時間がかか りすぎる – CI プロセスを理解している人がいない
- 19. 15.5.4 貧弱な構成管理 • 環境をうまく運用できず、自動プロセス によるアプリケーションのインストール を確実に行えない • 症状・・・ • 原因 – 環境が異なっている – 変更管理のプロセスが機能していない – などなど
- 20. 15.6 コンプライアンスと監査 • 規制に従う一般的な戦略 – 特権環境へのアクセス制御 – 変更管理、およびそのプロセス – 管理職の許可 – 文書化の必須 – などなど • めんどくなりがちだが、次のセクション でうまくいく原則と習慣を説明
- 22. 15.6.2 トレーサビリティを確保 する • バイナリ作成を一回だけにする – 作成されたものを使い回す • デプロイのテスト・リリースプロセスを 完全に自動化する
- 23. 15.6.3 サイロで作業する • 部署間のコミュニケーションを密にする 方法 – リリースワーキンググループ – 定期的にふりかえり、改善策の検討、実施 (PDCA) – 頻繁にデモ環境にリリースする – 現状の可視化
- 24. 15.6.4 変更管理 • 変更の承認手続きを管理する手順 – 変更諮問委員会 – 変更管理プロセス下に置く環境 – 変更リクエストを必ず通す – 変更後の問題と対策を立てる – 変更が成功したかどうか判断する基準を作成する – 変更適用するプロセスを自動化する • 三つの原則 – メトリクスを記録し、可視化する – システムがうまく進んでいるかどうかを計測し、可 視化する – ふりかえりを定期的に開催し、システムを改善する
- 25. 15.7 まとめ • 管理作業はプロジェクトを成功させる上 で不可欠 • イテレーティブでインクリメンタルなプ ロセス最高！ • 最後にひとこと – デプロイメントパイプラインいいぜ – P. 158