Amazon Web Services ブログ

Category: AWS CodePipeline

Builder 例のコンセプト

Cloud Native Buildpacks による AWS CodeBuild と AWS CodePipeline を使ったコンテナイメージの作成

この記事は Creating container images with Cloud Native Buildpacks using AWS CodeBuild and AWS CodePipeline (記事公開日: 2021 年 10 月 6 日) を翻訳したものです。 Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、またはその他のコンテナオーケストレーターを使用している組織は、迅速に稼動させるためのよくある課題に直面しています。それは、アプリケーションのソースコードをコンテナイメージに迅速かつ効率的にパッケージ化するにはどうすればよいかということです。この “Source to Image” というという道のりは、組織がコンテナ技術を導入したばかりであるか、数百のワークロードにスケールアップしようとしているかに関わらず、さまざまな場面で課題となります。

Read More

音声によるゲームの進化

この記事は、“How the power of voice can supercharge gaming”を翻訳したものです。 Doppio社は、ヨーロッパを拠点とする音声ゲーム開発会社で、「The Vortex」,「The 3% Challenge」,「PAC-MAN™ WAKA WAKA」などの音声ゲームのヒット作を生み出しています。 Jeferson Valadaresは、BioWare、Playfish、Digital Chocolate、BANDAI NAMCOなどの有名スタジオで経験を積んだゲームのベテランです。Christopher Barnesは、大手ゲーム会社でモバイルゲームやバックエンドプラットフォームサービスを担当していました。

Read More

Amplifyで構築したバックエンドをCDKで出力して既存のデプロイパイプラインで使用する新機能「エクスポート」のご紹介

この記事は、Export Amplify backends to CDK and use with existing deployment pipelines を翻訳したものです。 AWS Amplifyは、Amplify CLIで生成されたバックエンドをAWS Cloud Development Kit (CDK)スタックとしてエクスポートし、既存のCDKデプロイメント・パイプラインに組み込む機能を発表しました。この新機能により、フロントエンド開発者はアプリのバックエンドを迅速に構築し、リリースの準備毎に、DevOpsチームと連携し本番環境にデプロイすることができます。

Read More

AWS CDK Pipelines を利用した SaaS の並列かつ動的なデプロイ

こちらの記事は「Parallel and dynamic SaaS deployments with AWS CDK Pipelines」を翻訳したものです。 Software as a Service(SaaS)は、従量課金制の価格モデル、スケーラビリティ、可用性などのメリットをもたらすビジネスモデルで、独立系ソフトウェアベンダー(ISV)の間でますます人気を集めています。 SaaS サービスは、多数のアーキテクチャモデルを使用して構築できます。アーキテクチャを共有しないサイロモデルでは、各テナントごとに専用のリソースを提供します。サイロモデルでの展開は、テナント間のコンピューティングリソースとデータを分離し、ノイジーネイバー問題を排除するのにも役立ちます。一方、プールモデルには、コンピューティングリソースとキャパシティをより効率的に利用できるため、メンテナンスのオーバーヘッドの削減、管理と運用の簡素化、コスト削減の機会など、いくつかのメリットがあります。ブリッジモデルは、サイロモデルとプールモデルの両方が共存して使用されるハイブリッドなモデルです。システムの一部はサイロモデルとして、別の一部はプールモデルとして構築することができます。

Read More

AWS DevOps Monitoring Dashboard ソリューションを使用して CI/CD メトリクスのキャプチャと分析を自動化する方法

この記事は 2021年4月14日に Solutions Builder and Data Analytics SME の Aijun Peng と Technical Program Manager の Rakshana Balakrishnan により投稿された How to automate capture and analysis of CI/CD metrics using AWS DevOps Monitoring Dashboard solution を翻訳したものです。 世界中の企業が、ソフトウェア・デリバリー・プロセスの生産性を向上させるために、DevOps ツールに投資しています。お客様からは、継続的インテグレーション/継続的デリバリ (CI/CD) パイプラインのパフォーマンスや運用に関するメトリクスを収集して、DevOps の自動化から得られる価値を定量化し、ソフトウェアデリバリーの効率化を行える箇所を特定したい、という声が寄せられています。しかし、お客様の中には、適切なメトリクスを特定し、CI/CD パイプラインのさまざまなコンポーネントからメトリクスを集約することは、複雑で時間のかかるものであるため、困難であると感じている方もいらっしゃいます。 この記事では、AWS DevOps Monitoring Dashboard ソリューションを使うことで、DevOps メトリクスを収集して可視化するためのセットアッププロセスを自動化し、時間と労力を節約する方法を紹介します。このソリューションは、あらゆる規模の組織がソフトウェア・デリバリー・プロセスにおける主要な運用指標を収集、分析、可視化することを容易にするリファレンス実装です。

