Amazon Web Services ブログ

Category: Developer Tools*

AWS X-Ray で AWS Lambda をサポート

本日、 で サポート の一般提供開始を発表しました。Jeff が GA で投稿したブログですでにご存知の方もいるかと思いますが (「Jeff の GA POST (Jeff’s GA POST)」)、X-Ray は分散アプリケーションの実行やパフォーマンス動作を分析する AWS サービスです。 複数の独立したコンポーネントを異なるサービスで実行するマイクロサービスベースのアプリケーションでは、従来の問題をデバッグする方法がうまく機能しません。アプリケーションでレイテンシーを分けることで、X-Ray はエラーや処理の低下、タイムアウトを迅速に診断することができます。それでは、シンプルな Lambda ベースのアプリケーションを構築し分析する方法をお見せしながら、独自のアプリケーションで X-Ray を使用する方法をご説明します。 今すぐ開始したい場合は、関数の設定ページで追跡を有効にすれば既存の Lambda 関数で簡単に X-Ray を使い始めることができます。 または で関数の tracing-config を更新してください (必ず –function-name も忘れずに): $ aws lambda update-function-configuration –tracing-config ‘{“Mode”: “Active”}’ トレースモードをオンにすると、Lambda は関数を追跡しようとします (アップストリームサービスによって追跡されないよう明示的に指示されていない限り)。オフの状態では、アップストリームサービスによって追跡するよう明示的に指示されている場合のみ関数が追跡されます。トレーシングモードをオンにすると追跡の生成が始まり、アプリケーションとその間のコネクション (辺) におけるリソースのビジュアル表現が見られるようになります。 X-Ray デーモンは Lambda 関数のいくつかのリソースを使用することがあります。メモリ制限に近付いている場合、Lambda はメモリ不足エラーを回避するために X-Ray デーモンを終了しようとします。では、複数のサービスを使用する簡単なアプリケーションを構築して新しい統合を試してみましょう。 20 […]

Read More

New – AWS CodeStarの紹介 – AWS上のアプリケーションをすばやく開発、構築、デプロイする

それほど遠く無い昔、今日多くのソフトウェア チームがアプリケーション開発で直面している、リリース期限までにソフトウェア プロジェクトを完成させ変化に対応するというような開発チームに私は所属していました。そこには新しいプロジェクト環境のセットアップ、チームメンバーのコラボレーション、各開発ビルドのコード変更、構成、ライブラリの継続的な追跡を行う日常的なタスクなどの課題がありました。 今日、企業がイノベーションと市場投入をより迅速に行うためには、開発チームがソフトウェアの作成、構築、展開をより簡単かつ効率的に行うことが不可欠になっています。   残念なことに、多くの組織は、より機敏で動的なソフトウェア開発プロセスを追求する上で、いくつかの重要な課題に直面しています。 ほとんどの新しいソフトウェア プロジェクトが直面する最初の課題は、開発者がコーディングを開始する前に完了しなければならない長いセットアップ プロセスです。 このプロセスには、IDEのセットアップ、適切なコード リポジトリへのアクセスの取得、および/またはビルド、テスト、および運用に必要なインフラストラクチャの識別が含まれます。   コラボレーションは、ほとんどの開発チームが直面しうる別の課題です。 プロジェクトのすべてのメンバーに安全な環境を提供するために、チームはさまざまなチームの役割とニーズに応じて別々のプロジェクトとツールを頻繁に設定する必要があります。 さらに、すべてのステークホルダーに、課題の更新、開発の進展、およびソフトウェアの問題の報告に関する情報を提供することは、時間がかかる可能性があります。   最後に、ほとんどの企業では、継続的インテグレーションと継続的デリバリに関するベストプラクティスを採用することで、ソフトウェア開発のスピードを高め、市場投入までの時間を短縮したいと考えています。 これらのアジャイル開発戦略を適用するには、企業が方法論についてチームを教育し、これらの新しいプロセスのためのリソースを設定するための時間を費やす必要があります。   AWS CodeStar:プレゼンテーション   開発チームがソフトウェアを構築する上での課題を緩和し、アプリケーションやソリューションをリリースするペースを向上させるために、AWS CodeStarを紹介します。   AWS CodeStarは、開発プロジェクト全体の設定を簡素化することにより、AWS上でアプリケーションの開発、構築、および展開を容易にするために設計されたクラウドサービスです。 AWS CodeStarには、ソフトウェア プロジェクトのコーディング、ビルド、テスト、デプロイ、および実行のためのプロジェクトとリソースのプロビジョニングを可能にする一般的な開発プラットフォーム用のプロジェクト テンプレートが含まれています。   AWS CodeStarサービスの主な利点は次の通りです: Amazon EC2、AWS Elastic Beanstalk、またはAWS Lambda用のテンプレートを使用して、5つの異なるプログラミング言語を使用して新しいプロジェクトを簡単に作成できます。 JavaScript、Java、Python、Ruby、およびPHPをサポートします。 テンプレートを選択すると、サービスはプロジェクトとアプリケーションに必要な基盤となるAWSサービスをプロビジョニングします。 ソフトウェアチーム全体に対するアクセスおよびセキュリティ ポリシー管理の統一されたエクスペリエンスを提供します。プロジェクトは、適切なIAMコントロール ポリシーで自動的に構成され、安全なアプリケーション環境を確保します。 コードのコミット、ビルドの結果、デプロイメント アクティビティなど、さまざまなアクティビティを追跡するための事前設定されたプロジェクト管理ダッシュボード。 素早い立ち上げと実行に役立つ実行可能なサンプルコードは、Visual Studio、Eclipse、またはGitをサポートする任意のコード エディタなどのお好きなIDEで使用できます。 AWS CodeCommit、AWS CodeBuild、AWS CodePipeline、およびAWS CodeDeployを使用して、自動的に構成された各プロジェクトの継続的なデリバリ パイプライン。 […]

