Category: Developer Tools*


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

それほど遠く無い昔、今日多くのソフトウェア チームがアプリケーション開発で直面している、リリース期限までにソフトウェア プロジェクトを完成させ変化に対応するというような開発チームに私は所属していました。そこには新しいプロジェクト環境のセットアップ、チームメンバーのコラボレーション、各開発ビルドのコード変更、構成、ライブラリの継続的な追跡を行う日常的なタスクなどの課題がありました。 今日、企業がイノベーションと市場投入をより迅速に行うためには、開発チームがソフトウェアの作成、構築、展開をより簡単かつ効率的に行うことが不可欠になっています。

 

残念なことに、多くの組織は、より機敏で動的なソフトウェア開発プロセスを追求する上で、いくつかの重要な課題に直面しています。 ほとんどの新しいソフトウェア プロジェクトが直面する最初の課題は、開発者がコーディングを開始する前に完了しなければならない長いセットアップ プロセスです。 このプロセスには、IDEのセットアップ、適切なコード リポジトリへのアクセスの取得、および/またはビルド、テスト、および運用に必要なインフラストラクチャの識別が含まれます。

 

コラボレーションは、ほとんどの開発チームが直面しうる別の課題です。 プロジェクトのすべてのメンバーに安全な環境を提供するために、チームはさまざまなチームの役割とニーズに応じて別々のプロジェクトとツールを頻繁に設定する必要があります。 さらに、すべてのステークホルダーに、課題の更新、開発の進展、およびソフトウェアの問題の報告に関する情報を提供することは、時間がかかる可能性があります。

 

最後に、ほとんどの企業では、継続的インテグレーションと継続的デリバリに関するベストプラクティスを採用することで、ソフトウェア開発のスピードを高め、市場投入までの時間を短縮したいと考えています。 これらのアジャイル開発戦略を適用するには、企業が方法論についてチームを教育し、これらの新しいプロセスのためのリソースを設定するための時間を費やす必要があります。

 

AWS CodeStar:プレゼンテーション

 

開発チームがソフトウェアを構築する上での課題を緩和し、アプリケーションやソリューションをリリースするペースを向上させるために、AWS CodeStarを紹介します。

 

AWS CodeStarは、開発プロジェクト全体の設定を簡素化することにより、AWS上でアプリケーションの開発、構築、および展開を容易にするために設計されたクラウドサービスです。 AWS CodeStarには、ソフトウェア プロジェクトのコーディング、ビルド、テスト、デプロイ、および実行のためのプロジェクトとリソースのプロビジョニングを可能にする一般的な開発プラットフォーム用のプロジェクト テンプレートが含まれています。

 

AWS CodeStarサービスの主な利点は次の通りです:

  • Amazon EC2AWS Elastic Beanstalk、またはAWS Lambda用のテンプレートを使用して、5つの異なるプログラミング言語を使用して新しいプロジェクトを簡単に作成できます。 JavaScript、Java、Python、Ruby、およびPHPをサポートします。 テンプレートを選択すると、サービスはプロジェクトとアプリケーションに必要な基盤となるAWSサービスをプロビジョニングします。
  • ソフトウェアチーム全体に対するアクセスおよびセキュリティ ポリシー管理の統一されたエクスペリエンスを提供します。プロジェクトは、適切なIAMコントロール ポリシーで自動的に構成され、安全なアプリケーション環境を確保します。
  • コードのコミット、ビルドの結果、デプロイメント アクティビティなど、さまざまなアクティビティを追跡するための事前設定されたプロジェクト管理ダッシュボード。
    素早い立ち上げと実行に役立つ実行可能なサンプルコードは、Visual Studio、Eclipse、またはGitをサポートする任意のコード エディタなどのお好きなIDEで使用できます。
  • AWS CodeCommitAWS CodeBuildAWS CodePipeline、およびAWS CodeDeployを使用して、自動的に構成された各プロジェクトの継続的なデリバリ パイプライン。
  • CodeStarコンソールから課題管理とトラッキングを直接行えるAtlassian JIRA Softwareとの統合

 

AWS CodeStarによって、開発チームはソフトウェアのデプロイとバグ修正のスピードアップだけでなく、開発者が顧客の要望やニーズに一層合ったソフトウェアを構築できるようにするためのアジャイル ソフトウェア開発ワークフローを構築することができます。

 

AWS CodeStarを使用したレスポンシブな開発ワークフローの例を以下に示します:

CodeStarへの旅

 

AWS CodeStarサービスについて少し理解できたので、このサービスを使ってWebアプリケーションプロジェクトを設定しましょう。 まず、AWS CodeStar Consoleに行き、[Start a project]ボタンをクリックします。

適切なIAM権限を設定していない場合、AWS CodeStarはあなたのためにAWSリソースを管理する権限を要求するダイアログボックスを表示します。 [Yes、grant permissions]ボタンをクリックして、AWS CodeStarに他のAWSリソースへの適切な権限を与えます。

ところが、IAMユーザーに正しいポリシーを適用していないため、AWS CodeStarに対する管理者権限がないという警告が表示されました。 AWS CodeStarでプロジェクトを作成する場合は、IMSユーザーにAWSCodeStarFullAccess管理ポリシーを適用するか、すべてのAWSサービスに対して完全な権限を持つIAM管理ユーザーを持っている必要があります。

