Category: Developer Tools

.NET Framework用のカスタムCodeBuildビルド環境の作成方法について説明している、この素晴らしいブログを書いたMicrosoftプラットフォーム担当シニア・ソリューション・アーキテクト、Greg Eppelに感謝します。 — AWS CodeBuildは、ソースコードをコンパイルし、テストを実行し、展開可能なソフトウェアパッケージを生成する、フルマネージドなビルドサービスです。 CodeBuildは、Android、Go、Java、Node.js、PHP、Python、Ruby、Dockerなどのプログラミング言語とランタイムのためのビルド環境を提供します。 CodeBuildは、Microsoft Windows Serverプラットフォーム用のビルドもサポートしています。これには、Windows上の.NET Core用にあらかじめパッケージ化されたビルド環境も含まれます。アプリケーションで.NET Frameworkが使用されている場合は、独自のDockerイメージを使用して、Microsoftの.NET Frameworkクラスライブラリを含むカスタムビルド環境を作成する必要があります。この手順が必要な理由については、よくある質問を参照してください。この記事では、.NET Frameworkアプリケーション用のカスタムビルド環境を作成し、この環境を使用するようにCodeBuildを設定する手順を説明します。

皆さんに AWS Cloud Development Kit (CDK) の開発者プレビューをご案内できることを嬉しく思います。現在の対応言語は TypeScript、 JavaScript そして Java で、.NET と Python を近々ご案内予定です。AWS CDK はソフトウェア開発のフレームワークであり、クラウドのインフラストラクチャをコードで定義して CloudFormation でプロビジョニングできます。CDK は AWS のサービスと統合され、高レベルかつオブジェクト指向の抽象概念を使ってAWS リソースを定義できます。CDK によってモダンなプログラミング言語を使ってAWS インフラストラクチャを見通しよく効率よく定義できるため、アプリケーションからインフラストラクチャまで一貫した開発体験 (development experience) が得られます。

Chef サーバは、テスト済みの信頼できるクックブックを対象ノードの run list に簡単に追加できるハブであるべきです。しかしながら、クックブックのテストを実行し、Chef サーバへ配信する作業は手間のかかるタスクです。このプロセスをシンプルかつ迅速にするために、私たちは AWS の技術を活用してテストの実行と Chef サーバへのクックブックの配信を統合したパイプラインを構築しました。これによりクックブック開発の定型的ながらも重要な部分を自動化できます。

大規模なデータおよびデータレイクのワークロード用にサーバーレスETL（抽出、変換およびロード）アプリケーションを開発するためにAWS Glueはますます普及しています。 ETLアプリケーションをクラウドベースのサーバーレスETLアーキテクチャに変換する組織は、ソースコードからビルド、デプロイ、プロダクトデリバリまで、シームレスでエンドツーエンドの継続的なインテグレーションおよび継続的なデリバリ（CI / CD）パイプラインが必要です。優れたCI / CDパイプラインを持つことで、組織はプロダクションリリース前にバグを発見し、より頻繁にアップデートを提供することができます。また、開発者が高品質のコードを書いたり、ETLのジョブリリース管理プロセスを自動化したり、リスクを軽減したりするのに役立ちます。 AWS Glueは、フルマネージドのデータカタログとETLのサービスです。これは、データの発見、変換、およびジョブスケジューリングなどの困難で時間のかかる作業を簡素化し自動化します。 AWS Glueは、データソースをクロールし、CSV、Apache Parquet、JSONなどの一般的なデータフォーマットとデータタイプ用に事前に作成された分類子を使用してデータカタログを構築します。 AWS Glueを使用してETLアプリケーションを開発する場合、CI / CDの次のような課題に直面する場合があります。 ユニットテストによる繰り返しの開発 継続的なインテグレーションとビルド ETLパイプラインをテスト環境にプッシュする ETLパイプラインをプロダクション環境にプッシュする 実データを使用したETLアプリケーションのテスト（live test） データの調査と検証 この記事では、AWS Developer Tools（AWS CodePipeline、AWS CodeCommit、AWS CodeBuildなど）とAWS CloudFormationがサポートするサーバーレスAWS Glue ETLアプリケーションのCI / CDパイプラインを実装するソリューションを紹介します。 ソリューションの概要 次の図は、ワークフローのパイプラインを示しています。 このソリューションでは、AWS CodePipelineを使用して、ETLアプリケーションのソースコードのテストおよびステージへのデプロイを制御および自動化することができます。 このソリューションは、以下のステージを含むパイプラインで構成されています。 1.）Source Control：このステージでは、デプロイするETLジョブのAWS Glue ETLジョブソースコードとAWS CloudFormationテンプレートファイルの両方がバージョン管理にコミットされます。 バージョン管理にAWS CodeCommitを使用することにしました。 ETLジョブソースコードとAWS CloudFormationテンプレートを取得するには、gluedemoetl.zipファイルをダウンロードします。 このソリューションは、以前の記事、AWS Glue と Amazon S3 を使用してデータレイクの基礎を構築するに基づいて開発されました。 2.）LiveTest：このステージでは、AWS […]