Read More

AWS X-Ray の更新 – Lamba 統合を含む一般提供の開始

を最初に紹介したのは での「AWS X-Ray – 分散アプリケーションの中を見てみよう (AWS X-Ray – See Inside Your Distributed Application)」というタイトルのブログ投稿でした。 は Amazon EC2 インスタンス、Amazon ECS コンテナ、マイクロサービス、AWS データベースサービス、AWS メッセージングサービスをトラバースする実行として、アプリケーションに対して行われたリクエストをトレースできるようにします。これは開発および本番環境用に設計されており、シンプルな 3 層アプリケーションや何千ものマイクロサービスで形成されたアプリケーションを処理することができます。去年公開したブログでも説明しましたが、 はリクエストのエンドツーエンドのトレースや、代表的なサンプルのトレースセットの記録、サービスのマップ表示、データのトレース、パフォーマンス問題やエラーの分析を行えるようにします。これにより、アプリケーションとその基盤サービスがどのように動作しているか把握することができるため、問題の根本的な原因を識別し対処することができます。詳細については、X-Ray の機能を詳しく説明した過去のブログをご覧ください。 のプレビューバージョンは re:Invent でリリースし、興味を示した開発者やアーキテクトが使用できるようにご招待しました。本日より、同サービスの一般提供を開始しました。、、、、、、、、、、、 リージョンで今すぐご利用いただけます。 新しい Lambda 統合 (プレビュー) 本日よりご利用いただけるプレビューバージョンには、先のプレビュー実施時に行ったサービスの微調整と 統合が含まれています。これにより、Lambda のデベロッパーが を使用して関数の実行やパフォーマンスの可視性を得ることが可能になりました。これまでは、Lambda のユーザーがアプリケーションのレイテンシーの詳細やスローダウンの原因を突き止めたい場合、またはタイムアウトをトラブルシュートしたい場合はカスタムロギングや分析に頼る必要がありました。この新しい統合を使用するには、対象となる関数に実行ロールを指定してください。この実行ロールは、関数が X-Ray に書き込むことを許可し、関数をベースにトレースすることを可能にします (コンソールを使用して新しい関数を作成した場合、適切な許可が自動的に指定されます)。次に X-Ray サービスマップを使用して Lambda 関数、EC2 インスタンス、ECS コンテナなどでどのようにリクエストが動作しているか確認します。興味のあるサービスやリソースを識別、拡大、タイミング情報を調査し問題を解決します。Lambda 関数への各呼び出しは 2 つ以上のノードを X-Ray マップで生成します。Lambda サービス – このノードは […]