IAMで前述の権限を追加したので、このサービスを使ってプロジェクトを作成することができます。 単に [Create a new project]ボタンをクリックするだけで、AWS CodeStarサービスのハブに移動します。

この時点でソフトウェア開発のニーズに応じて、さまざまな環境を提供するために、20種類以上のAWS CodeStarプロジェクトテンプレートが用意されています。 各プロジェクトテンプレートは、プロジェクトの展開に使用されるAWSサービス、サポートされているプログラミング言語、実装されている開発ソリューションの種類の説明が記述されています。 AWS CodeStarは現在、Amazon EC2、AWS Lambda、AWS Elastic BeanstalkのAWSサービスをサポートしています。 これらのプロジェクト テンプレートは、あらかじめ設定されたAWS CloudFormationテンプレートを使用して、ボタンをクリックするだけで、マイクロサービス、Alexaスキル、Webアプリケーションなどのソフトウェア開発プロジェクトを作成できます。

私の最初のAWS CodeStarプロジェクトでは、Node.js / AWS Lambdaプロジェクトテンプレートを使用して、Node.jsとAWS Lambdaを使用してサーバーレスWebアプリケーションを構築しましょう。

このテンプレートによってAWS CodeStarがAWS CodeBuild、AWS CloudFormation、Amazon CloudWatchなどのサービスと連携するAWS CodePipelineを含む、開発プロジェクトに必要なすべてのツールとサービスを設定することに気づくでしょう。 新しいAWS CodeStarプロジェクトの名前をTaraWebProjectにして、Create Projectをクリックします。

ここではAWS CodeStarを初めて作成したので、AWS CodeStarのユーザー設定について質問するダイアログが表示されます。 表示名のテキストボックスにTaraと入力し、メールテキストボックスに自分のメールアドレスを追加します。 この情報は、プロジェクトの他のメンバーにどのように表示されるかを示しています。

次に、プロジェクトコードの編集方法を選択します。 Visual Studio IDEを使用してTaraWebProjectプロジェクトコードを編集することに決めました。 Visual Studioでは、プロジェクトコードの編集中にAWS Toolkit for Visual Studio 2015を使用してAWSリソースにアクセスするように設定することがポイントです。 この画面では、AWS CodeStarがプロジェクト用に設定したAWS CodeCommit Gitリポジトリへのリンクも表示されます。

ソフトウェア開発プロジェクトのプロビジョニングとツールのセットアップが完了しました。 私のソフトウェアプロジェクトであるTaraWebProjectのAWS CodeStarダッシュボードを提示されているので、プロジェクトのリソースを管理することができます。 これには、コードのコミット、チームメンバーシップとwiki、継続的なデリバリ パイプライン、Jiraの課題トラッキング、プロジェクトステータス、およびその他の適用可能なプロジェクトリソースなどのリソース管理が含まれます。

AWS CodeStarが本当にすばらしいのは、サーバレスWebアプリケーションの開発を開始できる実用的なサンプルプロジェクトを提供することです。 私の新しいWebアプリケーションのサンプルを見るには、ダッシュボードのApplication endpointsセクションに行き、提供されたリンクをクリックします。

新しいブラウザウィンドウが開き、開発を開始するためにAWS CodeStarが生成したサンプルWebアプリケーションが表示されます。サンプルアプリケーションのクールな機能は、サンプルアプリのバックグラウンドが時刻に基づいて色が変わることです。

サンプルWebサイトの構築に使用したコードを見てみましょう。 コードを表示するには、AWS CodeStarコンソールのTaraWebProjectダッシュボードに戻り、サイドバーメニューからCodeオプションを選択します。

AWS CodeCommitコンソールのtarawebproject Gitリポジトリに移動します。 ここから自分のWebアプリケーションのコード、リポジトリで行われたコミット、コミットやブランチの比較、リポジトリのイベントに応じたトリガーの作成を手動で行うことができます。

これによりAWSでホストされているWebアプリケーションの開発を開始することができます。 AWS CodeStarをVisual Studioに統合したので、コードを変更するためにIDEを使用してWebアプリケーションを更新することができます。これによってプロビジョニングされたコード リポジトリにコミットするたびにTaraWebProjectに含まれるコードを毎回自動的更新できます。

AWS CodeStarのTaraWebProjectダッシュボードには、コードを操作するためにツールをプロジェクト リポジトリに接続していますというメッセージがあります。 Visual StudioをIDEとして既に選択していますが、Connect ToolsボタンをクリックしてこのIDEに接続する手順を確認してみましょう。

再度、どのIDEを選択するかを選択できる画面を参照します。 Visual Studio、Eclipse、またはコマンドライン ツールがプロジェクト コードの編集に使用できます。 開発プロジェクトの作業中はいつでもIDEの選択肢を変更するオプションがあることが重要です。 さらに、HTTPSとSSH経由のGitでAWS CodeCommitリポジトリに接続できます。 各プロトコルの適切なリポジトリURLを取得するには、Code repository URLドロップダウンを選択してHTTPSまたはSSHを選択し、結果のURLをテキストフィールドから単にコピーするだけです。

Visual Studioを選択した後、CodeStarはVisual Studioとの統合に必要な手順に進みます。 これには、Visual Studio用のAWS Toolkitのダウンロード、Team ExplorerをAWS CodeCommitを介してAWS CodeStarに接続すること、および変更をリポジトリにプッシュする方法が含まれます。

