Elastic BeanstalkはエンタープライズグレードのCDに適していますか？

私はJenkinsを使用してマイクロサービスを構築し、Elastic Beanstalkにデプロイしているプロジェクトで作業しています。統合ブランチをテスト環境にデプロイし、ブランチをステージング環境にリリースしてから、最終的なマスタービルドを本番環境にデプロイします。私はこの方法でそれを行うことにいくつかの懸念があります。最初に、環境ごとにプロジェクトごとに1つのビルドのマトリックスが作成され、作業が重複することを意味します。2つ目は、ステージングで検証されたものと同じビルドアーティファクトを本番環境にデプロイしないことです。

私はBeanstalkを放棄して、デプロイメントにChefのようなものを使用してプレーンなASGに移行する傾向があります。これにより、プロジェクトごとに1つのビルドが作成され、ビルドアーティファクトが生成されます。ステージングで承認されたプロダクションに同じアーティファクトをデプロイできます。ただし、移行の前払いコストはさほど重要ではありません。より信頼性が高く、管理が容易なCI / CDを可能にするBeanstalkをよりよく使用する方法はありますか？

注：同じビルドアーティファクトをプロモートすることはまさに私がやりたいことですが、ドキュメントからはそれを行う明確な方法がわかりません。アプリソースからEBにデプロイする方法について説明していますが、既存のバージョンを別の環境に昇格させる方法については説明していません。EB自体で使用できる場合、Jenkins EBデプロイメントプラグインに制限があり、それが特にJenkinsで実行できないようになっている可能性がありますが、その方法はまったくわかりません。

IMOは、あなたの問題はそのシナリオのElastic Beanstalkにあるのではなく、Jenkinsにある、または少なくともそれを使用している方法にあると考えています。「もの」の内容にかかわらず、「もの」の構築に本当に集中する必要があります。

完全な開示：私はThoughtWorksで働いており、GoCDに非常に偏っています。私ができる限り中立的であったように、私が何を意味するのかを詳しく説明しようとします。私のツールのドキュメントは例として使用しますが、うまくいけば、人々は自分のシステムを推定できます。

パイプラインの早い段階で「アーティファクト」を構築しています。これは、アプリケーションのすべてまたは一部を表すバイナリである場合と、テストツールなどの任意の数のツールから出力される場合があります。これらのアーティファクトはシステムによって保存され、再構築されることはありません。次に、システムは必要に応じて適切なリビジョンからアーティファクトをフェッチします。

例えば...

1. .jarファイルを作成して、基本的なC / Iなどの単体テストを実行します。合格すると、その.jarファイルとテストの出力がその特定のパイプラインジョブにアップロードされます。
2. 次のパイプラインは、より複雑なテスト環境への展開になる可能性があります。それはそれを構築した正確なジョブから正確な jar をフェッチする必要があります。次に、Elastic Beanstalkを実行して、そのjarを適切な環境にデプロイします。
3. 次のパイプラインは、ステージングデプロイメントです。これは、第1パイプラインにすべての方法の背中を行くとフェッチ正確からjar 正確なそれを建てた仕事を。次に、Elastic Beanstalkを実行して、そのjarを正しい環境にデプロイします。

これらを使用すると、ブロックすることなく、より多くの並列またはオンデマンドで実行できます。

Elastic Beanstalk、Chef、Puppet、Ansible、uDeploy、または他の任意の数のツールを使用して、実際のデプロイを行うことができます。問題の原因はここではありません。継続的インテグレーションサーバーは、元々これを行うために構築されていません。もちろん、同じ場所に行くために使用できるプラグインはたくさんあります。

GoCD、Chef Automate、ConcourseCIなどの継続的デリバリーサーバーは、このような問題を解決するために特別に構築されました。