Read More

AWSでの疎結合データセットの適合、検索、分析

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する(あるいは反論する)ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています(例えば、日時が間違っている、地理座標が間違っているなど)。 最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。 データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。 関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。 このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。 異なる3つのデータセットを適合させて索引付けし、検索可能にします。 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。 Amazon AthenaやAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

Read More

AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント

同僚のJohn PignataがAmazon ECSに対する継続的デプロイメントパイプライン作成方法について素晴らしいブログを書いてくれました。 — 今日のビジネス環境では、新しいソフトウェアの反復を高速で提供することは競合に対するアドバンテージになります。企業がイノベーションを顧客に提供するスピード、変化する市場に適応するスピードは、ますます成功と失敗の違いを生む重要な要素になっています。 AWSは、企業がアプリケーションやサービスを高速に提供する組織の能力を向上させるDevOpsと呼ばれる文化哲学、実践、ツールの組み合わせを企業が採用できるように設計された一連の柔軟なサービスを提供します。 このポストでは、継続的デプロイメントと呼ばれるデプロイの実行方法について説明し、AWS CodePipeline、 AWS CodeBuild、および AWS CloudFormationを使用してAmazon ECS上のDockerコンテナとして提供されるアプリケーションの自動デプロイメントパイプラインを実装するためのリファレンスアーキテクチャの概要を説明します。 継続的デプロイメントとは? 俊敏性は、ITリソースのトラディショナルな提供方法に比べてクラウドコンピューティングが持つ重要な利点としてよく引用されています。他の部門が新しいサーバーをプロビジョニングするのに数週間か数ヶ月待つ代わりに、開発者はシングルクリックやAPIコールで新しいインスタンスを作成することができ、数分で使用開始することができます。この新たな速度と自律性は、開発者が新しい製品や機能を試し、できるだけ早く顧客に提供するこを可能にします。 製品の市場投入期間を短縮し、コードの品質を向上させ、より信頼性の高い製品やサービスのリリースを実現するために、開発チームはクラウド上でDevOpsの実践を採用しています。 継続的デプロイは、新しいソフトウェアリビジョンが自動的にビルドされ、テストされ、パッケージ化され、本番環境にリリースされる、DevOpsの実践です。 継続的デプロイにより、開発者は完全に自動化されたソフトウェアリリースプロセスを通じて機能や修正を出荷できます。開発者は、数週間や数ヶ月にわたる大規模なリリースをバッチ処理し、手動で展開する代わりに、新しいソフトウェアリビジョンが準備され次第、自動化されたプロセスを使用してアプリケーションのバージョンを1日に何回も配信することができます。クラウドコンピューティングがリソースの調達期間を短縮するのと同様に、継続的デプロイは新しいソフトウェアのリリースサイクルを数週間~数ヶ月から数分間に短縮します。 このスピードと敏捷性を活用することには、次のような多くの利点があります。 新機能やバグ修正を迅速にすることができる :  ソースコードリポジトリに置いてあるコードは、ビジネス価値をもたらしたり、顧客に利益をもたらすものではありません。新しいソフトウェアリビジョンをできるだけ早くリリースすることで、顧客はより迅速に利益を享受できるようになり、チームはより集中的なフィードバックを得ることができます。 変更セットが小さくなる : 大きな変更セットは、問題、バグ、およびその他の退化の根本原因を突き止める際に問題を引き起こします。より小さな変更セットを頻繁にリリースすることで、チームは発生した問題をより簡単に特定して修正することができます。 自働デプロイによりベストプラクティが促進される : ソースコードリポジトリにコミットされた変更は即座に自動プロセスによってデプロイすることができるため、チームはその変更が十分にテストされ、運用環境が厳重に監視されていることを確実にする必要があります。 継続的デプロイはどのように動くのか? 継続的デプロイは、ソフトウェアのリリースに関連する活動を調整する自動化されたパイプラインによって実行され、プロセスの可視性を提供します。プロセスの最中に、リリース可能な成果物が構築され、テストされ、パッケージ化され、本番環境にデプロイされます。リリース可能な成果物には、実行可能ファイル、スクリプトファイルのパッケージ、コンテナ、または最終的にプロダクションに配信されなければならないその他のコンポーネントが含まれます。 AWS CodePipelineは、新しいソフトウェアリビジョンができるたびにコードのビルド、テスト、およびデプロイを実行する継続的デプロイおよび継続的デリバリーのサービスです。 CodePipelineは、コード変更の統合、可視化を行い、ワークフローを介して最終的にユーザーの提供します。このパイプラインは、ソースコードリポジトリからのコード取得、ソースコードのビルド、テスト、および本番環境へのデプロイといったステージを定義し、これらのステージが順番に実行されること、障害が発生した場合には停止することを保証します。 CodePipelineはデリバリパイプラインを強化し、プロセスを統合しますが、ソフトウェア自体をビルドまたはテストする機能はありません。このステージでは、CodePipelineは、フルマネージドのビルドサービスであるAWS CodeBuildなど、いくつかのツールと統合されます。 CodeBuildはソースコードをコンパイルし、テストを実行し、デプロイする準備が整ったソフトウェアパッケージを生成します。このサービスは継続的なデプロイパイプラインの構築とテストに最適です。CodeBuildはDockerコンテナのビルドを含む多くの異なる種類のビルド環境をネイティブサポートしています。 コンテナは、予測可能で再現可能な環境を実現し、ある環境でテストされた変更が正常に展開できるという高いレベルの信頼性を提供するため、ソフトウェア提供の強力なメカニズムです。 AWSは、Dockerコンテナイメージを実行・管理するためのいくつかのサービスを提供しています。 Amazon ECSは、非常に高い拡張性とパフォーマンスを持つコンテナ管理サービスで、Amazon EC2インスタンスのクラスタ上でアプリケーションの実行環境を提供します。  Amazon ECRは、フルマネージドのDockerコンテナレジストリで、開発者は簡単にDockerコンテナイメージの格納、管理、およびデプロイが可能です。 最後に、CodePipelineはデプロイメントを容易にするために、AWS Elastic Beanstalk、AWS CodeDeploy、AWS OpsWorksや、AWS LambdaまたはAWS CloudFormationを使用した独自のカスタムデプロイメントコードやデプロイプロセスなど、いくつかのサービスと統合されます。これらのデプロイアクションを使用してパイプラインの最後に新しく構築された変更を本番環境にプッシュすることができます。 Amazon ECSへの継続的デプロイ これらのコンポーネントを組み合わせて、Dockerアプリケーションの継続的なデプロイパイプラインをECSに提供するためのリファレンスアーキテクチャを次に示します。 このアーキテクチャーは、CodePipelineを使用してECSおよびECRにコンテナをデプロイし、AWS上でフルマネージドの継続的デプロイパイプラインを構築する方法を示しています。この継続的デプロイのアプローチは、完全にサーバーレスであり、ソフトウェアの統合、ビルド、およびデプロイにマネージドサービスを使用します。 リファレンスアーキテクチャで作成されたパイプラインは、次のようになります。 このポストでは、このリファレンスアーキテクチャの各ステージについて説明します。開発者がランディングページの原稿を変更し、その変更をソースコードリポジトリにプッシュするとどうなるでしょう? まず、Source ステージでは、ソースコードリポジトリシステムにアクセスするための詳細がパイプラインに設定されます。リファレンスアーキテクチャでは、GitHubリポジトリにホストされているサンプルアプリケーションがあります。 CodePipelineはこのリポジトリをポーリングし、新しいコミットごとに新しいパイプラインを実行開始します。 […]