Visual StudioをAWS CodeStarプロジェクトに正しく接続したら、AWS CodeStar TaraWebProject CodeStarダッシュボードに戻り、Webアプリケーションで作業しているチームメンバーの管理を開始します。 Setup your teamを選択して、プロジェクトチームページに行くことができます。

私のTaraWebProjectプロジェクトチームページでは、Add team member ボタンを選択し Select userドロップダウンをクリックして、チームメンバーのJeffを追加します。 チームメンバーは自分のアカウントのIAMユーザーでなければならないので、JeffのIAMアカウントを作成するには、Create new IAM userリンクをクリックします。

Create IAM user ダイアログボックスが表示されたら、チームメンバー(この場合はJeff Barr)のIAMユーザー名、表示名、電子メールアドレスを入力します。 Jeffに付与できるプロジェクトロールには、所有者、コントリビュータ、ビューアの3種類があります。 TaraWebProjectアプリケーションでは、Contributor プロジェクト ロールを付与し、Remote accessチェックボックスをオンにしてリモートアクセスできるようにします。 ここでは、[Create]ボタンをクリックしてJeffのIAMユーザーアカウントを作成します。

これにより、新しいIAMユーザーの作成を確認するIAMコンソールが表示されます。 IAMユーザー情報と許可されたアクセス許可を確認した後、[Create user]ボタンをクリックして、TaraWebProject用のJeffのIAMユーザーアカウントの作成を完了します。

Jeffのアカウントを正常に作成したら、Jeffのログイン資格情報を電子メールで送信するか、credentials.csvファイルをダウンロードすることが重要です。これらの資格情報を再度取得することはできません。 現在のログイン資格情報を取得せずにこのページを終了すると、Jeffの新しい資格情報を生成する必要があります。 [Close]ボタンをクリックすると、AWS CodeStarコンソールに戻ります。

JeffBarr-WebDev IAMロールを選択し、[Add]ボタンをクリックすることで、TaraWebProjectのチームメンバーとしてJeffを追加することができます。


私はジェフをAWS CodeStarプロジェクトのチームメンバーとして追加し、Webアプリケーションを構築する際にTaraWebProjectのチームコラボレーションを可能にしました。

私がAWS CodeStarサービスを本当に気に入っているのは、TaraWebProjectダッシュボードから自分のプロジェクトのすべてのアクティビティを監視できるからです。 アプリケーションのアクティビティや最近のコードのコミットを見ることができ、ビルドの結果、コードの変更、展開などのプロジェクトアクションの状態を1つの包括的なダッシュボードで追跡できます。 AWS CodeStarはダッシュボードのApplication activityセクションでAmazon CloudWatchと結びつけ、AWS CodePipelineに連携したContinious Deploymentセクションでビルドとデプロイメントのステータスに関するデータを提供し、Commit HistoryセクションでAWS CodeCommitのの最新のGit コードのコミットを表示します。


まとめ

AWS CodeStarサービスの旅で、AWSサービスを使用してTaraWebProjectソフトウェアプロジェクトのコーディング、ビルド、テスト、デプロイメント用に開発ツールチェーン全体をプロビジョニングしたサーバーレスWebアプリケーションを作成しました。 驚くべきことに、私はアプリケーションをリリースする日々のソフトウェア開発活動を管理するためのAWS CodeStarを使用するメリットについて、まださらっと表面をなめただけです。

AWS CodeStarを使用すると、AWS上でアプリケーションを迅速に開発、構築、および展開できます。 AWS CodeStarは、統一されたユーザーインターフェースを提供し、ソフトウェア開発活動を1か所で簡単に管理できるようにします。 AWS CodeStarでは、さまざまなテンプレートからAWS LambdaAmazon EC2AWS Elastic Beanstalkを使用してプロジェクトを設定することができます。 AWS CodeCommitAWS CodeBuildAWS CodePipeline、およびAWS CodeDeployを使用して、プロジェクト管理ダッシュボード、自動化された継続的デリバリ パイプライン、およびGitコードリポジトリが事前設定されており、開発者は最新のアジャイル ソフトウェア開発のベストプラクティスを実装できます。各AWS CodeStarプロジェクトは、Gitをサポートする一般的なIDEで使用できる実用的なコードサンプルを提供することにより、開発者に開発の最前線を提供します。加えてAWS CodeStarのAtlassian JIRA Softwareとの組み込みの統合機能によって、AWS CodeStarコンソールからダイレクトに連携するプロジェクト管理と課題追跡システムをソフトウェアチームに提供します。

AWS CodeStarサービスを使用して、AWSで新しいソフトウェア プロジェクトを開発することができます。 詳細については、AWS CodeStarの製品ページとAWS CodeStarのユーザーガイドのドキュメントを参照してください。
Tara

 

原文 New- Introducing AWS CodeStar – Quickly Develop, Build, and Deploy Applications on AWS (翻訳;SA 福井 厚)

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

