この機能は(ざっくりと説明)、承認・拒否のどちらかのボタンをクリックするまで、パイプラインを一時的に停止するためのものです。微妙な点)」についてまとめてみました。イケてるところ認証・認可周りの設定管理が楽(当たり前ですが)デプロイするまでのパイプラインがAWS上で全て完結します。サードパーティ製のサービスを選択しなくて良いことによる恩恵は、ユーザーの権限管理、サービスの学習や事前調査(AWSの実行環境との親和性を調べたり)をしなくて良いことです。幅広くカスタマイズ可能です。サービスでできることであれば、大体のことはサポートされているように思います。CodeBuild(CircleCIのようなビルドパイプライン)を挿れることにより、殆どのことは実現可能かと思います。は上手い具合に自由度を制限します。唯一の方法を提供してくれます。選択する決め手となりうるのは、この標準化にあるのではないか?と思います。これがどういうことかを説明するために、少しだけパイプラインの仕組みについて述べます。具体的な処理の最小単位となります。より予め決められています。「XXの目的のときはYYを使うと良い」ということを提案してくれているのです。羅列し、ゴニョゴニョゴニョ・・・)を用いることで実現可能です。使用した方が良いということを明言します。微妙な点)ドキュメントこれは私だけかもしれないのですが、率直に言ってドキュメントが読み難い・・・というよりもどこから読んで理解したら良いのか分からない・・・というのがありました。関わるサービスが幅広いからなのかな、と思っています。構築チュートリアルは、CodeCommit、CodeBuild、CodeDeploy、CloudFormation、の3つサービスを組み合わせてパイプラインを作っていました。私は3つの全てについて無知だったため、最初何が何やら訳の分からない状態で、とりあえず動くものを作っていました笑。私の場合、まずこのチュートリアルを見ながらとりあえず動くものを作り、その後でドキュメントを熟読しました。時間がない場合、この方法でも問題ないと思います。使われている各々のサービスを1つずつ理解していくことだと思います。通知しなければなりません。関数を自前で作成しなければならないのです。連携は容易にできることが当たり前です。改善していただきたい点の1つだと思います。私が知らないだけで簡単にできる方法あるのかな???まとめ「所感」では微妙な点も述べましたが、これらは「慣れ」によって十分に解消可能だと思っています。触れてから3週間以上経ち、当初微妙な点であると感じていたことが気にならなくなっています。作れるようになりました。それではありがとうございました。作る場合、まず参考にすべきなのがこのドキュメントです。コンセプトを掴むために読んでおきたい。制約について書かれているのがこちら。本格的に使う前に1度は目を通しておきたい。ミラーリングする方法については、こちらが参考になります。2019」20日目の記事です。