Read More

CodePipeline の更新 – CloudFormation スタックの継続的配信ワークフローの構築

2 つの AWS サービスを一緒に使用して生産性を高めるための新しい方法について記事を書き始めたときに、1980 年代の Reese ピーナッツバターカップの TV コマーシャルを思い出しました。2 つの有益なサービス (2 つのおいしい味) を組み合わせることで、さらにうまみのある新しいものが生まれます。 今日のチョコレート / ピーナッツバターの組み合わせは、 と が出会って生まれます。CodePipeline を使って、CloudFormation スタックの継続的配信パイプラインを構築できるようになりました。継続的配信を実行すると、コードの変更が毎回自動的にビルド、テストされ、本稼働環境へのリリースのために準備されます。ほとんどの場合、継続的配信のリリースプロセスには、手動と自動の承認ステップの組み合わせが含まれます。たとえば、自動化された一連のテストに合格したコードは、最終的な確認と承認のために開発マネージャーまたはプロダクトマネージャーにルーティングしてから、本稼働環境にプッシュできます。 この機能の重要な組み合わせにより、継続的配信の利点をすべて活用しながら、コードとしてのインフラストラクチャモデルを使用できるようになります。CloudFormation テンプレートを変更するたびに、CodePipeline はテストスタックを構築し、変更をテストして手動の承認を待ってから本稼働環境にプッシュするワークフローを開始できます。このワークフローでは多くの異なる方法でスタックを作成し、操作できます。 すぐ後で説明するように、ワークフローでは変更セットを生成して運用可能なスタックに適用する機能 (詳細については、「新機能 – AWS CloudFormation 用の変更セット」を参照) など、CloudFormation の高度な機能を活用できます。 セットアップ 私はこの機能の詳細について参照するため、CloudFormation テンプレートを使って継続的配信パイプラインをセットアップしました (これはコードとしてのインフラストラクチャの別の例です)。このテンプレート (こちらから入手可能で、詳細は こちらで参照可能) により、フル機能のパイプラインをセットアップできます。このテンプレートを使ってパイプラインを作成するときは、S3 バケットの名前とソースファイルの名前を指定します。 SourceS3Key は、S3 のバージョニングが有効な ZIP ファイルを指します。このファイルには、これから作成するパイプラインを介してデプロイされる CloudFormation テンプレート (WordPress のシングルインスタンスの例を使用) が含まれています。また、設定ファイルやパラメーターファイルなど、他のデプロイアーティファクトも含まれています。その例を次に示します。 [Create Stack] をクリックすると、わずか数秒で継続的配信ライン全体を準備できます。これを次に示します。 アクション この時点で、CloudFormation を使ってパイプラインをセットアップしました。これで準備が整ったので、このパイプラインで新しい […]