Read More

CDK Pipelinesのmodern APIを使ってCDKアプリケーションをデプロイする

CDK Pipelines は、AWS CodePipelineによって CDK アプリケーションの継続的なデプロイパイプラインを簡単にセットアップできる高レベルのコンストラクトライブラリです。現在のCDK Pipelinesには従来のoriginalバージョンと、新しいmodernバージョンの2つのAPIセットが含まれています。modernバージョンのAPIはより使いやすく改善されており、今後は推奨されるAPIとなります。originalバージョンのAPIは後方互換性のためまだ利用可能ですが、可能であれば新バージョンへの移行をおすすめします。 originalのAPIと比較して、modernのAPIは、より適切なデフォルト値を持ち、より柔軟性があり、並列デプロイメントをサポートし、複数のシンセサイザー入力をサポートし、CodeBuildプロジェクトのより詳細な制御を可能にし、CodePipeline以外のデプロイメントエンジンをサポートしています。original APIのREADMEと移行ガイドは、GitHub にあります。 この記事ではCDK Pipelinesのmodern APIを使ってデプロイを行う基本的な手順について解説します。CDK Pipelinesの使い方についてはAWS CDK Reference Documentation の @aws-cdk/pipelines module のページに詳しく書いてあるため、そちらも合わせて参照してください。

Read More

GitHub モノレポを AWS CodePipeline と統合して、プロジェクト固有の CI/CD パイプラインを実行する

(この記事は、Integrate GitHub monorepo with AWS CodePipeline to run project-specific CI/CD pipelines を翻訳したものです。) AWS CodePipeline は、ソフトウェアのリリースに必要なステップをモデル化、可視化、自動化できる継続的デリバリーサービスです。AWS CodePipeline を使用して、コードを構築し、稼働前の環境にデプロイし、アプリケーションをテストし、実稼働環境にリリースするまでの完全なリリースプロセスをモデル化できます。AWS CodePipeline は、コードが変更されるたびに定義されるワークフローに従って、アプリケーションを構築、テスト、デプロイします。多くの組織が GitHub をソースコードリポジトリとして使用しています。組織によっては、1 つの GitHub リポジトリに複数のアプリケーションまたはサービスをフォルダで分割して格納することを選択しています。リポジトリ内のソースコードをこのように整理する方法は、モノレポと呼ばれます。 この記事では、AWS Lambda で GitHub イベントペイロード(訳者注:GitHub 上でのアクティビティを元にトリガーされるイベント情報。詳細は GitHub イベントのドキュメントをご確認ください。)を読み取り、サービス固有のパイプラインを実行するようにカスタマイズする方法を示します。

Read More

サードパーティの Git リポジトリから AWS CodePipeline のビルドステータスを追跡する

(この記事は、Tracking the AWS CodePipeline build status from the third-party Git repository を翻訳したものです。) AWS CodePipeline では、パイプラインのソースとしてサードパーティの Git リポジトリを使用できますが、ビルドステータスをサードパーティ Git リポジトリダッシュボードで確認できない場合があります。開発者がリポジトリで作業する場合、同じダッシュボードでビルド/パイプラインのステータスを確認できることが望ましいです。このブログでは、パイプライン/ビルドステータスをサードパーティのリポジトリに反映するソリューションの構築手順を説明します。これにより、開発者はコンテキストを切り替えることなくステータスを簡単に追跡できます。 CodePipeline は GitHub と Bitbucket をサポートしており、どちらも REST API を提供し、パイプライン実行に関連する情報をリポジトリにプッシュできます。このブログでは、CodePipeline と Git リポジトリ間のこの統合を設定する方法について説明します。