AWS X-Ray を最初に紹介したのは AWS re:Invent での「AWS X-Ray – 分散アプリケーションの中を見てみよう (AWS X-Ray – See Inside Your Distributed Application)」というタイトルのブログ投稿でした。AWS X-RayAmazon EC2 インスタンス、Amazon ECS コンテナ、マイクロサービス、AWS データベースサービス、AWS メッセージングサービスをトラバースする実行として、アプリケーションに対して行われたリクエストをトレースできるようにします。これは開発および本番環境用に設計されており、シンプルな 3 層アプリケーションや何千ものマイクロサービスで形成されたアプリケーションを処理することができます。去年公開したブログでも説明しましたが、AWS X-Ray はリクエストのエンドツーエンドのトレースや、代表的なサンプルのトレースセットの記録、サービスのマップ表示、データのトレース、パフォーマンス問題やエラーの分析を行えるようにします。これにより、アプリケーションとその基盤サービスがどのように動作しているか把握することができるため、問題の根本的な原因を識別し対処することができます。詳細については、X-Ray の機能を詳しく説明した過去のブログをご覧ください。AWS X-Ray のプレビューバージョンは re:Invent でリリースし、興味を示した開発者やアーキテクトが使用できるようにご招待しました。本日より、同サービスの一般提供を開始しました。US East (Northern Virginia)US West (Northern California)US East (Ohio)US West (Oregon)Europe (Ireland)Europe (Frankfurt)South America (Brazil)Asia Pacific (Tokyo)Asia Pacific (Seoul)Asia Pacific (Sydney)Asia Pacific (Sydney)Asia Pacific (Mumbai) リージョンで今すぐご利用いただけます。

新しい Lambda 統合 (プレビュー)
本日よりご利用いただけるプレビューバージョンには、先のプレビュー実施時に行ったサービスの微調整と AWS Lambda 統合が含まれています。これにより、Lambda のデベロッパーが AWS X-Ray を使用して関数の実行やパフォーマンスの可視性を得ることが可能になりました。これまでは、Lambda のユーザーがアプリケーションのレイテンシーの詳細やスローダウンの原因を突き止めたい場合、またはタイムアウトをトラブルシュートしたい場合はカスタムロギングや分析に頼る必要がありました。この新しい統合を使用するには、対象となる関数に実行ロールを指定してください。この実行ロールは、関数が X-Ray に書き込むことを許可し、関数をベースにトレースすることを可能にします (コンソールを使用して新しい関数を作成した場合、適切な許可が自動的に指定されます)。次に X-Ray サービスマップを使用して Lambda 関数、EC2 インスタンス、ECS コンテナなどでどのようにリクエストが動作しているか確認します。興味のあるサービスやリソースを識別、拡大、タイミング情報を調査し問題を解決します。Lambda 関数への各呼び出しは 2 つ以上のノードを X-Ray マップで生成します。Lambda サービス – このノードは Lambda で使用した時間を表します。ユーザー関数 – このノードは Lambda 関数の実行時間を表します。ダウンストリームサービスの呼び出し – これらのノードは Lambda 関数による他のサービスへの呼び出しを表します。詳細については「Lambda で X-Ray を使用する (Using X-Ray with Lambda)」をご覧ください。

今すぐ利用可能
X-Ray の使用量に対する料金は 2017 年 5 月 1 日から開始します。料金は記録したトレース数と分析数に基づきます (各トレースはアプリケーションに対して行われたリクエストを表します)。毎月無料で記録できるトレース数は 100,000 件、また 1,000,000 トレースを取得またはスキャンすることができます。それ以上の場合は記録したトレース数 1 万件につき 5 USD、また分析用に取得したトレース数 1 万件につき 0.50 USD が課金されます。詳細は AWS X-Ray 料金表ページをご覧ください。記録済みまたはアクセスしたトレース数を確認するには AWS 請求コンソールをご覧ください (データ収集は 2017 年 3 月 1 日に開始しました)。AWS X-Ray と新しい Lambda 統合をぜひご覧ください。ご感想をお待ちしています!

Jeff;

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

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

  • 異なる3つのデータセットを適合させて索引付けし、検索可能にします。
  • 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。
  • Amazon AthenaAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

