ベストプラクティスのまとめ - AWS での継続的インテグレーションと継続的デリバリーの実践

ベストプラクティスのまとめ

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

すべきこと:

  • Infrastructure as Code を処理する。

    • インフラストラクチャコードにバージョン管理を使用する。

    • バグトラッキング/チケット発行システムを利用する。

    • 変更を適用する前にピアレビューを実施する。

    • インフラストラクチャコードのパターン/設計を確立する。

    • コード変更などのインフラストラクチャの変更をテストする。

  • デベロッパーを 12 人以下の自立したメンバーで構成されるチームに統合する。

  • 長く続く機能ブランチを持たずに、すべてのデベロッパーにメイントランクにコードを頻繁にコミットさせる。

  • 組織全体で Maven や Gradle などのビルドシステムを継続的に採用し、ビルドを標準化する。

  • コードベースの 100% のカバレッジを目標としてデベロッパーにユニットテストを構築させる。

  • ユニットテストが期間、数、およびスコープにおいてテスト全体の 70% を占めていることを確認する。

  • ユニットテストが最新のものであり、無視した部分がないことを確認する。ユニットテストの失敗は、バイパスするのではなく修正する必要がある。

  • 継続的デリバリーの設定をコードとして扱う。

  • ロールベースのセキュリティ制御 (つまり、誰が何をいつできるか) を確立する。

    • 可能な限りすべてのリソースを監視/追跡する。

    • サービス、可用性、および応答時間に警戒する。

    • ものごとを把握し、学習し、改善する。

    • チームの全員とアクセスを共有する。

    • メトリクスとモニタリングをライフサイクルの計画に組み込む。

  • 基本的なメトリクスを保存し、追跡する。

    • ビルドの数。

    • デプロイの数。

    • 変更が本稼働環境に到達するまでの平均時間。

    • 最初のパイプラインステージから各ステージまでの平均時間。

    • 本稼働環境に到達する変更の数。

    • 平均ビルド時間。

  • 各ブランチとチームに区別された複数のパイプラインを使用する。

してはいけないこと:

  • 大規模で複雑なマージを伴う長期的なブランチを持つ。

  • 手動テストを行う。

  • 手動の承認プロセス、ゲート、コードレビュー、セキュリティレビューを持つ。