このブログ記事では、AWS CodeStar プロジェクトの一部として単体テストを実行する方法についてご紹介します。AWS CodeStar は AWS 上でアプリケーションを素早く開発、ビルド、そしてデプロイするのに役立ちます。AWS CodeStar を使えば、継続的デリバリ（CD）のツールチェーンを構築しソフトウェア開発を一箇所に集約して管理することができます。 単体テストはアプリケーションのコードの個々の単位をテストし、問題を素早く特定し取り去るのに役立ちます。単体テストは、自動化された CI/CD プロセスの１部分を構成することで、バッドコードが本番環境にデプロイされてしまうことを防ぐのにも役立てられます。 多くの AWS CodeStar プロジェクト テンプレートには、単体テストのフレームワークがあらかじめ設定されています。そのため、自信を持ってコードのデプロイを開始することができるでしょう。この AWS CodeStar プロジェクトの単体テストは、ビルドステージにおいて実行されるように設定されているので、もし単体テストがパスしなかったらそのコードがデプロイされることはありません。単体テストを内包している AWS CodeStar プロジェクト テンプレートの一覧については、AWS CodeStar ユーザガイドの AWS CodeStar プロジェクト テンプレートを参照してください。

AWS Cloud9 は 2017年11月の AWS re:Invent で発表されました。Cloud9 はブラウザベースの IDE で、サーバレスアプリケーションも含め、数多くのクラウド上の開発ユースケースに適しています。AWS CloudFormation を使うことで AWS CodeCommit と連携した AWS Cloud9 の開発環境を迅速に構築することができます。このブログでは、CloudFormation を使った Cloud9 環境の構築手順を説明します。さらに Cloud9 の環境で Python と Boto3 のコードを書き、 Troposphere を使って CloudFormation の YAML テンプレートを生成する方法についても説明します。

AWS X-Ray は、開発者がマイクロサービスやサーバレス・アーキテクチャで構築された本番環境のアプリケーションを分析及びデバッグすることを手助けし、顧客への影響を定量化します。AWS X-Ray を使うと、アプリケーション及びそのアプリケーションが依存しているサービスがどのように振る舞っているかを把握し、パフォーマンスの問題やエラーに対する根本原因の究明やトラブルシュートを行うことができます。これらの洞察を駆使してアプリケーションの問題点を見つけ出し最適化の機会を得ることができます。 このブログ記事では、X-Ray がアプリケーションにおける遅延やエラー、あるいは失敗の増加を検知したときに、どうすれば Amazon CloudWatch と Amazon SNS を使って通知を受信することができるのかをお見せします。特に、エンドユーザがあなたのアプリケーションを利用していて遅延の増加やサーバサイドのエラーに遭遇した際にEメールや SMS メッセージを通して通知を受け取るためにはどうすればよいでしょうか。サンプルアプリケーションを使ってお見せしたいと思います。サンプルアプリケーションは、コードを修正することによってアラームやイベントをカスタマイズすることも可能です。

