この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。CX事業本部Delivery部のきんじょーです。
みなさん、今年のre:Invent 2022はいかがお過ごしでしたか？
私ははじめて現地参戦し大興奮でした。
その中でも12/01の Warner Vogels キーノートで「Amazon CodeCatalyst」という新サービスが発表され、久しぶりのCodeシリーズの大きなアップデートに大変興味を惹かれています。
CodeCatalystについて紹介する「Introducing Amazon CodeCatalyst(DOP206-R1)」というセッションを聴講したので、早速レポートしていきます！
セッション情報
登壇者
Harry Mower
Derector, DevOps Services
Amazon Web Services
Doug Clauson
Product Manager DevOps Services
Amazon Web Services
セッション概要
Amazon CodeCatalyst brings together everything developers need to plan, code, build, test, and deploy applications on AWS into a streamlined, integrated experience. In this session, discover its key capabilities, including project blueprints, issue tracking, automated workflows and CI/CD pipelines, cloud development environments, automated infrastructure provisioning, notifications, and collaboration to maximize your team’s productivity. Join this session for an overview of Amazon CodeCatalyst.
(Amazon CodeCatalyst は、開発者が AWS 上でアプリケーションを計画、コーディング、ビルド、テスト、デプロイするために必要なすべてを、合理的かつ統合的なエクスペリエンスにまとめます。このセッションでは、プロジェクト設計図、課題追跡、自動ワークフローとCI/CDパイプライン、クラウド開発環境、自動インフラプロビジョニング、通知、チームの生産性を最大化するコラボレーションなど、その主要な機能をご紹介します。Amazon CodeCatalystの概要については、このセッションにご参加ください。)
セッション内容
Harry氏:
こんにちは、みなさん、ごきげんよう。午後遅くまでお付き合いいただきありがとうございます。
私の名前はHarry Mowerです。私はAWSのDevOpsサービス担当のディレクターです。私の役割は、CodeBuild、CodePipeline、CodeCommit、そして去年から今日にかけての新しいサービス、Code CatalystのようなDevOpsツールの戦略と実行を監督しています。
今日は、CodeCatalystについて詳しく説明します。その特徴や利点、自分の環境でどのように使えるかデモを交えて紹介します。
でもその前に、Dougが自己紹介をしたいと言っています。
Doug氏:
私の名前はDoug Clausonです。DevOpsサービス・チームでプロダクト・マネージャーをしています。
Amazonで働いていてもっとも気に入っているのは、私たちの作るものがお客様にとって何が重要であるかということに基づいているということです。そして、開発者ツールに関しては、皆さんから「もっと速くしたい」と言われています。
コードやアプリケーションの開発に時間・お金・リソースを費やし、アプリケーションの記述、テスト、ウィンドウパイプライン、そして最終的に本番環境へのデプロイに時間がかかればかかるほど、あなたが作ったものの価値を顧客が理解するまでに時間がかかることになります。
一方、複雑さは、私たちに不利に働きます。つまり、ツールチェーンやプロセスが複雑になる程、私たちに不利に働きます。ですから、スピードを追求するときは、複雑さを取り除く努力もしたいものです。そのような理由からです。今日はAmazon CodeCatalystの話をするためここに来ることができてとても興奮しています。
これまでのCodeシリーズについて
Harry氏:
ありがとう、Doug。私はDevOpsツールを統括していますが、実は開発者向けにさまざまなツールを提供しており、ソースコードの編集、デバッグにCloud9、SDKなどのツールキットから、テスト構築、AWSへのアプリケーションデプロイまであらゆる作業を支援しています。
私たちの仕事は、お客様がアプリケーションを構築し、テストし、最終的にAWSにデプロイするための作業を簡単に管理できるようにすることです。
私たちは常に、お客様が使用している他のツールと組み合わせて、私たちのサービスを柔軟かつ簡単に使用できるよう努めています。つまり、私たちのサービスはビルディングブロックのようなもので、エンドユーザーの課題を解決するために、独自のツールチェーンを構築することができるのです。
現在、私たちのお客様の多くが利用しているのは、今から紹介する5つのサービスです。
ソースコード管理のためのCodeCommitがあります。あなたのソースコードをクラウドに持ち込み、高度にスケーラブルで、保管時および転送時でも安全で暗号化されたインフラを手に入れることができます。
パッケージとアーティファクトを管理するため、ビルドプロセスをローカルマシンからクラウドに移行し当社の弾力的なコンピューティングインフラを活用するために、Code Artifactを用意しています。
ローカル環境からクラウドへビルド環境を移行するためにCodeBuildがあり、Lambda・ECS・EKS・その他AWSにあるさまざまなコンピューティングプラットフォームへデプロイするために、CodeDeployがあります。
そして最後に、CodePipelineで、すべてをまとめることができ、最終的に本番環境へ到達する前に、コードが必要とするすべての異なる環境を通じて、変更をオーケストレーションします。
Codeシリーズのトレードオフ
このように、これらのサービスは非常に柔軟性が高く、独自のカスタムツールチェーンを構築するために時間と労力をかけたいお客様には最適なサービスです。
しかし、このようなカスタマイズや柔軟性がある一方で、お客様が抱えている課題や、このアプローチに伴うトレードオフの問題についても耳にしました。そこで、私たちは一歩踏み出しました。そして、お客様が抱えていた課題と、長年にわたってお客様からお聞きしてきたその他の課題を検討したのです。
コストの問題
最初に耳にしたのは、「カスタムツールチェーンを自分たちで作るというアイデアがとても気に入った」 というものでした。 でも、結局のところ、コストがかかって大変なんですよね。
JIRAとJenkins、Circle CI、その他すべてのデプロイツールの配線には多くの投資と努力が必要で、この投資は通常、顧客のために新機能や修正を構築することを犠牲にして行われるものです。また、長期的なメンテナンスも必要になりコストがかかります。
開発環境のインフラの問題
もう1点、ツールチェーンをすべてセットアップすると、データ処理に必要なインフラストラクチャのことを忘れてしまうことがあります。
私たちが第1に考えるのは、アプリケーションを実行するために必要な本番環境のインフラです。しかし、実際はテスト環境、開発環境、開発者用デスクトップなど、さまざまなインフラを構築することが必要です。
新しい開発者がプロジェクトに参加するたび、異なる言語やツールのセットを、ラップトップに再設定しなければならない可能性があり、デスクトップとクラウドの両方にあるインフラを、より簡単に管理できるようにしたい、というものでした。
このようなフィードバックがありました。私たちがすべきことは、ツールチェーンの維持・管理にかかるコストを削減し、モダンなアプリケーションの構築とインフラ管理の複雑さに対応するための新機能を追加することです。
そこで登場したのが、CodeCatalystです。
CodeCatalystでできること
Harry氏:
今日これを発表できることに、私はとても興奮しています。これを構築することは、チームにとって長い旅でした。私たちは、このために多くの時間と労力を費やしてきました。
CodeCatalystは、アイデアからインパクト、あるいはアイデアから生産に至るまで、チームが必要とするすべてのツールとインフラを1つのシームレスな体験にまとめる、統合されたDevOpsのサービス です。
CodeCatalystの目的は、Dougが言ったように、複雑な部分を取り除いてより速く作業できるようにすることです。CodeCatalystはそれをすべてまとめてくれます。CodeCatalystはそれをすべて提供してくれます。さまざまなツールを統合するために、多くの時間と労力を費やす必要はありません。私たちがそれを代行します。また、その管理も私たちが行います。そのため、開発者のために環境を常に新鮮に保つためのメンテナンス作業や継続的な作業について心配する必要はありませんね。
ツールチェーンの立ち上げを容易にすることに加え、私たちは、これまでお話ししたような他の問題にも取り組みたいと考えており、とくに4つの分野に重点を置いています。
1. プロジェクトのセットアップを高速化
まず第一に、優れたアーキテクチャーのアプリケーションを数分で簡単に構築できるようにしたいと考えました。
今朝、Wernerが言ったことに戻ります。すべての物事はシンプルに始まり、やがて拡張される。私たちは、その最初のシンプルなものを、本当に簡単に立ち上げられるようにしたいのです。 そのシンプルなものとは、ソースコードや実行中のアプリケーションだけでなく、実際にアプリケーションを構築、時間をかけてメンテナンスし、進化させるために必要なすべてのものを指します。
Doug氏:
今日はもっともクールな話をしようと思います。
あなたは良いアイデアを得て、始める準備ができています。しかし、実際に始める前に、ここでたくさんのセットアップをしなければならないことに気がつきます。たとえば、AWSのWell Architected Frameworkのページやデータベース・ソリューションをうまく設計して、適切なサービスを利用することです。どのようなツールが必要かを考え、そのようなプロジェクトを実際に開発できるようローカルマシンを設定します。
また、持っていないライブラリーをインストールすることも必要です。CI/CDパイプラインのことも考えないとね。インフラについても考えないといけない。というわけで、いろいろあるんです。
そこで、お客さまがより速く動けるようにするため、このブループリントには、お客様が始めるために必要なものがすべて含まれています 。ソースコードを入手することはその一部ですが、それ以外のことも重要です。 異なる言語・アーキテクチャ、同じプロジェクト内のマイクロサービスについて、CI/CDパイプラインや監視・追跡するためのIssueトラッカーの情報を、開発チームでコンテキストを共有できるようにするためのダッシュボードがセットアップされています。
ローンチ時には、さまざまなブループリントが用意されています。サーバーレス、コンテナベースのアプリケーション、ウェブアプリケーション、APIバックエンドもあり、これらはすべて、文字通り数回クリックするだけで始められます。
AWSソリューションから始めたいお客様のために、サーバーレス、画像処理やビデオオンデマンドサービスなど、もっとも人気のあるAWSソリューションを取り上げて、ブループリントにしました。
もしあなたがこれらのソリューションを使ったことがあるなら、1つの画面に表示されたものを、自分のアカウントで作業し、いきなりステップバイステップのプロセスに従って、多くのコピーアンドペーストを行う必要があることをご存知でしょう。
ブループリントは、これまで私たちがしなければならなかった大変な作業の多くを担ってくれます。
さらに、特定のツールチェーンやデジタルツールを使用している場合、たとえば、Issue管理のためのJIRAやソースのためのGitHubを使用しているしている場合などです。それらの製品を使いながら、それらとの統合を構築し、成熟させ続けることができます。
デモ
デモではブループリントからReactのプロジェクトを構築してデプロイする様子が紹介されました。 5分程度で、Reactのアプリ、インフラのCDKコード、CI/CD、CloudFront + S3といったリソースが簡単に構築できることがわかります。
※詳しくはセッション動画をご確認ください。
2. CI/CDパイプライン
Harry氏:
AWSの多くのものは簡単に始められますが、あなたがやりたいことは、次のステップを踏み出すことです。ブループリントで生成されたプロジェクトを簡単に変更できるようにするため、そのアプリケーションに変更を簡単に反映させるパイプラインが必要なのです。そうですね。これは、ソースコードやリポジトリ、GitHubなどのソースリポジトリをプルダウンする際によく見られるラストマイルの問題と同じです。
コードをどうやって正しくデプロイするか、いつも考えなければならないんです。 この問題は、プロジェクトを作成時はCodeCatalystのブループリントが解消してくれます。しかし、アプリケーションに新しいサービスを追加したり、何かを変更したりする場合、ワークフロー自体を変更する必要があります。そのため、ワークフローを簡単に変更する方法をいくつか紹介します。
YAMLベースで作成
まず、パイプラインをYAMLとして定義する方法があります。これはYAMLベースのパイプラインです。つまり、これらはすべてYAMLベースのパイプラインで、ソースコードとしてリポジトリに保存が可能です。
実は、お客様のプロジェクトを生成する際、YAMLのワークフローが実際に生成され、初期のワークフローとしてリポジトリに保存されます。これはデモとして数分後にお見せします。
ビジュアル・エディターで作成
YAMLを直接編集することを選択できますが、ビジュアル・エディターを使用して、GUIでワークフローを作成することもできます。
AWS上のCI/CD構築に必要なもっとも一般的なアクションがすべて用意されています。ビルド、テスト、デプロイ、EKSへのデプロイ、Lambdaへのデプロイ、Fargateへのデプロイ、一般的なインフラやコンピュート環境へのデプロイなどです。パイプラインの一部として行いたい典型的なものだけでなく。任意のLambdaを実行したり、パッケージスキャンを行ったりといったことも含まれます。
GitHub Actionsの利用
多くの人がすでにGitHub Actionsを使い始めていることも知っています。 そこで、GitHub Actionsを自分のワークフローで簡単に使えるようにしたいと思います。そこで、パイプラインの標準をGitHub Actionsのオープンスタンダードとし、GitHub のアクションをワークフローに取り込むことができるようにしました。 ワークフローやGitHubアクションのクリエイターは、10～12,000のオープンソースのGitHubアクションを持っていて、CodeCatalystのワークフローの中で実行することができるんです。
自由に選べるパイプラインの実行環境
パイプラインを修正したり、新しいパイプラインを作ったりすると、それぞれのアクションを正しく実行するために、何らかのバックアップが必要になりますね。そこで自動的に行うことは、これらのアクションを実行するのに適した環境を選択することです。 オンデマンドで環境を立ち上げ、通常はコンテナ内で実行しますが、高速化が必要なものについてはLambdaとして実行することもできます。また、長時間稼働するワークフローや頻繁に稼働するワークフローで起動時間を短縮したい場合や、特定のタイプのマシンを実行したい場合、独自のオンデマンドインスタンス群を作成してワークフローを実行するオプションもあります。
パイプライン中でテストレポートの表示
それに加えて、ワークフローの中でテストがどのように機能しているかを簡単に確認できるようにしたいと考えました。これは、これまでCodeシリーズで行ってこなかったことです。テストツールに触れることはありませんでした。
CodeシリーズやCodeCatalystの中で、ワークフローにあるテストレポートを自動的に検出し、ワークフローのアウトプットの一部として表示するテストツールの始まりを見ることができるのです。コードカバレッジやテストの実行時間など、必要な情報を見ることができます。そのため、YAMLやビジュアル・エディターでそれらを簡単に作成し、自動的にテストを検出して表示するアクションの一部として、自由に組み立てることができるのです。早速、このデモをお見せしましょう。
デモ
ブループリントから作成した開発環境へデプロイするワークフローに加えて、Production環境へのワークフローを追加するデモがありました。
ワークフローをStepFunctions Studioのようなビジュアルエディターで構築できることや、別のアカウント、リージョンに対してのデプロイパイプラインを簡単に構築できることがわかります。
※詳しくはセッション動画をご確認ください。
3. 統合開発環境
Harry氏:
ありがとう、ゲイリー。さて、ここまでで、プロジェクトを立ち上げ、ワークフローを自動化する方法についてお話しました。そして今、私はすぐにでも開発を始める準備ができています。
今日、開発者がコードを変更したりプロジェクトにコントリビュートしたいと思ったときに、いくつかの異なる問題にぶつかりますよね？ソースコードを手に入れようとすると、通常自分のマシンをセットアップする必要があります。つまり、ソースコードをローカルにcloneするわけです。適切なライブラリをインストールし、できればそのライブラリが他のプロジェクトで使われているものであることが望ましい。そうしないと、環境依存の罠にハマることになります。
有名な話ですが、自分のマシンでは動作していたのに、なぜそのマシンでは動作するのか？他のマシンでは動かないのか？というようなことを、バイナリの違いから見つけるわけです。開発するアプリケーションの負荷によっては、開発用マシンでは処理しきれないことがあります。そのため、このアプリケーションをどのように実行すればよいかを考えなければなりません。低性能なマシンで効率的にデバッグを行うにはどうすれば良いのか、という問題もあります。
これを解決するために、CodeCatalystは自分の環境と他の人の環境の間に不必要な差異がないことを保証して、再現性のある開発環境を提供します。異なる開発者間で再現性を得ることができます。IDE全体がクラウド上で動作しているにもかかわらず、ローカルのIDEと同じ感覚で使用でき、開発環境は自分の作業したい場所にあるレポから好きなインターフェイス(Cloud9,VS Code, IntelliJ, GoLand, PyCharm)を使用できます。
もうひとつ、この開発環境での作業で素晴らしいのはコンテキストの切り替えがとても簡単なことです。ローカルで変更の設定をする必要はありません。別のレポに移動して、そのレポを立ち上げ実行するのです。また、オンデマンドで使用することができ、一時停止、再起動、削除が可能です。
デモ
VS Code用の開発環境を立ち上げ、コードを修正するデモが紹介されました。
※詳しくはセッション動画をご確認ください。
4.コラボレーション
では、チームの他のメンバーはどのようにこれを利用するのでしょうか。どうやって入手するのでしょうか。CodeCatalystへサインアップする際に、AWS Builder IDというものがあり、これについても少し説明します。このBuilder IDを使うと、自分のスペースにAWSアカウントがあり、プロジェクトに参加しているすべての人が同じAWSアカウントを共有することができます。これにより、セキュリティやCodeCatalystでのさまざまなデプロイ活動のモデル化など、実に興味深いことができるようになります。これで、プロジェクトに参加する人たちが揃い、シンプルな電子メールがその人たちに届き、招待状を受け取ってくれると一緒に作業を始めることができます。
ソフトウェア・プロジェクトの中で人と仕事をする場合、通常2つの方法があります。
1つは、新しい機能やその他の種類の問題を管理することで、通常は課題管理ツールを使用します。先にも述べたように、私たちははじめてテストツールというものに足を踏み入れました。また、AWSが提供する全体的なツールの一部として、新しい課題管理ツールやアジャイル計画ツールをはじめて導入しています。
CodeCatalystの内部には、フル機能のプロジェクト管理ツールセットがあり、さまざまな課題の作成、担当者の管理、バックログの管理、スタンドアップなどを行うことが可能です。
プロジェクトに人を招き、仕事の調整を始める。次にすることは、おそらくコードの変更に関するコラボレーションです。私たちは、PRを作成したり、コードのレビューを行ったりするのがとても簡単にできるようにしたいと思いました。そのため、CodeCatalystのレポには、さまざまなツールやPRツールなどがフルセットで組み込まれています。他のレポを使うという選択肢もあります。
サードパーティとの統合についてもお話しします。課題、コーディング、デプロイメント、そして最終的にあなたがこれから行うことになることまで、一連のアクティビティを追跡し、通知を受け取ることができるようにします。プレビューの一環としてSlackと統合しています。
この数カ月間、このアプリケーションの開発に協力してくれたパートナーに感謝したいと思います。プレビューの一部として、CodeCatalystに搭載されている課題管理システムをご覧いただきましたが、これをJIRAに置き換えることも可能です。私たちはAtlassianと協力して、ワークフローの拡張可能な部分を構築し、必要であれば別の課題管理システムを導入できるようにしました。
JetBrainsとも広範囲に渡って協力しあっています。もっとも人気のあるIDEはJetBrainsで、彼らは私たちを助けてくれました。 ワークフローのアクションの中には、サードパーティ製のものがあり、リソースやその種のものに対して自動コードを発行するようになっています。そして、そのようなコードをどのように実装すれば良いのか、その方法を見つけ出す手助けをしてくれました。
デモ
デモではCodeCatalystの課題管理ツールの使い方や、PR作成・コードレビューなどの機能の紹介がありました。
※詳しくはセッション動画をご確認ください。
所感
開発に必要なものをオールインワンで提供する統合DevOpsサービス「Amazon CodeCatalyst」と聞くとなんとも凄そうですね。
AWSが用意するIDEにはCloud9が元々ありました。 以前プロジェクトで使用した際には、WebブラウザとショートカットがコンフリクトしたりEC2のスペックによってインテリセンスが効かなかったりと、あまり使いこなすことができず、VS CodeのRemote ServerでCloud9のEC2へ接続して使用する運用に落ち着いていました。 そのため、今回のAWSが開発環境を用意してくれて、好きなエディターで接続して使ってくださいという方針は嬉しいです。
また、GitHub Actionsを使用するユーザーが大多数であることを認め、共存する形でCI/CDが改善されたことも大変喜ばしいです。 ブループリントのインフラがCDKで出力されるのも最高です！
現時点ではオレゴン(us-west-2)のみ使用可能となっており、早く東京リージョンで使用可能になるのが待ち遠しいサービスです。 説明だけではイメージがつかないところもあったので、しっかり触ってみたいと思います。
以上。CX事業本部Delivery部のきんじょーでした。
13