Read More

AWS 開発者用ツールのまとめ – CodeCommit、CodePipeline、CodeDeploy に追加した最近の機能強化

AWS 開発者用ツールは現代の DevOps を実施する上で役立ちます。概要については次をご覧ください (詳しくは「ソースコード管理やデプロイに使用できる新しい AWS ツール」を参照)。 は完全マネージド型のソースコード管理サービスです。既存の Git ツールやワークフローを引き続き使用しながら、安全でスケーラビリティに優れたプライベート Git リポジトリをホストするために同サービスを使用できます (詳細は「Introduction to AWS CodeCommit」のビデオをご覧ください)。 は インスタンスやオンプレミスサーバーでコードのデプロイを自動化します。デプロイの間にダウンタイムを回避しながら、すばやくアプリケーションを更新することができます (詳細は「Introduction to AWS CodeDeploy」のビデオをご覧ください)。 はリリースプロセスの効率化や自動化に使用することができる継続的配信サービスです。リポジトリ (CodeCommit または Git) でチェックインを行うと、ビルド、テスト、デプロイなどの操作が開始します (概要については「Introducing AWS CodePipeline」をご覧ください)。このビルドは CodeDeploy、、 のいずれかを使用して EC2 インスタンスまたはオンプレミスサーバーでデプロイすることができます。 こうしたサービスと既存のビルドやテストツールを組み合わせて使用することで、CodePipeline がまとめるエンドツーエンドソフトウェアのリリースパイプラインを作成することができます。 AWS は今年 Code* 製品に多数の機能強化を追加しました。今回は時期的にもそうした機能の概要をご説明するのにちょうど良い時期だろうと思い、このブログを公開することにしました。こうした機能強化の多くは開発者用ツールと AWS の他の部分を連携できるようにするので、今後もデプロイのプロセスを調整していくことが可能になります。 CodeCommit の機能強化 [codecommit_u] の新機能: リポジトリトリガー コードブラウジング コミット履歴 コミットの可視化 Elastic Beanstalk の統合 リポジトリトリガー – […]

