Retty インフラチームの幸田です。 6月に実施したマイクロサービス強化月間で公開した記事では、マイクロサービス環境を Terraform を利用して刷新した話を書きました。 engineer.retty.me この記事では前回と重複する箇所もありますが、Terraform の CI/CD にフォーカスした内容を書こうと思います。 CI を整備するにあたって意識したこと 「誰でも」かつ「安全に」利用できるように CI 上ですべての作業を完結させる Pull Request によるレビュー環境の整備 バージョンアップ作業の完全自動化 Terraform のディレクトリ構成について リポジトリの運用フロー Terraform によるリソースの追加、変更、削除 tfmigrate によるステートファイルの操作 CI で実行される job について Pull Request をオープンした時 P
Intro Nx リポジトリが攻撃を受け、広範囲にわたるインシデントが発生した。 今回の事例は、GitHub Actions を中心に複数のステップが組み合わさった攻撃であり、過去に何度も発生してきた攻撃と本質的には変わらない。 しかし、途中で AI が何度か登場するため「AI が書いたコードをマージしたから」などといった表面的な反応もあるが、実態はそこまで単純な話でもない。 また、「自分のプロジェクトは Nx を使っていないから関係ない」とも言えない攻撃であるため、特にフロントエンドエンジニアは全員注意と確認が必要となる。 この攻撃が何だったのか、そこから学べることは何なのか、解説する。 Nx Incident 今回のインシデントについては、既に公式の Advisory が出ている。ニュース系の記事も多々あるが、一次情報は以下となる。 Malicious versions of Nx a
こんにちは！「家族アルバム みてね」（以下、みてね）SREグループのおじまです。 今回は、みてねの開発プロセスを支えるデプロイパイプライン、特にブランチ戦略を改善し、ステージング環境における占有問題などの課題を解決したお話をご紹介します。 みてねの開発フローとこれまでの課題みてねでは、ブランチ戦略としてGitHub Flowを採用しています。GitHub Flow では、はじめにメインブランチからフィーチャーブランチを作成します。フィーチャーブランチで機能開発を行った後、プルリクエストを作成します。フィーチャーブランチは、プルリクエストにおけるコードレビューを経て、メインブランチにマージされます。メインブランチは常にデプロイ可能な状態に保たれます。GitHub Flowは、シンプルで分かりやすいのが特徴です。 しかし、GitHub Flow自体には、本番環境以外へのデプロイ方法について明確
チューニング チューニングにあたっては、大きく以下の3点を重視しました。また、これらを管理するための「プロンプト」と「Knowledge」の使い分けも工夫しています（後述します）。 レビュー時のお作法を守らせる（AIは細かい作業に分解することが苦手な場合が多いため、ファイル単位でのチェックや処理の追い方といった手順をインプットしています） Railsアプリケーションにおける理想的な設計パターンをレビュー時に定着させる グロービス特有のドメイン知識・運用ルールを活用させる これらの観点で情報整理を行うことにより、「一般的に望ましい設計や実装方法」だけでなく、「自社特有の事情を反映した指摘」を自然に提示できるようになります。 また、知識の初期構築に多くの時間を割くことなく、実際に使いながらDevinにフィードバックを行い徐々に精度を高めていけるため、最初は小さく始めることを意識しました。 Kn
はじめに GitHub Script概要 セットアップ context の中身 eSquare Liveでの活用事例 発生した問題 タグの打ち間違い releaseブランチが複数存在する場合のデプロイ先選択の複雑化 解決策としてのGitHub Scriptの活用 機能1 vX.Y.Zのタグがmainブランチのコミットハッシュと一致することを確認する 機能2 releaseブランチは最新バージョンのみ自動で検証環境にデプロイする 完成版スクリプト まとめ はじめに こんにちは、enechainでeSquare Liveを開発しているエンジニアの古瀬(@tsuperis3112)です！ 今回は、マニュアル依存になりがちなデプロイフローの問題を actions/github-script で解消した方法についてお話します。 eSquare Liveの開発では、効率的かつ信頼性の高い開発フローを維
3秒まとめ Claude Code GitHub Actionsを使うと、@claudeでレビューからPR作成まで全部やってくれる /install-github-app一発で導入完了。めちゃくちゃ簡単 GitHub上でコミュニケーション完結するので、開発フローが超スムーズ Issue → 実装計画 → PR作成まで一気通貫でサポート *この記事は８割程度がAIのサポートにより執筆されていますが、スクリーンショットや使用感はヒューマンが試し、気づいたことを書いています どんな人向けの記事？ レビュー作業に時間を取られがちなエンジニア GitHub Actionsを使った自動化に興味がある方 AI活用で開発効率を上げたいチーム Claude Codeって何？と思っている方 レビューって面倒じゃないですか？ レビューは得意ですか？ ぼくは正直、レビューがあまり得意じゃありません😅 「このコー
PR-Agent を使って Pull Request をAIレビューしてみた。（日本語対応もしてみた） - LayerX エンジニアブログ
LayerXの suguru です。 今日は、バクラクの開発に導入した PR-Agentの話をしようと思います。 PR-Agent は、Codium AI によってオープンソースで開発されている ChatGPT を使ったプルリクエストを便利にするためのAIツールです。 現時点で、下記のような機能を持っています。 Pull Request の自動分析およびレビュー Pull Request のタイトルと説明文を自動入力 コード改善の提案 フリーテキストな質問への回答 CHANGELOG の自動生成 必要なものは、 OpenAI のキーのみのため、CIに簡単に導入できます。 GitHub上へのインラインコメントなどにも対応しており、普段開発する際に面倒なプルリクエストに関する様々な作業を自動化することができます。 裏側ではデフォルトで GPT-4 を使っており、ソースコードを解析し、高精度な結
大分時間が経ってしまいましたが、2022/8/31 に開催された stand.fm 主催の TECH STAND #9 GitHub イベントに参加しました。 その際に呟いたやつが今回の記事の内容です 有り難いことに直ぐにフォロー頂きました。 あまり纏まった記事が見当たらなかったので、自分用のメモとしてまとめます。 他のCIにはあったアレ GitHub Actions を利用する前は、TravisCI や CircleCI を利用していました。 移行してから随分使ってないので、記憶が定かではないのですが という機能が標準であった気がします。 この機能の名前は何と呼ぶのでしょうか？地味だけれども、ないと困るアレですｗ GitHub Actions のリリース直後にこちらの機能と [ci skip] が使えずに後発なサービスなのにーと不満を覚えていました。 その後にアレの機能を実装したカスタム
分類の観点としては以下を総合的に判断するようにしています。 変更が影響するコンポーネントやモジュールの数 既存の振る舞いへの影響度（インターフェース変更、DB変更、API変更など） 変更の波及範囲（他の機能やサービスへの影響） リスクの大きさ（決済・認証など重要ドメインへの関与） 2. AIによるコードレビューとApprove 同じworkflowの中で、AIがコードレビューも実施します。レビューの観点は人間のレビュアーと同じです。 コード品質とベストプラクティス 潜在的なバグ パフォーマンスへの影響 セキュリティの問題 テストカバレッジ そして、上記の観点で重大な問題がなければ、AIがApproveをsubmitします。 3. XSラベル × Approve済み → auto merge 最後のピースとして、以下の条件をすべて満たすPRでauto mergeを有効化するようにしました。
はじめに 以前からGitHubのプルリクにAIサポート、Copilotがあればいいのにと思っていました。 Github Copilot for Pull RequestもありますがCopilot Enterpriseに登録した企業のみなので シンプルかつ個人でも始められそうなChatGPT CodeReviewを導入してみます。 ChatGPT CodeReviewを導入する OpenAIの作業 1. OpenAIアカウントに登録、ログインする 2. 課金する Setting - Billingを選択します。 Add to credit balanceを選択して、クレジットカードを登録します。 ミニマム$5〜から課金を行います。 3. APIKey作成 API Keysを選択します。 Create New Secret keyを選択してAPI Keyを作成します。 API keyを安全な場
GitHub Actions / GitHub CLI を使った PR レビューをサポートする取り組み - Uzabase for Engineers
NewsPicks でサーバーサイドエンジニアを務めている池川です。 サービス運営をされている会社さんであれば、どの会社さんでも何らかの障害を起こし、その対策のための MTG を実施されていると思います。 が、サービスを長く運営していると、過去に発生してしまった事故と似た事故を発生させてしまうということが往々にしてあります。 NewsPicks でも、そのような事故が発生し、どうしたものかということが MTG での話題にのぼりました。 そこで、 NewsPicks ではそのような事故を風化させないための取り組みとして、事故が発生しそうな PR に対して、 GitHub Actions を用いて注意をうながすメンションを投げるワークフローを設定しました。 簡単な取り組みとなっているので、ご参考になれば幸いです。 背景 使用したツール 処理フロー GitHub Actions での実装 実際の
Claude Code Action は Claude Code を GitHub Actions のワークフローに統合するためのアクションです。これを使用することで、GitHub 上でコードの生成やレビューを AI に依頼することができます。 Claude Code Action は Claude Code を GitHub Actions のワークフローに統合するためのアクションです。これを使用することで、GitHub 上でコードの生成やレビューを AI に依頼できます。 Claude Code Action のセットアップ Claude Code Action のセットアップは非常に簡単です。ターミナル上で Claude Code を使用してコマンドを実行するだけです。前提として Claude Code をインストールしておく必要があります。 npm install -g @anth
AI開発ツールDevinが作成したPull Requestに対して、セキュリティと品質を確保するために2人の承認を必要とする実装方法について解説します。 2025/05/21 追記 レビューコメントが30件以上あったときに正しく動かない問題を修正しました 開発者が書いたPull RequestをDevinにApproveしてもらってマージするパターンも防ぎたい場合は、ifの条件を少し変える必要があります。 背景 newmoでも少し前からDevinを利用して開発を行っています。 Devinを利用するフローは、以下のような感じになります。 エンジニアがSlackやDevinのWeb UIからタスクを依頼 DevinがGitHubにPull Requestを作成 エンジニアは必要に応じてSlackやPull Request上でコメント Devinがコードを修正 問題なければ承認してマージ dev
テックブログの校正を支える技術 textlint とルール設定について｜Offers Tech Blog
Offers を運営している株式会社 overflow の あほむ です。「〜を支える技術」的な技術評論社さまの伝統的パンチラインに感化されてしまう世代です。 文書校正の自動化でおなじみの textlint textlint は JSer.info や JavaScript Primer でおなじみの azuさん が開発されている OSS です。 ESLint に代表される各種 Lint ツールの自然言語バージョンです。プレーンテキストや Markdown テキストを対象にいわゆる文章校正を自動的に走らせて、ルールによっては自動修正も適用できます。 弊社のテックブログは GitHub リポジトリで zenn のコンテンツを管理 しており、そのリポジトリ上で textlint を使ってルールに従った文章校正の自動化を試みています。 GitHub Actions の設定 設定はシンプルで Pu
はじめに モチベーション 実装 インフラリポジトリ（Terraform 変更） アプリケーションリポジトリ（ECS タスク定義変更） 横展開：Reusable / Caller 構成への移行 運用風景 コスト影響がない変更の場合 コスト影響がある変更の場合 おわりに はじめに 弊社では AWS 上にマルチテナント構成のインフラを複数の環境にわたって運用しており、その構成管理を Terraform でおこなっています。インフラ側のリソース構成はもちろんのこと、アプリケーション側で管理されている ECS タスク定義の CPU / メモリ割り当てに対しても、折に触れて変更が入ります。 こうしたリソース変更は無論コストに跳ねます。新規コンポーネントの追加やインスタンスサイズの変更が Pull Request（以下 PR、サービスによっては Merge Request 等の呼称もあります）として上が
GitHub Actionsで実行されるCIのキャッシュが初回実行だけ効かない問題を紐解く - Nealle Developer's Blog
背景と悩み SREチームの大木(@2357gi)です。いよいよ暖かくなってきましたね。春スキーの季節です。 チーム開発においてCIを如何に高速化するかという話は日夜行われていると思います。 弊社でも同様のことが行われており、その中でパッケージ管理ツールによるライブラリのキャッシングなどの高速化も実施しています。 しかし、キャッシュを指定しているはずなのに、「PRを作成して最初に走るCIではキャッシュがまったく効いていない」 というケースが存在しました。 お使いのGitHub Actions Workflow によっては実は同じ症状の方もいると思うので、ご参考になれば幸いです。 GitHub Actionsのキャッシュ仕様のおさらい GitHub Actionsのキャッシュはブランチごとに分けて生成されます。 もう少しいうと、キャッシュは「 ワークフローが実行されるブランチ」に紐づいて生成さ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は Terraform Advent Calendar 2024 の 23日目の記事です。 TerraformのCI/CDどうしてますか？私は長年Atlantisを愛用していました。Atlantisは、Terraform/OpenTofu用のCI/CDサーバで、自分で使う分にはどちゃクソ便利なんですが、サーバを自前で建てないといけないのがネックで、なかなか初心者や小規模な環境にはオススメしづらいのが悩ましいところです。 なんかよい代替手段はないかしら？と思って最近使ってみているのがDiggerです。DiggerはGit
この記事では、Cloud Service Mesh for Cloud Run を利用して PR 環境を構築する方法について紹介します。 背景・概要 newmo ではトランクベース開発を行なっているため、開発環境での動作確認は main branch (trunk) に merge されていることが前提になっています。 そのため現状では、手軽に開発環境で API の動作確認ができなかったり、動作検証が十分でないコードが main branch に merge されてしまう課題があります。CI での test 実行などにより一定品質は担保していますが 、PR 環境 (GitHub の Pull Request ごとに用意される一時的な環境) で QA ができれば問題発見のタイミングを前にずらすことができます。 PR 環境の要件は以下の通りです。 機能追加を行なった PR が実際に Cloud
tl;dr; モチベーション 技術的なこと 注意点 苦労したポイント One more thing 2026/2/20 23:50追記 tl;dr; 自分が管理してるOSSで Dependabot Security Alert で作られたPRに対して自動でタイトルにCVE IDをつけたりsecurityラベルをつけられるようにしました モチベーション PRのタイトルにCVE IDを書いておくとリリースノートでオートリンクされて便利です。 今まではDependabot Security Alertが作ったPRに対して手でタイトルを修正をしてたのですが、自動化の機運が高まったのでやりました。 技術的なこと dependabot/fetch-metadata で alert-lookup: true をつければGHSA ID（ https://github.com/advisories 上のID
【最強のプルリクレビュー環境】 GitHub ActionsとPHPStanを繋げてPRのコード上に自動で静的解析のエラーが出てくる仕組みを作る - Qiita
GitHubでプルリクをレビューするとき、こんな風にコード上に勝手にエラーがあるよ！って表示されたら嬉しいなあということがあります。 わざわざCIの実行結果を見に行ってひとつひとつエラーを確認するのは面倒ですからね。 というわけで、今回は上の画像のように自動でエラーがコード上に現れて教えてくれる環境をGitHub Actionsで作りたいと思います。 大前提 PHPStanがプロジェクトに導入されている 今回はPHPStan 1.5.4を使用して検証しています PHPStanが入ってないと話が始まらないので、まずは入れておきましょう。 GitHub ActionsからPHPStanが走るようにする 以下の設定を入れておきます。 name: PHPStan on: push: branches: - main - master - develop pull_request: types: -
どうも、Repro Core Unit に所属している村上です。 Repro では現在、20 を超える Kafka Streams アプリケーションが稼働しています。 その中の半分くらいが Repro システムの共通基盤を構成する Kafka Streams アプリケーションであり、それらの運用は Repro Core が持つ責務の 1 つとなっています。 この共通基盤となる Kafka Streams アプリケーション群は、Gradle のマルチプロジェクト構成になっていてコードベースはモノレポで管理されています。 本稿では、この構成におけるデプロイ性の課題とそれに対するアプローチの話をします。 ディレクトリ構造 共通基盤のコードは以下のようなディレクトリ構成になっています。 . ├── Base ├── Deployments A │ └── Kafka Streams Applica
この記事は GENDA Advent Calendar 2025 - シリーズ 2 - 4日目の記事です。 はじめに - デフォルト設定の課題 anthropics/claude-code-action は GitHub Actions で手軽に AI コードレビューを導入できます。 レビュー自動化によるレビュアーの負荷軽減と、 Claude Code から /install-github-app コマンド一つで導入できる手軽さが魅力で、多くのプロジェクトで導入されています。 しかし、デフォルト設定のまま運用しているといくつかの課題に直面することがあります。 課題 ひとかたまりの長文レビュー デフォルトの設定では、Pull Request (PR) 全体に対して1つの長いコメントでフィードバックが返ってきます。 網羅的ではあるものの、具体的な指摘箇所とコードの対応付けが難しく、「読むだけで
trivyとGithub Actionsを使用しTerraform設定ファイルのセキュリティスキャンを実行する仕組みを作りました - コネヒト開発者ブログ
この記事はコネヒトアドベントカレンダー21日目の記事です。 コネヒト Advent Calendar 2023って？ コネヒトのエンジニアやデザイナーやPdMがお送りするアドベント カレンダーです。 コネヒトは「家族像」というテーマを取りまく様々な課題の解決を 目指す会社で、 ママの一歩を支えるアプリ「ママリ」などを 運営しています。 adventar.org はじめに コネヒトのプラットフォームグループでインフラ関連を担当している@yosshiです。 今年の7月に入社してから早いもので半年が経ちました。時が経つのは本当に早いですね。 今回のブログでは、セキュリティスキャンツールであるtrivyを使って、自動的にIaC (Infrastructure as Code)スキャンを実行する仕組みを構築した話をしたいと思います。 弊社ではインフラ構成をTerraform利用して管理するようにして
こんにちは！ファンと共に時代を進める、Web3スタートアップのGaudiyでエンジニアをしている勝又（@winor30）です。 Gaudiyのプロダクト開発において、最も大切にしていることの1つに、ファンダムな最高のユーザー体験を提供することがあります。 今回は、このファンダムなユーザー体験を提供しながら、プロダクトの成長速度を落とさないために取り組んでいる、UX中心のスキーマ駆動開発についてまとめてみます。 具体的な開発フローや工夫している点についてまとめたので、同じような課題を抱えるチームのご参考になれば嬉しいです！ 1. 取り組みの背景 2. Gaudiyのアーキテクチャ構成 3. UX中心のスキーマ駆動開発の概要 3-1. すべてのインターフェースをスキーマ駆動で開発 3-2. スキーマのズレを検知できるようにする 3-3. システム全体の結合は開発初期の段階で行う 3-4. FE
AtlantisのようにPull Requestが作成されたタイミングでlambroll deploy --dry-runが実行され、/deployとコメントすることでlambroll deployが実行されるGitHub Actionsのワークフローを作ってみた。 デモ デプロイされたら自動でマージされる エラーになったらマージされない ボットのコメントは最新のもの以外は自動で最小化される 実装 ファイル構成 / ├── .github/ │ └── workflows/ │ ├── deploy.yml │ ├── dry-run.yml │ └── lambroll.yml ├── .gitignore ├── .lambdaignore ├── function.jsonnet ├── index.mjs └── option.jsonnet deploy.yml
どうもみゅーとんです. 最近パフォーマンス周りで問題をおこしかけてしまったので, パフォーマンスの劣化を抑制する方法を調べてみました. 概要 3 行でまとめ public repository であれば, CodSpeed を無料で利用できる main ブランチでのパフォーマンスを計測しておき, Pull Request で劣化したら警告してくれる CodSpeed から, 内部処理を詳細に追うことができる 前提知識 vitest でパフォーマンステストを行う構成ができていることが条件になります. 導入方法についてはこの記事を確認してください. techblog.hacomono.jp CodSpeed とは docs.codspeed.io なんて読むんでしょうか・・？私はコードスピードと呼んでいますが, コッドスピードのほうが正しそう・・？ GitHub Actions で実行した P
Amplify Hostingのプレビュー環境をGitHub Actionsでデプロイする - ROUTE06 Tech Blog
こんにちは、ROUTE06でソフトウェアエンジニアをしている @MH4GF です。 Amplify Hosting を利用してホスティングしている Web アプリケーションで、プレビュー環境を GitHub Actions でデプロイする方法を紹介します。 背景 Amplify Hosting では、実はプルリクエストベースのプレビューを機能として提供しています。 docs.aws.amazon.com プルリクエストの作成と同時に環境にアクセスする URL が払い出され、Gitのコミットのプッシュと同時に再ビルドし、プルリクエストのマージと共に環境を削除します。 ビルドの進捗状況もプルリクエストの Checks として確認できるため、概ね期待する機能は揃っています。 ただ、運用する上でどうしても気になる点がありました。 モノレポで構築されているリポジトリで、ビルドの発火するディレクトリパ
はじめに こんにちは、iOSアプリエンジニアの羽柴です。本記事では、LINEの膨大なソースコードを扱う上で欠かせない「コードオーナー」の設定率を向上させるため、GitHub Actionsとして実装したチェッカーツールについてご紹介します。 プロジェクトの背景 LINEは、2011年のリリース以来急成長を遂げて来たアプリです。その巨大なコードベースにおいて、特に古くからある機能などに、どのチームがオーナーシップを持っているのかわからないことがあります。これを解決するのがコードオーナーです。ファイルにコードオーナーが設定されていれば、そのコードに修正を加える際に迅速な議論や開発をすることができます。したがって、LINEプロジェクトにおけるコードオーナーの設定率向上を目指す"CODEOWNER Improvements"というプロジェクトが発足しました。このプロジェクトの取り組みの一つが、今回
開発品質とDeveloper eXperienceを高めるコンテナ開発環境のご紹介 (Python) - ABEJA Tech Blog
はじめに こんにちは 2023年1月に入社し、システム開発グループでエンジニアをしてる春名です。 私の所属しているシステム開発グループでは、開発初期の環境構築をより効率的に行うための活動に取り組んでいます。 今回はそのうちの一つである、Pythonでコンテナ開発をする環境を構築した内容をご紹介します。 なぜコンテナ開発環境かと言いますと、単にAWSのECSやGoogle CloudのCloud Runを使ってデリバリーする案件が多いからです。 より使用頻度の高い開発環境を整備し、テンプレート化しておくことで開発の効率化に活用しています。 2025/12/19 追記 最新のPython開発環境を以下の記事でご紹介しています！ tech-blog.abeja.asia 本記事の内容もご参考にいただきつつ、最新の情報をご確認ください🚀 目次 はじめに 目次 今回作成する環境 Poetryによる
はじめに 弊社では、2023年11月よりOSSチームの活動がスタートしました。 このチームに参加しているメンバーは、1週間のうちの1日分の稼働をOSS活動に割り当てる事ができます。社員の技術力向上及び、日頃使わせていただいているOSSコミュニティに対する恩返しをチームのミッションとしています。 OSSチーム以前のOSS部では下記のような活動も行っていました。 今回は、OSSチームで新たに開発したGitHub Custom Actionsについて紹介させて頂きます。 GitHub Custom Actions GitHubActionsでusesの所に指定するアレです。 Docker Container ActionsやJavaScript Actions、Composite Actionsなど、さまざまな種類が存在しますが、今回はCustom Actionsの詳細な解説は省略させていただき
PR に紐付けたいワークフローは push ではなく pull_request イベントを使おう [GitHub Actions]
概要 ジョブ実行画面に PR へのリンクがないから不便という記事に賛同している人が思いのほか多かったのでこの記事を書いておきます。 pull_request イベントは PR へリンクされる pull_request イベントには最初から PR へのリンクが用意されています。 なぜ push イベント？ push イベントを使いたくなる理由は主に以下の 2 つかなと思っていますがいずれも pull_request イベントで実現可能です。 PR が更新されたときに実行したい PR のブランチで実行したい PR が更新されたときに実行する pull_request イベントはデフォルトで types: [ opened, synchronize, reopened ] のときに実行されます。 このうち synchronize が PR が更新されたときに該当します。 PR のブランチで実行す
![PR に紐付けたいワークフローは push ではなく pull_request イベントを使おう [GitHub Actions]](https://cdn-ak-scissors.b.st-hatena.com/image/square/b7a58e15f4766e9f2e45b9f6e7154948112ca016/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--sIXjR-Qn--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3APR%252520%2525E3%252581%2525AB%2525E7%2525B4%252590%2525E4%2525BB%252598%2525E3%252581%252591%2525E3%252581%25259F%2525E3%252581%252584%2525E3%252583%2525AF%2525E3%252583%2525BC%2525E3%252582%2525AF%2525E3%252583%252595%2525E3%252583%2525AD%2525E3%252583%2525BC%2525E3%252581%2525AF%252520push%252520%2525E3%252581%2525A7%2525E3%252581%2525AF%2525E3%252581%2525AA%2525E3%252581%25258F%252520pull_request%252520%2525E3%252582%2525A4%2525E3%252583%252599%2525E3%252583%2525B3%2525E3%252583%252588%2525E3%252582%252592%2525E4%2525BD%2525BF%2525E3%252581%25258A%2525E3%252581%252586%252520%25255BGitHub%252520...%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3A%2525E9%25259B%2525AA%2525E7%25258C%2525AB%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FPaDE0R2dsdnpGMmRXRHdxQlZmQ0hHd2Z6bV9PTW5YeTZjVElKVm1WOVV4Tmc9czI1MC1j%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png%3F_a%3DBACAGSGT)
Claude Code GitHub Actions で Dependabot が作成した PR を自動マージ | CyberAgent Developers Blog
はじめに この記事は CyberAgent Developers Advent Calendar 2025 9 日目の記事です 🎅 こんにちは。ABEMA の広告配信システム開発チームでバックエンドを担当している戸田朋花です。 ABEMA の広告配信システムは大規模なシステムなため依存するパッケージが多いです。 セキュリティの観点から依存パッケージは定期的にバージョンアップして最新に近い状態を維持するのが重要です。しかし、依存が多いプロジェクトではひとつひとつ更新を確認し必要なバージョンアップを行う作業が負担になります。 この作業を自動化する方法の一つに Dependabot の活用があります。Dependabot とは GitHub で利用可能な依存関係を管理するためのツールで、リポジトリで使用している依存関係の脆弱性について通知したり、依存関係を最新に保つための Pull Reque
このエントリーは一休.com Advent Calendar 2024の6日目の記事になります。 デモ環境を簡単に作りたい 特定の新機能を関係者にお披露目するためのデモ環境は、簡単に作れて、かつ、修正も素早く反映できると、うれしいです。 デモ環境へのデプロイは、特別なことをするのではなく、既存の開発ワークフローに混ぜ込みたい。 デモ環境は、静的な配置場所があるのではなくて、デプロイ時に動的にリソース確保して作成され、使い終わったら、破棄される。静的な配置場所があると、「デモ環境使いたいので使い終わったら教えてください」的なやり取りが生まれますが、これは、なくしたい。 このうち、1.は、Github ActionsでGithubのイベントをトリガにして、既存の開発ワークフローにうまく混ぜ込んでデプロイできそうです。 2.については、Kubernetesを使って、ロードバランサからアプリケーシ
Claude Code hooksで始めるPromptOps：チームで意図を残す仕組み作り - Algomatic Tech Blog
こんにちは。Algomatic AI Transformation(AX) の柗村@yu_mattznです。 私は7月にAIプロダクトエンジニアとして入社し、今はネオデザインAIの開発責任者をしています。プロダクト出身でAIについての深い知見はないため、日々AIエンジニアの方々の投稿からキャッチアップできて最高な環境です。 今回は、Claude Codeをチームで使う際、プロンプトを共有するのが今後大事になってくるのではないか？と考えたきっかけとその取り組みを紹介します。 Claude Codeを導入してみて Claude Codeが出た時、部署では一瞬で使用を許可していただきました。(爆速。感謝) 使ってみて、フロントもバックエンドも一通して開発させることができ、実装スピードは跳ね上がりましたが、バックエンドは自身が使用してきた言語ではなかったのもあり、コードレビューがボトルネックになり
Pull RequestごとにGitHub ActionsでSnykを動かしてみた - TC3株式会社｜GIG INNOVATED.
はじめに 最近よく目にするようになったSnyk。なんて読むかご存知ですか？「すにぃく」や「すにっく」と読み、鍵を閉める際の音を表し、セキュリティ強化するという意味合いがあるようです。なお、 ‘So Now You Know’ （日本語だと「これでお分かりでしょう」のような意味）の頭文字をとったものらしいです（参考）。開発者向けのセキュリティツールで、GitHub Actionsなどのソースコード管理システム（SCM)との連携などを行い、開発プロセス中にセキュリティチェックをしてくれる、注目度が高まるツールです。ちなみにSnyk社のロゴの犬はドーベルマンで、Patch（パッチ）という名前のようです（参考）。 今回は、SnykとGitHub Actionsと組み合わせた活用例をご紹介します。開発者からのプルリクエストをトリガーで起動し、自動でSnyk Open Sourceによる脆弱性チェック
monorepoをなぜ採用したか、及び大まかな構成： 三井物産デジタルアセットマネジメントでの事例｜Matsumoto Yuki
皆さんこんにちは、代表取締役CTOの松本（@y_matsuwitter）です。最近買ったSonyのlinkbudsがめちゃ快適で感動しています。骨伝導イヤホンから乗り換えました。 さて、再びLayerXアドベントカレンダー（概念）がスタートするようです。もはやアドベントとは何なのか分からなくなっておりますが、継続してブログ書いていこうというチームでの決意表明となります。 今回は私が見ているプロジェクトの一つでmonorepoを採用し、その立ち上げ最中となりますので、まずはその採用目的や大まかにどのような構成をとったのかという話をさせてください。今レポジトリ構成でmonorepoを検討中の方の参考になればと思います。 背景今回取り上げるmonorepoは、三井物産デジタルアセットマネジメントにおける業務効率化、特に物件等の運用に関わる業務の改善プロジェクトにて採用したものとなります。もともと
AWS App RunnerとGitHub Actionsでレビュー環境を構築する - BASEプロダクトチームブログ
この記事はBASE Advent Calendar 2021の22日目の記事です。 はじめに はじめまして、Owners Success Frontend Shop Frontチームの坂口です。 普段はフロントエンドエンジニアとしてVue.jsを使った開発をメインに行なっているのですが、チームでプロジェクトマネージャーやデザイナーが手軽に動作を確認できるレビュー環境がほしいという話があり、AWS App RunnerとGitHub Actionsを連携して構築をしたのでその話をしたいと思います。 レビュー環境とは レビュー環境というのはGitHubのプルリクエストやブランチごとに動作確認ができる環境で以下のような動きをするものを今回は構築することにしました。 プルリクエストが作成されるとレビュー環境立ち上げ (作成) プルリクエストに紐付いたブランチが更新されるとレビュー環境更新 (更新)
# https://aquasecurity.github.io/tfsec/v1.0.11/getting-started/configuration/github-actions/pr-commenter/ name: Run tfsec PR commenter run-name: tfsec PR commenter on: pull_request: types: [synchronize, opened] jobs: tfsec: runs-on: ubuntu-latest steps: - name: Clone repo uses: actions/checkout@master - name: Terraform security scan uses: tfsec/tfsec-pr-commenter-action@main with: github_token: ${
GitHub Actions で Terraform の CI/CD を構築する | MoT Lab (GO Inc. Engineering Blog)
タクシーアプリ「GO」、法人向けサービス「GO BUSINESS」、タクシーデリバリーアプリ「GO Dine」の分析基盤を開発運用している伊田です。GitHub Actions から OIDC トークンを利用し、サービスアカウントキーなしで GCP に認証した上で Terraform の CI/CD を構築する方法を紹介します。 ※ 対象読者は分析基盤を管理しているデータエンジニア、または Terraform を管理しているエンジニアです はじめに本記事では、なぜ Terraform の CI/CD を構築したのか、まず分析基盤について簡単に説明し、次に分析基盤のうち Terraform で何を管理しているのか説明します。その上で現状抱えていた課題とそれに対する対応案を説明させて頂き、実際に構築に使用した技術要素やコード、運用にあたって気をつけたことについて紹介させて頂きます。 分析基盤に
Googleは2025年8月6日、Gemini CLI GitHub Actionsをベータ公開したようです！ ターミナル向けのオープンソースAIエージェントGemini CLIをワークフローイベント（Issue/PR など）で非同期に呼び出し、ラベル付け、コードレビュー、さらには @gemini-cli メンション経由でのタスク委譲まで自動化できます。 個人向けにはAI Studioの無料枠（1,000req/day ほか）が利用でき、Enterpriseでは Vertex AI＋Workload Identity Federationで鍵レス運用も可能です。 この記事では、セットアップから代表ユースケース、ベストプラクティスまでをさらりと解説します。 Gemini CLI と GitHub Actions の概要 Gemini CLI は ReAct ループを採用した AI エージェン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Retty の Terraform CI/CD 解体新書 - Retty Tech Blog
Nx の攻撃から学べること #s1ngularity | blog.jxck.io
ブランチ戦略（GitHub Flow）を見直してステージング環境の運用を改善しました
Devinにコードレビューをさせ、コード品質と開発速度を同時に高める話
CI/CD革新 GitHub Script活用術 - enechain Tech Blog
GitHub WorkflowにClaude Codeを統合するとレビューもPRもよしなにやってくれる良い話🎉
GitHub Actionsで連続pushした時に止めるアレ
PRのレビューが追いつかない！もう人間がボトルネックなので、気合いではなく仕組みで少しずつなんとかしていく
【GitHub】 プルリクエストにAIレビューを導入してみた - Qiita
Claude Code Action で Claude Code を GitHub に統合しよう
Devinが作るPull Requestのセルフマージを禁止する - newmo 技術ブログ
Claude Code に AWS コストを PR 上で試算させる - MNTSQ Techブログ
Digger + GitHub Actionsで作るTerraform/OpenTofuのCI/CD - Qiita
Cloud Service Mesh for Cloud Run で実現する PR 環境 - newmo 技術ブログ
DependabotのSecurity Alertで作られたPRをいい感じにする - くりにっき
マルチプロジェクト構成リポジトリにおいて変更の影響を受けるプロジェクトを検出する - Repro Tech Blog
本家に学ぶ Claude Code Action のサブエージェント並列レビュー
UXの向上と開発の生産性を両立するスキーマ駆動開発 - Gaudiy Tech Blog
Pull Requestへのコメントでlambroll deployを実行する - so what
(小ネタ) Vitest でパフォーマンス劣化を検知する - hacomono TECH BLOG
LINEのアプリ開発を支えるコードオーナー管理
ブランチ名をもとにPRに自動でラベルを貼るGitHubActions
Github ActonsとKubernetesを使って効率的にデモ環境を作る
Github Actions で見る tfsec と Trivy の今 ~ Terraform 静的解析
【最新】GitHub ActionsでGemini CLIを活用してみよう