この記事はAWS Senior Technical EvangelistのAbby Fullerの投稿です。 2017年12月12日に、AWSはAWS CodePipelineのターゲットとしてAmazon Elastic Container Service (ECS)をAWS Fargateも含めてサポートしたことをアナウンスしました。このサポートにより、コンテナベースのアプリケーションやマイクロサービスを継続的デリバリするパイプラインを作成するのがより簡単になりました。 コンテナ化したサービスを手動で構築しデプロイするのは、時間がかかりますしエラーを起こしがちです。自動化されたビルドとテスト機構と組み合わせた継続的デリバリは、早期にエラーを発見し時間を短縮することを助け、失敗を減らしてくれるので、アプリケーションのデプロイモデルとして一般的なものとなってきています。以前は、ECSでコンテナワークフローを自動化するには、AWS CloudFormationを使った自前のソリューションを構築する必要がありました。これからは、わずか数ステップでCodePipelineとCodeBuildをECSと連携させてワークフローを自動かすることができます。 CodePipeline、CodeBuild、そしてECSを使った典型的な継続的デリバリのワークフローは、以下のようなものです: ソースを選択する プロジェクトをビルドする コードをデプロイする GitHub上にこのワークフローのための継続的デプロイのリファレンスアーキテクチャも公開しています。 はじめてみよう 最初に、CodePipelineで新規プロジェクトを作成し、例として”demo”というプロジェクト名を設定します。 次に、コードが保管されているソースの場所を選択します。ここには、AWS CodeCommit、GitHub、またはAmazon S3が選択できます。この例では、GitHubを入力し、CodePipelineにレポジトリへのアクセス権を与えます。 次に、ビルドステップを追加します。JenkinsサーバURLやCodeBuildプロジェクトの様に既存のビルドを持ってくることもできますし、CodeBuildで新しいステップを作成することもできます。もし既存のCodeBuildのプロジェクトがなければ、以下の様に選択してCodePipelineから新しいものを作成しましょう: Build provider: AWS CodeBuild Configure your project: Create a new build project Environment image: Use an image managed by AWS CodeBuild Operating system: Ubuntu Runtime: Docker Version: aws/codebuild/docker:1.12.1 Build specification: […]

プログラミングを始める時に最初に学ぶことは、どんな職人でも同様ですが、道具についてです。メモ帳は役に立たないでしょう。強力なエディタとテスティング パイプラインがあなたの生産性に大きく貢献します。私はまだ最初にVimの使い方を学んだ時のことを覚えています。それを使ってシステムと複雑なプログラムをZip化しました。すべてのコンパイラと依存関係を新しいマシンにセットアップすることが、どれほど大変だったか覚えていますか？新しいデベロッパーをプロジェクトに参加させるためにバージョンをマッチさせ、構成ファイルを取り繕い、ドキュメントを書くのに、どれほどのサイクルを浪費したことか。 本日（11/30）コーディング、実行、デバッグを可能にする統合開発環境（IDE）をWebブラウザ上で実現するのAWS Cloud9をローンチしました。Cloud9は多くの人気のある開発言語（Javascript、Python、PHP、その他）のための主要なツールをパッケージ化しているので、様々なコンパイラやツールなどをインストールする必要はありません。Cloud9はまたサーバーレスアプリケーションとのシームレスなエクスペリエンスを提供しておりローカルとリモートの間でテストやデバッグを素早くスイッチできます。ポピュラーなオープンソースのAce Editorとc9.io IDE（昨年買収しました）をベースに、AWS Cloud9は非常にパワフルなペアプログラミング機能と共にクラウド開発におけるコラボレーションが容易になるように設計されています。Cloud9は、このBlog記事でカバーしているものよりも多くの機能を提供していますが、ここではクイックにエディタ機能、AWSとのインテグレーション、コラボレーション機能の3つのコンポーネントに分解して掘り下げていきます。

以前の「GitとAWS CodePipelineの統合」の記事では、Amazon API Gateway、AWS Lambda、Amazon S3を使用して、サードパーティのGitリポジトリとAWS CodePipelineを統合する方法の1つを示しました。 このアプローチでは、GitリポジトリをCodePipelineと迅速に統合できますが、多くの利用者がCI/CDパイプラインで使用するソースのメタデータをCodePipelineに提供することはできません。 この記事では、ソースリポジトリから、より多くのメタデータをCodePipelineに提供するための異なる戦略を提供する、CodePipelineカスタムソースアクションについて説明します。最も一般的なソース メタデータは、コミット識別子とコミットメッセージです。Commit識別子は、ソフトウェアライフサイクル全体の変更を追跡するために頻繁に使用されますが、コミットメッセージは人間が判読可能で簡潔な記述を提供します。カスタムソースアクションを使用すると、CodePipelineがCodeCommitやGitHubと統合するのと同じ方法で、任意のソースリポジトリと統合することができ、コミット識別子とコミットメッセージにアクセスできます。 この記事では、API GatewayとLambdaをセットアップしてパイプラインをトリガし、パイプラインをカスタムソースアクションで構成し、カスタムソースアクションからジョブを処理するワーカーを構築します。このアーキテクチャを使用すると、VPCでホストされているか、またはオンプレミスに構築されておりVPCからアクセス可能なソースプロバイダにアクセスできます。