(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はこのリポジトリをポーリングし、新しいコミットごとに新しいパイプラインを実行開始します。 GitHubに加えて、CodePipelineは、AWS CodeCommitのGitリポジトリやAmazon S3に格納されたバージョン管理されたオブジェクトなどのソースロケーションもサポートしています。新しいビルドはそれぞれソースコードリポジトリから取得され、zipファイルとしてパッケージ化され、S3に格納され、パイプラインの次のステージに送られます。

Sourceステージでは、Amazon S3に格納されているテンプレートも定義されます。これは、アプリケーションのビルドが成功した後に、デプロイメントステージで使用されるデプロイメント環境を定義するテンプレートです。

Build ステージではCodeBuildを使用して、最新のソースコードに基づいて新しいDockerコンテナイメージを作成し、ECRリポジトリにプッシュします。 CodePipelineは、Jenkins、CloudBees、Solano CI、TeamCityなどのサードパーティのビルドシステムとも統合されています。

最後に、DeployステージではCloudFormationを使用して、新しく作成されたDockerコンテナイメージを指す新しいタスク定義リビジョンを作成し、新しいタスク定義リビジョンを使用するためにECSサービスを更新しています。こうすることで、ECSは新しいDockerコンテナをECRから取得し、サービスを再起動することによってデプロイを開始します。

パイプラインのステージがすべてグリーンになったら、Webブラウザでアプリケーションをリロードして、開発者の原稿の変更を本番環境で確認することができます。これは人手での作業は何もしなくても自動的に実行されます。

このパイプラインはすでにプロダクション状態であり、ソースコードリポジトリから新しいコードを取得し、チームがプロダクションにプッシュする将来の変更を出荷する用意ができています。また、拡張可能なので、新しいステップを追加して追加のステージを含めることもできます。たとえば、新しいコードリビジョンが本番環境に安全にデプロイされることを確認するために、テストステージを組み込んでユニットテストと受入テストを実行することができます。デプロイ後、新しいバージョンが稼動したことおよび、本番環境にデプロイされた変更セットの詳細について、電子メールまたはSlackチャンネルでチームにアラートを送るための通知ステップも追加することができます。

最後に

私たちはこのアプローチを使用してあなた方がどのような種類のアプリケーションをユーザーに提供できるのか、またそれが製品開発プロセスにどのような影響を及ぼすのかを見せていただけることを楽しみにしています。クラウドは俊敏性において大きなメリットを発揮し、継続的デプロイなどの技術を実装する能力は、競争上の大きな利点を生み出します。

GitHub上のAWS Labs EC2 Container Service – Reference Architecture: Continuous Deploymentリポジトリには、独自の継続的デプロイパイプラインを起動するために必要なすべてのものを含むAWS CloudFormationテンプレートがあります。

ご質問、ご意見、ご提案がありましたら是非お知らせください!

(翻訳はSA千葉が担当しました。原文はこちら)

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

2 つの AWS サービスを一緒に使用して生産性を高めるための新しい方法について記事を書き始めたときに、1980 年代の Reese ピーナッツバターカップの TV コマーシャルを思い出しました。2 つの有益なサービス (2 つのおいしい味) を組み合わせることで、さらにうまみのある新しいものが生まれます。

今日のチョコレート / ピーナッツバターの組み合わせは、AWS CodePipelineAWS CloudFormation が出会って生まれます。CodePipeline を使って、CloudFormation スタックの継続的配信パイプラインを構築できるようになりました。継続的配信を実行すると、コードの変更が毎回自動的にビルド、テストされ、本稼働環境へのリリースのために準備されます。ほとんどの場合、継続的配信のリリースプロセスには、手動と自動の承認ステップの組み合わせが含まれます。たとえば、自動化された一連のテストに合格したコードは、最終的な確認と承認のために開発マネージャーまたはプロダクトマネージャーにルーティングしてから、本稼働環境にプッシュできます。

この機能の重要な組み合わせにより、継続的配信の利点をすべて活用しながら、コードとしてのインフラストラクチャモデルを使用できるようになります。CloudFormation テンプレートを変更するたびに、CodePipeline はテストスタックを構築し、変更をテストして手動の承認を待ってから本稼働環境にプッシュするワークフローを開始できます。このワークフローでは多くの異なる方法でスタックを作成し、操作できます。

すぐ後で説明するように、ワークフローでは変更セットを生成して運用可能なスタックに適用する機能 (詳細については、「新機能 – AWS CloudFormation 用の変更セット」を参照) など、CloudFormation の高度な機能を活用できます。

セットアップ
私はこの機能の詳細について参照するため、CloudFormation テンプレートを使って継続的配信パイプラインをセットアップしました (これはコードとしてのインフラストラクチャの別の例です)。このテンプレート (こちらから入手可能で、詳細は こちらで参照可能) により、フル機能のパイプラインをセットアップできます。このテンプレートを使ってパイプラインを作成するときは、S3 バケットの名前とソースファイルの名前を指定します。

SourceS3Key は、S3 のバージョニングが有効な ZIP ファイルを指します。このファイルには、これから作成するパイプラインを介してデプロイされる CloudFormation テンプレート (WordPress のシングルインスタンスの例を使用) が含まれています。また、設定ファイルやパラメーターファイルなど、他のデプロイアーティファクトも含まれています。その例を次に示します。

[Create Stack] をクリックすると、わずか数秒で継続的配信ライン全体を準備できます。これを次に示します。

アクション
この時点で、CloudFormation を使ってパイプラインをセットアップしました。これで準備が整ったので、このパイプラインで新しい CloudFormation アクションを使用する方法をご覧いただくことができます。

2 番目のステージである、TestStage に注目しましょう。このステージは最初のステージによってトリガーされ、CloudFormation を使ってテストスタックを作成します。

このスタックは ZIP の test-stack-configuration.json ファイルのパラメーター値を使って作成されます。CloudFormation アクションごとに異なる設定ファイルを使用できるので、同じテンプレートをテストと本稼働に使用できます。

スタックが起動して実行されると、ApproveTestStack ステップを使って手動の承認を待ちます (“Waiting for approval above.” と表示されます)。私は開発マネージャーの役割を果たし、テストスタックが予期どおり動作、実行されることを確認したら、それを承認します。

承認後は、DeleteTestStack ステップによりテストスタックが削除されます。

これで、本稼働環境へのデプロイの準備がほぼ整いました。ProdStage は CloudFormation 変更セットを作成し、それを手動の承認用に送信します。このステージでは ZIP の prod-stack-configuration.json ファイルからのパラメーター値を使用します。これらのパラメーターを使って、小さい EC2 インスタンスで適切なサイズのテスト環境を起動し、同じテンプレートから大規模な実稼働環境を起動できます。

ここで私は上役の役割を果たし、実稼働サイトの起動と運用を維持する責任を負います。実稼働環境へのデプロイで何が起こるかを確実に理解するため、変更セットを確認します。パイプラインを実行するのはこれが初めてであるため、変更セットは EC2 インスタンスとセキュリティグループが作成されることを示します。

次に、私はこれを承認します。

変更セットが承認されると、ExecuteChangeSet ステップの既存の実稼働スタックに適用されます。既存のスタックに変更を適用すると、既存のリソースは可能な場合は継続して機能し、アプリケーションの完全な再起動を回避します。通常、これはスタック全体を置き換えるよりも効率的で、破壊的ではありません。インメモリキャッシュのウォームアップ状態が維持され、コールドスタートアクティビティで発生する可能性のあるバーストが回避されます。

変更の実装
HTTPS のサポートを決定するとします。これを行うには、アプリケーションのセキュリティグループにポート 443 を追加する必要があります。CloudFormation テンプレートを編集し、新しい ZIP にこれを配置して、S3 にアップロードします。テンプレートに追加したコードは次のとおりです。

      - CidrIp: 0.0.0.0/0
        FromPort: '443'
        IpProtocol: tcp
        ToPort: '443'

次にコンソールに戻り、CodePipeline がすでに変更を検出してパイプラインが動作するよう設定したことを確認します。

パイプラインはもう一度実行されます。テストスタックを承認し、変更セットを点検して、既存のセキュリティグループを変更することを確認します。

次に進む前に、1 つ注意事項があります。パイプラインの CloudFormation テンプレートによって IAM ロールが作成され、これを使ってテストおよびデプロイスタックを作成します (これは新機能です。詳細については、「AWS CloudFormation サービスロール」を参照してください)。最適な結果を得るには、パイプラインを削除する前にスタックを削除します。これを行わない場合は、スタックを削除するためにロールを再作成する必要があります。

その他の情報
スペースと時間が足りなくなってきましたが、この新機能のその他の側面のついて、いくつか簡単に説明します。

パラメーターの上書き – CloudFormation アクションを定義する際に、テンプレートに対して定義されるパラメーター値の追加の制御が必要になる場合があります。これを行うには、[Advanced] ペインを開き、必要なパラメーター値の上書きを入力します。

アーティファクトのリファレンス – 状況によっては、以前のステージのパイプラインで作成されたアーティファクトの属性を参照する必要が生じます。たとえば、パイプラインの早い段階で Lambda 関数を S3 バケットにコピーし、結果として生じるアーティファクト LambdaFunctionSource を呼び出すとします。パラメーターの上書きを使って属性からバケット名とオブジェクトキーを取得する方法を次に示します。

{
  "BucketName" : { "Fn::GetArtifactAtt" : ["LambdaFunctionSource", "BucketName"]},
  "ObjectKey" : { "Fn::GetArtifactAtt" : ["LambdaFunctionSource", "ObjectKey"]}
}

JSON パラメーターへのアクセス – 新しい Fn::GetParam 関数を使って、アーティファクトに含まれる JSON 形式ファイルから値を取得できます。

Fn:GetArtifactAttFn::GetParam は、パラメーターの上書き内で使用されるよう設計されています。

S3 バケットのバージョニング – 私のパイプライン (Source アクション) の最初のステップでは、S3 バケットのオブジェクトを参照します。オブジェクトの S3 バージョニングを有効にして、変更ごとにテンプレートの新しいバージョンをアップロードします。

ソースとして S3 を使用する場合は、バージョニングを使用する必要があります (既存のオブジェクトに対する新しいオブジェクトのアップロードはサポートされません)。AWS CodeCommit または GitHub レポジトリをソースとして使用することもできます。

パイプラインウィザードの作成
私は、CloudFormation テンプレートを使ってパイプラインを作成することで、このブログ投稿を開始しました。コンソールで [Create pipeline] をクリックし、ウィザードを使って最初のパイプラインを構築することもできます (ソース、ビルド、およびベータデプロイステージを使用)。このウィザードでは、デプロイプロバイダーとして CloudFormation を選択することもできます。ベータデプロイステージでスタックや変更セットを作成または更新できます。

今すぐご利用可能
この新機能は今すぐご利用可能で、すぐに使用を開始することができます。詳細については、CodePipeline ドキュメントの「AWS CodePipeline を使用した継続的配信」を参照してください。

Jeff;

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

AWS 開発者用ツールは現代の DevOps を実施する上で役立ちます。概要については次をご覧ください (詳しくは「ソースコード管理やデプロイに使用できる新しい AWS ツール」を参照)。

AWS CodeCommit は完全マネージド型のソースコード管理サービスです。既存の Git ツールやワークフローを引き続き使用しながら、安全でスケーラビリティに優れたプライベート Git リポジトリをホストするために同サービスを使用できます (詳細は「Introduction to AWS CodeCommit」のビデオをご覧ください)。

AWS CodeDeployAmazon Elastic Compute Cloud (EC2) インスタンスやオンプレミスサーバーでコードのデプロイを自動化します。デプロイの間にダウンタイムを回避しながら、すばやくアプリケーションを更新することができます (詳細は「Introduction to AWS CodeDeploy」のビデオをご覧ください)。

AWS CodePipeline はリリースプロセスの効率化や自動化に使用することができる継続的配信サービスです。リポジトリ (CodeCommit または Git) でチェックインを行うと、ビルド、テスト、デプロイなどの操作が開始します (概要については「Introducing AWS CodePipeline」をご覧ください)。このビルドは CodeDeploy、AWS Elastic BeanstalkAWS OpsWorks のいずれかを使用して EC2 インスタンスまたはオンプレミスサーバーでデプロイすることができます。

こうしたサービスと既存のビルドやテストツールを組み合わせて使用することで、CodePipeline がまとめるエンドツーエンドソフトウェアのリリースパイプラインを作成することができます。

AWS は今年 Code* 製品に多数の機能強化を追加しました。今回は時期的にもそうした機能の概要をご説明するのにちょうど良い時期だろうと思い、このブログを公開することにしました。こうした機能強化の多くは開発者用ツールと AWS の他の部分を連携できるようにするので、今後もデプロイのプロセスを調整していくことが可能になります。

CodeCommit の機能強化
[codecommit_u] の新機能:

  • リポジトリトリガー
  • コードブラウジング
  • コミット履歴
  • コミットの可視化
  • Elastic Beanstalk の統合

リポジトリトリガー – リポジトリで変更があるたびに通知を送信したりコードを実行するリポジトリトリガーを作成することができます (これは場合によって webhooks と呼ばれることもあります — ユーザー定義の HTTP コールバック)。こうしたフックは開発のワークフローをカスタマイズしたり自動化することを可能にします。トピックまたは Lambda 関数を呼び出して Amazon Simple Notification Service (SNS) に通知を配信することもできます。

コードブラウジングコンソールでコードをブラウズすることができます。これにはソースコードのツリーとコードでのナビゲーションも含まれています。

コミット履歴 – リポジトリのコミット履歴を表示できます (私の場合はあまり動きがなかったため 2015 年の履歴が表示されています)。

コミットの可視化 – リポジトリのコミット履歴をグラフィカル表示にすることができます。

Elastic Beanstalk の統合Elastic Beanstalk を使用する CodeCommit リポジトリで、Elastic Beanstalk 環境で実施するデプロイ用のプロジェクトコードを保存できます。

CodeDeploy の機能強化
CodeDeploy の新機能:

  • CloudWatch イベントの統合
  • CloudWatch アラームと自動デプロイメントロールバック
  • プッシュ通知
  • 新しいパートナーの統合

CloudWatch イベントの統合 – インスタンスの状態または AWS Lambda 関数、Amazon Kinesis ストリーム、Amazon Simple Queue Service (SQS) キュー、SNS トピックのデプロイで起きた変更をストリームするように CloudWatch イベントを設定すると、デプロイで起きた変更を Amazon CloudWatch イベントで監視したり対応することができます。変更によりトリガーするワークフローやプロセスを構築することができます。デプロイに失敗した場合に EC2 インスタンスを自動的に終了させたり、Slack チャネルにメッセージをポストする Lambda 関数を呼び出すことができます。

CloudWatch アラームと自動デプロイメントロールバック – CloudWatch アラームは別の方法でデプロイ監視を可能にします。CodeDeploy で管理しているインスタンスまたは Auto Scaling グループのメトリックスを監視できるほか、決められた期間にしきい値を超えた場合は再起動、終了または復元することでデプロイを停止したり、インスタンスの状態を変更することができます。デプロイに失敗した場合や CloudWatch アラームへの対応として自動的にデプロイをロールバックすることもできます。

プッシュ通知 – デプロイに関するイベントについて Amazon SNS からプッシュ通知を受信し、デプロイの状態やプログレスを確認することができます。

新しいパートナーの統合 – AWS の CodeDeploy パートナーは AWS 製品と自社製品を連結できるように努めています。最近のリリース:

CodePipeline の機能強化
[codepipeline_u] の新機能:

  • AWS OpsWorks 統合
  • Lambda 関数のトリガー
  • 手動の承認アクション
  • コミット済み変更の情報
  • 新しいパートナーの統合

AWS OpsWorks 統合 – CodePipeline でモデルしたソフトウェアリリースパイプラインで AWS OpsWorks をデプロイプロバイダとして選択することができます。

[codepipeline_u] で [opsworks_u] を使用するように設定して、カスタム Chef cookbooks のレシピでコードをデプロイすることもできます。

Lambda 関数のトリガー – ソフトウェアリリースパイプラインの操作のひとつとして Lambda 関数をトリガーできるようになりました。Lambda では、ほぼすべてのタスク実行を可能にする関数を記述できるので、パイプラインを好きなようにカスタマイズすることができます。

手動承認アクション – ソフトウェアリリースパイプラインで手動承認アクションを追加できるようになりました。必要な IAM アクセス権限を持つ人物がコード変更を承認または拒否するまで実行が一時停止します。

コミット済み変更の情報 – ソフトウェアリリースパイプラインを経由するコードに対するコミット済み変更の情報を表示できるようになりました。

 

新しいパートナー統合 – AWS の CodePipeline パートナーは AWS 製品と自社製品を連結できるように努めています。最近のリリース:

新しいオンラインコンテンツ
最新の開発手法について皆さんにご理解いただけるように、いくつかの新しい入門用資料をご提供しています。

ご覧いただきありがとうございました。
今回は AWS の開発用ツールに新しく追加された機能概要をご紹介しました。いかがでしたか?

皆さんが継続的配信を実際に体験できるように、私の同僚が新たに Pipeline スターターキットを作成しました。このキットには、EC2 インスタンスを内部に含む VPC 作成のテンプレート、アプリケーションペア (各インスタンス用、CodeDeploy でデプロイ)、サンプルアプリケーションを構築してデプロイするパイプライン、その他必要な IAM サービスとインスタンスロールが含まれています。

Jeff;

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

AWS CodePipeline で、アクション失敗後のリトライが出来るようになりました。以前は、手動でパイプライン全体をリスタートするか、失敗したアクションをリトライするために、パイプラインの Source Stage へ新たな変更をコミットする必要がありました。

CodePipeline 内でアクションがうまく完了しなかった場合、そのアクションは失敗し、パイプラインが停止し、パイプラインを通じた更新を止めてしまいます。本日から、パイプライン全体をリスタートする必要なく、失敗したアクションをリトライできます。

本機能はマネジメントコンソール、 AWS CLI, AWS SDK, API を使用して、利用可能です。リトライ機能の詳細は こちらをご覧下さい。

CodePipelineに関する詳細:

翻訳は江川が担当しました。原文はこちら

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/

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/

【新機能】AWS CodeCommit の通知

AWS CodeCommit は、セキュアで高度にスケーラブルなプライベート Git リポジトリを容易にホストできるフルマネージドなソース管理サービスです。今回リポジトリ トリガーを追加することで CodeCommit はさらに有用なサービスになりました。これらのトリガーを利用することで、既にあるユニット テストやデプロイメント ツールをソースコード管理ワークフローに統合することができます。トリガーは効率的でスケーラブルなので、変更をポーリングするように構築されたモデルよりもより広範囲に適用可能です。継続的インテグレーション継続的デリバリをベースとした開発方法論に向かって進むために、これらのトリガーが有用であることがお分かり頂けると思います。

 

通知に関するすべて

CodeCommit のリポジトリごとに10個までのトリガーを作成することができます。トリガーはコードのプッシュ、ブランチ/タグの作成、ブランチ/タグの削除を含むリポジトリのアクションに対する応答として起動されます。トリガーはリポジトリの特定のブランチやすべてのブランチに対してセットできます。

トリガーによって Amazon Simple Notification Service (SNS) トピックの送信や AWS Lambda ファンクションの起動が可能です。また個々のトリガーはカスタム データで拡張することが可能で、そのデータによって特定のトリガーを同じイベントで実行される他のトリガーと区別することができます。リポジトリ イベントを email や SNS によって購買するためにトリガーを利用することができます。SNS から SQS へ書き込み、キューを通じて CI/CD のツールにジョブを上げたり、お使いのツールが提供する webhook に対して SNS を使ってアクティベートしたりできます。どのようなケースでも、CodeCommit リポジトリの変更によって指定したアクションがトリガーされます。また Lambda ファンクションを利用してビルド、シンタックスのチェック、コードの複雑度メトリックスの捕捉、開発者の生産性の測定(もちろん少ないほうがいいですね)などをトリガーできます。私の同僚もこの記事の最後にあるような、いくつかの珍しいアイデアを思いつきました!

トリガーは AWS マネジメント コンソールAWS コマンドライン インターフェース(CLI)、または CodeCommit API を通じて作成、表示、管理することができます。ここではコンソールを使います。左側のナビゲージョン列に Triggers の項目が追加されています:

Create Trigger をクリックして開始します。単一のイベント(または複数のイベント)を選択し、単一のブランチ(または複数のブランチ)を選択し、通知の発行や Lambda ファンクションの起動に必要な詳細を入力します:

対象となるイベントとブランチを選択しました:

そして、SNS トピックまたは Lambda ファンクションを指定し(適切なパーミッションが指定されていることを確認したのち)、期待通りにすべてが動作することを確認するために Test Trigger を利用し、Create ボタンをクリックします。

期待通りに IAM のパーミッションが動作することを検証するために Test Trigger を利用できます。例えばここでは、わざとエラーを発生させています:

 

ドキュメントにある「AWS CodeCommit はどのようにファンクションを実行するのか」を読んで、この問題を解決しました!

 

すでに利用可能です

この新しい機能はすでに利用可能で、すぐに使い始めることができます。より詳しく学ぶために Managing Triggers for an AWS CodeCommit Repository をお読みください。

私の同僚の Claire Liguori が CI/CD プロセスとの通常の統合を超えた、CodeCommit トリガーの創造的な用途についていくつか提案しています:

  • ビデオの展開 – 新しいビデオ、または既存のビデオの新しいバージョンがコミットされたかどうかをLambda ファンクションでチェックし、更新が発生したらビデオを YouTube に展開する
  • パーティータイム – 新しいリリースをデプロイした時に、自動的にケータリングを実行する(サンドイッチピザビール のAPIを利用して)
  • 広告リリース – 新しいリリースの準備ができたら、Facebook ページを自動的に生成、実行し、ソーシャル メディアにリリース情報を公表する

 皆様が開発プロセスでこれらのトリガーを利用し、創造的な方法編み出されることを耳にするのを楽しみにしています。ぜひコメントを残して、私にお知らせください!

Jeff;

 

日本語翻訳はSA 福井が担当しました。原文はこちらです: https://aws.amazon.com/jp/blogs/aws/new-notifications-for-aws-codecommit/