

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# CI/CD リトマステスト: パイプラインは完全に CI/CD になっていますか?
<a name="introduction"></a>

*Steven Guggenheimer および Ananya Koduri、Amazon Web Services (AWS)*

*2023 年 8 月* ([ドキュメント履歴](doc-history.md))

パイプラインは自動化されていますか? これは単純な質問ですが、多くの組織はその答えに対して単純すぎるアプローチをしています。その答えは、*はい*か*いいえ*かよりもはるかに複雑です。

テクノロジーにおけるイノベーションは絶えず起こっており、組織が遅れずについていくことは困難な場合があります。この新しいものは一時的な流行なのか、それとも次の大きな潮流なのか? 現在の慣行を全面的に見直すべきか、それとも待つべきか? 実際に何かが次の大きな潮流であることが明らかになる頃には、すでに後れを取っていることが多くあります。*継続的インテグレーションと継続的デリバリー* (CI/CD) は定着していますが、常にそうだったわけではありません。多くの人々は納得するのに長い時間がかかりました。また、一部の人々は今でもさらに説得を必要としています。

CI/CD は、ソフトウェアのリリースプロセスにおけるソース、ビルド、テスト、ステージング、および本番環境の各ステージを自動化するプロセスであり、一般的にパイプラインとして説明されます。現在では、CI/CD の自動化がもたらすコスト削減とスピードによって、ほとんどの組織がその価値に納得しています。しかし、この新しいアプローチに移行することは容易な作業ではありません。スタッフが適切なトレーニングを受けていることを確認し、いくつかのリソースをアップグレードし、さらにテスト、テスト、テストを行う必要があります。やるべきことはたくさんあります。ほとんどの場合、組織が適応できるように、これらの変更を段階的に行う必要があります。

このドキュメントの目的は、完全な CI/CD プロセスを持つことが何を意味するのかを定義することです。これは、自分自身のプロセスを評価するためのツールを提供するだけでなく、まだそこに到達していないプロセスに対しては進むべき道筋を提示します。この移行への道筋は、一夜で実現できるようなものであることはほとんどありません。これらのプロセスは複雑であり、現在の従業員のスキルセットや現在のインフラストラクチャの需要など、多くの要因に依存します。優先順位を付け、小さな変更を段階的に行うことを推奨します。

## 目的
<a name="objectives"></a>

このガイドの推奨事項を実装することによる潜在的な利点には、以下のようなものがあります。
+ **効率** – 完全な CI/CD デプロイプロセスでは、複雑さとワークロードを軽減できるほか、デバッグ、手動プロセスの実行、およびメンテナンスに費やされる無数の時間を削減できます。詳細については、「[継続的デリバリーの利点](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/benefits-of-continuous-delivery.html)」を参照してください。[TechAhead のブログ記事](https://www.techaheadcorp.com/blog/how-ci-cd-save-app-development-time/)によると、CI/CD プロセスの実装により、時間、労力、およびリソースについて推定 20% の削減につながる可能性があります。
+ **コスト削減** — [Forbes Insight レポート](https://www.forbes.com/sites/forbesinsights/2017/03/16/how-it-service-management-delivers-value-to-the-digital-enterprise/)によると、「経営幹部の 4 人中 3 人が、組織全体の競争力に影響を及ぼすのは、新しいプロジェクト開発や新しいイニシアチブではなく、継続的なメンテナンスと管理に費やされる時間、資金、およびリソースの量である、ということに同意しています。」 開発サイクルが短いほど、組織が市場投入までの時間に対する野心的な目標を達成し、適切なタイミングで適切な機会をつかむことができる可能性が高くなります。
+ **スピード** – 通常、完全な CI/CD パイプラインでは、ソフトウェアの変更を数時間以内に顧客にリリースできます。特に、迅速な障害分離や小規模なパッチのプッシュを行うケースでは、CI/CD パイプラインは平均復旧時間 (MTTR) の改善に役立ちます。詳細については、「[MTTR の削減](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)」を参照してください。
+ **セキュリティ** — 完全な CI/CD パイプラインは、攻撃の潜在的な侵入ポイントを減らし、人為的ミスのリスクを低減することで、リリースプロセスの保護も実現します。完全に自動化された CI/CD パイプラインがもたらすセキュリティ上の利点は、データ侵害やサービス停止などの高コストな結果を回避するのに役立ちます。
+ **離職率の低下** — 開発者は、優れた機能の作成により多くの時間を費やし、保守とデバッグの終わりのないサイクルに陥る時間を減らすことができると、満足度が高くなります。組織にとって、これは優秀な人材をより長期間にわたって獲得し、維持することを意味します。
+ **優れた品質のコード** – 開発者は小さなバッチでコードを共有リポジトリにリリースすることで、[並行テスト](https://www.browserstack.com/guide/what-is-parallel-testing)を実施できるようになります (BrowserStack のブログ記事)。開発者は単独で作業するのではなく、頻繁にビルドをチームと共有し、重要なバグを特定するために協力します。これは開発者を支援し、不適切なコードが本番環境に到達するのを防ぐのに役立ちます。開発者同士のサポートは、高品質なリリースに貢献し、組織の成長を促進します。
+ **メンテナンス** – メンテナンスと更新は、優れた製品を作成するための重要な部分です。ただし、トラフィックのピーク時にシステムを停止しないようにしてください。CI/CD パイプラインを使用して、使用量が少ない時間帯にメンテナンスを実行し、ダウンタイムとパフォーマンスへの影響を最小限に抑えることができます。