Read More

AWS CodePipeline で、失敗したアクションのリトライが可能に

AWS CodePipeline で、アクション失敗後のリトライが出来るようになりました。以前は、手動でパイプライン全体をリスタートするか、失敗したアクションをリトライするために、パイプラインの Source Stage へ新たな変更をコミットする必要がありました。 CodePipeline 内でアクションがうまく完了しなかった場合、そのアクションは失敗し、パイプラインが停止し、パイプラインを通じた更新を止めてしまいます。本日から、パイプライン全体をリスタートする必要なく、失敗したアクションをリトライできます。 本機能はマネジメントコンソール、 AWS CLI, AWS SDK, API を使用して、利用可能です。リトライ機能の詳細は こちらをご覧下さい。 CodePipelineに関する詳細: 製品ページ ドキュメント 連携プロダクト 翻訳は江川が担当しました。原文はこちら。

Read More

AWS CodePipeline に OpeWorks とのインテグレーション機能が追加されました

AWS Pipeline のソフトウェア リリース パイプライン内で AWS OpsWorks をデプロイメント プロバイダとしてモデル化できるようになりました。更新されたアプリケーション コードのリリースと OpsWorks 内で実行されるアプリケーションとインスタンスのための Chef クックブックのリリースが自動化できます。 AWS OpsWorks は Chef を利用してアプリケーションのすべての形式とサイズに対する構成と運用を支援する構成管理サービスです。これによってアプリケーションのアーキテクチャ及びパッケージのインストール、ソフトウェアの構成、ストレージのようなリソースを含む個々のコンポーネントの仕様を定義することができます。 この機能は、CodePipeline コンソール、AWS CLI、または AWS SDKとAPI によって使い始めることができます。デプロイメント プロバイダとして OpsWorks を利用するパイプラインを作成する方法を学ぶには、こちらを参照してください。   CodePipeline のより詳細な情報は下記をご参照ください:   製品ページ ドキュメント 製品インテグレーション   (日本語訳はSA 福井 厚が担当しました。原文は以下にあります) https://aws.amazon.com/jp/about-aws/whats-new/2016/06/aws-codepipeline-adds-integration-with-aws-opsworks/

Read More

AWS CodePipeline が AWS CodeCommit との連携をサポートしました

AWS CodePipeline 内でモデル化されたソフトウェア リリース パイプラインのソース プロバイダとして AWS CodeCommit を選択できるようになりました。パイプラインのソース ステージで CodeCommit リポジトリとブランチを選択できます。 CodeCommit はフル マネージドなソース管理サービスで、企業がセキュアで高いスケーラビリティのプライベート Git リポジトリをホストすることを容易にします。CodeCommit は、独自のソース管理システムを運用する必要性やインフラストラクチャのスケーリングについて心配を不要にします。CodeCommit はソースコードからバイナリまであらゆる物のセキュアなストアとして利用することが可能で、既にお使いの Gitツールとともにシームレスに動作します。 この機能は CodePipeline コンソール、AWS CLIまたは AWS SDKを通じて利用を開始することができます。CodeCommit をソース プロバイダにしたシンプルな Pipeline の作成を学ぶには、こちらをご参照ください   CodePipeline のより詳細な情報は: 製品ページ ドキュメント プロダクト連携 日本語訳はSA 福井 厚が担当しました。原文はこちらです。 https://aws.amazon.com/jp/about-aws/whats-new/2016/04/aws-codepipeline-adds-integration-with-aws-codecommit/

Read More