Read More
Solutions Design diagram explaining how the solution is structured

Selenium, AWS Lambda, AWS Fargate, AWS Developer Tools を使ったサーバーレスなUIテスト

(この記事は、 Serverless UI testing using Selenium, AWS Lambda, AWS Fargate, and AWS Developer Tools を翻訳したものです。) 以前、Using AWS CodePipeline, AWS CodeBuild, and AWS Lambda for Serverless Automated UI Testing (日本語版 ) を公開してから、Chrome headless とFirefox headless が各ブラウザでネイティブにサポートされるようになったことで、事態は大きく変わりました。 AWS Lambda は今やコンテナイメージをサポートし、 AWS Step Functions はLambda と統合された Map state のサポートを追加し、AWS Fargate は完全にサーバーレスのテクノロジを利用した、UIテストを可能にしました。

Read More

分散型環境における AWS Service Catalog を使用したインフラストラクチャデリバリーの標準化

多くのエンタープライズのお客様では、共通のセキュリティに関するデザインパターンやベストプラクティスとして、マルチアカウント戦略の導入を通じたアプリケーションの分離を行っています。かなりのお客様が、開発 (Dev) 、品質保証 (QA) 、そして実稼働 (Prod) といった開発ライフサイクル (SDLC) の各フェーズに合わせ、環境全体で完全な分離を実現するために、個別の AWS アカウントを作成する手法を選択しています。しかしながら、アカウント作成時点でアプリケーションからの要件が完全に理解できていない場合、必要なインフラストラクチャコンポーネントをプロビジョニングすることが困難になり得ます。加えて、作成されたアカウントが増えるに従い、それらの異なるカウント間でのインフラストラクチャのコンプライアンスと一貫性を実現するための手法を模索しなければなりません。 AWS Service Catalog は、こういった課題に対処するため役立ちます。これにより開発者は、どのような環境においても、インフラストラクチャコンポーネントを、素早く、安全かつ簡単にデプロイできるようになります。次の図は、このワークフローを示しています。ここでは、アプリケーションにおける Dev/QA/Prod 用の各アカウントが、実稼働および非実稼働向けのインフラストラクチャコンポーネントを共有するために、AWS Service Catalog が使用されています。 お客様の多くに、AWS Service Catalog を使用するメリットは「一枚のガラス」を通すようにインフラストラクチャがプロビジョニングできることである、と捉えていただいていますが、実はこれには、製品のデプロイを自動化する機能も備わっています。前出の図にあるワークフローでは、アプリケーションのアカウントで共有している各製品は、それぞれの継続的統合/継続的デリバリー (CI/CD) パイプラインから、直接デプロイすることが可能です。これにより、コードおよびインフラストラクチャの依存関係と、各チームに分散した個別コンポーネントの所有権とを、開発者が固く結びつけることができる環境が提供されます。 このモデルからは、次のように 2 つの主要なメリットが得られます。 中心チームは、承認されたインフラストラクチャのバージョンを定義することで、コンプライアンスと標準化を実施できるようになります。 アプリケーション所有者が、使用すべきインフラストラクチャコンポーネントを自身で選択できる、セルフサービス型の環境が提供されます。 次の図で、このプロセスをさらに詳細に説明しています。ここでは、インフラストラクチャの定義は Shared Services チームにより処理されます。このチームにより、アプリケーションアカウントとの間で共有する、ネットワークやコンピューティングベースのリソースに関するカタログが作成されます。アプリケーションの所有者には、各要件に最も適合するコンポーネントを決定する役割があり、各所有者は複数のバージョンをが共有できます。これらの製品は、アプリケーションの CI/CD プロセスの一環として、AWS CodePipeline などの AWS のサービスを使用してデプロイされます。この、インフラストラクチャのデプロイ手法には、セキュリティ上のメリットもあります。アプリケーションパイプラインのアクセス権限は、基盤となっている AWS のサービスではなく、最小権限を保証しながら AWS Service Catalog ポートフォリオに対し適用されるからです。 AWS Service Catalog アカウントポートフォリオの共有を活用する CI/CD パイプラインの自動構築は、次の GitHub レポジトリから Amazon […]

Read More