AWS DevDay Japan 2022 で登壇した際の資料です
![AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実 / ideal-and-reality-when-implementing-cicd-for-ecs-on-fargate-with-aws-cdk](https://cdn-ak-scissors.b.st-hatena.com/image/square/5a04f9aad23003782e02d5e220fe43684f7bfdae/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F0e7bfe4c76ef4cedafce6fa52df23045%2Fslide_0.jpg%3F23367212)
ここまでBazel の利点をいくつか紹介しましたが、採用には懸念点もありました。次のセクションからは、どのような懸念があったか、それをどのように解決したのかを紹介します。 Xcode 統合 Bazel と Xcode の統合は Bazel の採用においてもっとも大きな懸念でした。 Xcode はビルドシステムと密結合したやや特殊な IDE なので、外部ビルドシステムとの統合が難しいのです。特に indexing や LLDB デバッグを正しく動作させるのは困難でした。 統合とはつまり、Bazel によるビルドのアウトプットを利用して Xcode がサポートする動作を再現することを意味していて、主に下記のような要件を満たす必要があります。 Bazel のビルド構成ファイル群を解析して Xcode プロジェクトを生成する Xcode ビルドの実行を抑制し、代わりに Bazel ビルドを実行する
ちょうどよいビルドツールEarthlyの紹介 ビルドツールと呼ばれるものは昔から現代まで使われているMake、JavaやKotlinでは一般的なGradle、Googleで使われていたものをOSS化したBazelあたりが有名です。他にも様々なビルドツールが存在するのですが、知名度は低いものの最近自分が注目しているEarthlyというビルドツールを紹介します。 まずEarthlyの特徴をBazelやGradleといった他のビルドツールと比較して簡単に紹介します。 Dockerfile + Makefile風のDSL どんなビルドツールでも基本的には独自DSLでビルド設定を書くことになりますが、EarthlyはDockerfileとMakefileを合体させたようなDSLとなっており、他のビルドツールと比較して分かりやすい方だと思います。このDSLについては後述しますが、このサンプルコードでも
こんにちは、かたいなかです。 最近、マイクロサービスアーキテクチャを採用した環境でプレビュー環境の実現方法についていくつかのパターンを比較し整理する機会がありました。 今回の記事では、プレビュー環境を構築するための要件をなるべく特定の技術に依存せずに紹介したあとで、ArgoCD、Istio、OpenTelemetryを使用した実装例をご紹介します。 目次 目次 プレビュー環境とは プレビュー環境の構成要素 PRごとのアプリケーションやルーティングの設定のデプロイ ヘッダ伝播 および ヘッダによるルーティング 実装例 ArgoCD ApplicationSet Istio OpenTelemetry Baggageヘッダ挿入用Proxy 動作確認 まとめ 補足: 実装例で考慮していないこと 画像等のCORS DBのアクセス権限 参考 プレビュー環境とは ここでのプレビュー環境とは、Pull
Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり February 4, 2020 lt;dr GoReleaser と GitHub Actions を使うと簡単にビルドしたバイナリを作ってアップロードできる。 2つの YAML を書いてリポジトリにコミットする .github/workflows/release.yml .goreleaser.yml git tag して push する バイナリがリリースされる 専用のツールをローカルにインストールする必要はない。 本題 前に、Go のコマンドラインツールを簡単にリリースする | tellme.tokyo というブログを書いた。 それよりももっと楽になったので紹介する。 基本的にこのページで紹介する方法では 2 つの YAML をリポジトリに置くだけで終わる。 ロー
関西支店で新規事業開発室に所属する加藤です。私のチームでは、Google Cloud Platform (GCP) で主にGoogle App Engine (GAE) を使ってシステムを構築しています。 GAEはコマンド1つで簡単にデプロイできますが、チームの開発者が増えるにつれて、デプロイ用の設定を共有するのが大変になってきました。 デプロイにも時間がかかって、リリース作業に負荷を感じるようになりました。 そこで、GAEアプリケーションの開発フローに、Cloud BuildによるContinuous Integration (CI) / Continuous Delivery (CD) を組み込み、デプロイを自動化しました。 公式ドキュメントや各種ブログに個別の方法は記載されていますが、開発フローに組み込もうとした時にいくつか考えることがあったので、まとめておきます。 前提 Googl
GitHub's Google Cloud Build integration does not detect a cloudbuild.yaml or Dockerfile if it is not in the root of the repository. When using a monorepo that contains multiple cloudbuild.yamls, how can GitHub's Google Cloud Build integration be configured to detect the correct cloudbuild.yaml? File paths: services/api/cloudbuild.yaml services/nginx/cloudbuild.yaml services/websocket/cloudbuild.ya
みなさんは GAE 使ってますか?デプロイはどうしてますか?? 私は最近まで手動でデプロイ先のプロジェクトを切り替え、手動でデプロイをしていました。その方が温かみのあるアプリケーションに仕上がるかと思い・・・ 冗談はさておき、今回は簡単な GAE のサンプルアプリを GCP プロダクトを用いて CI/CD する方法について解説していきます!平成も終わったことですし、手動でのデプロイも終わらせましょう! GAE アプリを作成してデプロイしてみよう! GAE とは GAE は GCP の中でも最も歴史のある PaaS です。コードを書いてデプロイするだけで、 Google の管理する強固なインフラ上でアプリを動かせることや、急激なトラフィックの増加にも柔軟に対応し、スケールしてくれるところが魅力です。今回は GAE の Standard Environment (SE) 上に Go で書いた簡
こんにちは。SWETの加瀬(@Kesin11)です。 Google Cloud Next ’18でGoogleのCI/CDサービスとしてGoogle Cloud Build(以後GCBと略します)というものが発表されました。 https://cloud.google.com/cloud-build/ https://www.youtube.com/watch?v=iyGHW4UQ_Ts CI/CDサービスを追っているものとして、これは要チェック! ということで、GCBを軽く使ってみて分かった特徴をCircleCIと比較してまとめてみました。 最初にまとめを書いてしまうと、GCBはCI/CDとして見るとCircleCIと比べてまだまだ扱いづらいところがあります。一方で、従量課金制のフルマネージドなビルドサービスというCircleCIとは違った使い方もできるところが特徴と言えます。 GCBの特
CI-as-a-ServiceでGo言語プロジェクトの最新ビルドを継続的に提供する Go言語で作成したツールのリリース方法について,最近実践していることを書く. リリースは,ローカルから人手で行っている.具体的には,自分のローカル環境でクロスコンパイルし,セマンティック バージョニングによるタグをつけ,CHANGELOG.mdを丁寧に書いた上でリリースをしている.クロスコンパイルにはmitchellh/gox,リリースには自分で作成したtcnksm/ghrを使っている(ghrについては,“高速に自作パッケージをGithubにリリースするghrというツールをつくった”を参考). その一方で,開発中の最新のビルドも提供するようにしている.例えば,こんな感じで,Pre-Releaseとして提供している.Go言語での開発なので,go getしてくださいと言える.しかし,環境によってビルドが失敗する
// Tutorial //How To Configure a Continuous Integration Testing Environment with Docker and Docker Compose on Ubuntu 14.04 An Article from Docker Introduction Continuous integration (CI) refers to the practice where developers integrate code as often as possible and every commit is tested before and after being merged into a shared repository by an automated build. CI speeds up your development pr
この記事は、はてなエンジニアアドベントカレンダー2016の12月18日の記事です。 はてなエンジニアアドベントカレンダー2016を始めます - Hatena Developer Blog 昨日はid:ikesyoさんの「オープンソース活動への取り組み方」でした。 オープンソース活動への取り組み方 - Hatena Developer Blog こんにちは。はてなでWebオペレーションエンジニアとして働いているid:taketo957です。 2016年の4月に新卒として入社してからは、社内の仮想化基盤のリソース最適化に取り組んでみたり、 speakerdeck.com 社内の広告配信システムの刷新プロジェクトに関わってきました。 speakerdeck.com 本記事では広告配信システムの刷新を行う中で取り組んだ負荷試験環境を構築する際に考えたことと「継続的にパフォーマンス改善を行うためには
こんにちは、エンジニアの堀江(@Horie1024)です。先日行われたAndroid Testing Bootcamp #2で「AndroidのCI環境をCircleCIからWerckerにした話」という内容で発表させて頂きました。発表に使用したスライドはこちらになります。 この投稿では、スライドでは単にリンクを貼って終わらせてしまったなど、詳細を紹介しきれなかった点についてご紹介しようと思います。 移行前に利用していたCircleCIによるCI環境について スライドでも紹介しましたが、iQONの開発では、1年半ほど前からCircleCIを導入していました。導入についての詳細は以下の投稿にまとめてあります。 tech.vasily.jp CircleCIで行っていたことは以下の通りです。 ユニットテスト BetaでのAPK配布 Google Playへのアップロード自動化 図にすると以下の
ほとんど Rocket.Chat.Android.LilyをCircle CIで自動ビルドしてFabric betaにアップロード で書いたのと変わりませんが、 今回は、会社の公式アプリをAndroid SDK v24対応するときにすこ~しだけハマったので、共有です。 android-24が無いと言われる * What went wrong: A problem occurred configuring project ':app'. > failed to find target with hash string 'android-24' in: /usr/local/android-sdk-linux git submodule init && git submodule update echo "sdk.dir="$ANDROID_HOME > local.properties ec
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く