# ベストプラクティスのまとめ
<a name="summary-of-best-practices"></a>

 以下は、CI/CD のためにすべきこと、してはいけないことのベストプラクティスの一部を挙げています。 

 すべきこと: 
+  Infrastructure as Code を処理する。 
  +  インフラストラクチャコードにバージョン管理を使用する。
  +  バグトラッキング/チケット発行システムを利用する。
  +  変更を適用する前にピアレビューを実施する。
  +  インフラストラクチャコードのパターン/設計を確立する。
  +  コード変更などのインフラストラクチャの変更をテストする。
+  デベロッパーを 12 人以下の自立したメンバーで構成されるチームに統合する。 
+  長く続く機能ブランチを持たずに、すべてのデベロッパーにメイントランクにコードを頻繁にコミットさせる。 
+  組織全体で Maven や Gradle などのビルドシステムを継続的に採用し、ビルドを標準化する。 
+  コードベースの 100% のカバレッジを目標としてデベロッパーにユニットテストを構築させる。 
+  ユニットテストが期間、数、およびスコープにおいてテスト全体の 70% を占めていることを確認する。 
+  ユニットテストが最新のものであり、無視した部分がないことを確認する。ユニットテストの失敗は、バイパスするのではなく修正する必要がある。 
+  継続的デリバリーの設定をコードとして扱う。 
+  ロールベースのセキュリティ制御 (つまり、誰が何をいつできるか) を確立する。 
  +  可能な限りすべてのリソースを監視/追跡する。
  +  サービス、可用性、および応答時間に警戒する。
  +  ものごとを把握し、学習し、改善する。
  +  チームの全員とアクセスを共有する。
  +  メトリクスとモニタリングをライフサイクルの計画に組み込む。
+  基本的なメトリクスを保存し、追跡する。
  +  ビルドの数。
  +  デプロイの数。
  +  変更が本稼働環境に到達するまでの平均時間。
  +  最初のパイプラインステージから各ステージまでの平均時間。
  +  本稼働環境に到達する変更の数。
  +  平均ビルド時間。
+  各ブランチとチームに区別された複数のパイプラインを使用する。

 してはいけないこと: 
+  大規模で複雑なマージを伴う長期的なブランチを持つ。 
+  手動テストを行う。 
+  手動の承認プロセス、ゲート、コードレビュー、セキュリティレビューを持つ。