Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
32 lines (27 sloc) 9.67 KB

Continuous Delivery check

Part of the Multi-team Software Delivery Assessment (README)

Copyright © 2018-2019 Conflux Digital Ltd

Licenced under CC BY-SA 4.0 CC BY-SA 4.0

Permalink: SoftwareDeliveryAssessment.com

Jez Humble氏とDave Farley氏による書籍 Continuous DeliveryCDchecklist.info にある書籍の要約に基づいています。

目的:主要な継続的デリバリーの実践に関するチームの認識とパフォーマンスを評価すること

方法:Spotify Squad Health Check のアプローチを使用して、次の質問に対するチームの回答を評価する:

質問 しんどい (1) すばらしい (5)
1. リリース候補 - すべてのチェックインにリリースの可能性があります (Chapter 1) 特別な"リリース候補"ビルドが時折ある どのチェックインでも、ビルドを生成できる。ビルドは、それ以上ビルドすることなく実稼働に移行する可能性がある
2. 完了 - "完了" は リリース済み つまり [実稼働環境にリリースされ、問題を引き起こしていない] を意味します (Chapter 1) 完了の定義は、 "機能テストに合格した"ことを意味する 完了の定義は、変更がプロダクションにデプロイされ、何も問題が起きていないことを確認するための監視が行われることを意味する
3. 自動構成 - ビルドの構成は、構成リポジトリから取得した値を使用して、常に自動化されたプロセスで実行する必要があります (Chapter 2) アプリケーションとテストの多くは毎回手動で構成される すべての構成はスクリプトを使用して行われる
4. 構成オプション - デプロイされるすべての環境で、特定のバージョンのアプリケーションで使用可能な構成オプションを誰でも簡単に確認できます (Chapter 2) 異なるファイルに対して差分を実行する必要がある。一部はバージョン管理で、一部はライブサーバーから取得する 任意の環境にデプロイされた構成オプションを表示するAPIまたはUIがある
5. 壊れたビルド - 壊れたビルドをチェックインしません(Chapter 3) [壊れたビルドを修正することを除く!] チームがいつビルドを壊したかは簡単にはわからない ビルドを慎重に監視し、壊れたビルドにはチェックインしない
6. 失敗したテスト - 失敗したテストをコメントアウトしないでください (Chapter 3) ビルドまたはパイプラインを機能させるために、失敗したテストをオフにする テストを信頼する。 テストが失敗した場合、何かが間違っているので、修正する
7. バイナリ - 一度だけバイナリをビルドします [特別な「リリース候補」ビルドはありません] (Chapter 5) 複数の異なるビルドがあり、最終的なリリース候補を作成するためにマージする バイナリアーティファクトを生成するビルドは1つしかないため、追加のマージやビルドを必要とせずにすべての環境に配布される
8. ラインを止める - パイプラインの一部に障害が発生した場合、ラインを停止します [誰もが作業を停止し、問題を修正します] (Chapter 5) パイプラインは非常に頻繁に失敗するため、どのチームがビルドを中断したかを知ることは困難 パイプラインが失敗した場合、どのチームが責任を負うかは非常に明確であるため、問題を解決するために作業をすぐに停止する
9. べき等性のあるデプロイ - デプロイプロセスにはべき等性があリます [同じバージョンで同じ結果を繰り返しデプロイできます] (Chapter 6) 反復可能なデプロイを実施することは困難 同じバージョンを何度も再デプロイして同じ結果を得ることができる
10. スタブ - スタブを使用して外部システムをシミュレートします [他のほとんどすべてのシステムを'外部'として扱います!] (Chapter 8) 使用可能なスタブはほとんどなく、スタブを作成するのに十分な時間がない 使用しているスタブは良質であり、テストがうまく機能しているという強い自信を与えてくれる
11. APIリプレイ - サービスまたはパブリックAPIに対する相互作用を記録します (Chapter 9) リモートAPIからのリクエスト/レスポンスを記録する方法はない 高精度の統合テストを実施するために使用するリモートAPIからの主要な要求/応答を記録している
12. Blue-Green - Blue-Green Deployments を[きめ細かいレベルで]実施しています (Chapter 10) - これは、既存のバージョンとともに新しいバージョンをテストし、必要に応じて古いバージョンにロールバックできるメカニズムがあることを意味します Blue-Green Deployments を実施していない 個々のサービスのレベルで、きめ細かいBlue-Green Deployments を実施している
13. 環境の履歴 - デプロイを含め、すべての環境に加えられた変更の履歴を表示できる必要があります。 (Chapter 11) 環境の変化の履歴を見るのは難しい すべての環境に対する変更の履歴を確認する素晴らしいダッシュボードまたはログがある
14. DB変更 - データベースの移行や[他のデータがリッチなサービスから]からアプリケーションのデプロイを切り離します。 (Chapter 12) - これはデータベース共有に関連しています データベースまたはデータレイヤーと共にアプリケーションまたはサービスを展開する必要がある 当社のアプリケーションまたはサービスは、基礎となるデータベースまたはデータ層から完全に分離されている
You can’t perform that action at this time.