個人的なJavaScriptの情報収集の方法についてまとめてみます。 JSer.infoなどをやっているので、JavaScriptの情報については色々な情報源を見るようにしています。 JSer.infoの範囲の中での情報源については、次の記事でまとめています。 JSer.info 13周年: JavaScriptの情報源を整理する - JSer.info この記事では、少しスコープを広げてJavaScriptの情報収集についてまとめてみます。 かなりスコープが広がってしまうので、万人向けの方法ではなく、個人的な情報収集方法としてまとめています。 この記事では、膨大な情報の中から見つけるというアプローチをとっているので、人によって向き不向きがあると思います。 情報収集の方法 情報の元となる情報源はさまざまなサイトや人になると思います。 しかし、そのサイトや人ごとに見ていくというのはかなり大変
社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
開発に使える脆弱性スキャンツール - NTT docomo Business Engineers' Blog
この記事は、 NTT Communications Advent Calendar 2022 7日目の記事です。 はじめに こんにちは、イノベーションセンター所属の志村と申します。 「Metemcyber」プロジェクトで脅威インテリジェンスに関する内製開発や、「NA4Sec」プロジェクトで攻撃インフラの解明・撲滅に関する技術開発を担当しています。 今回は「開発に使える脆弱性スキャンツール」をテーマに、GitHub Dependabot, Trivy, Grypeといったツールの紹介をさせていただきます。 脆弱性の原因とSCAによるスキャン 現在のソフトウェア開発は、多くのOSSを含む外部のソフトウェアに依存しています。Python、Go、npm など多くの言語は、様々なソフトウェアをパッケージとして利用できるエコシステムを提供しており、この仕組みを利用してOSSなどのコンポーネントをソフト
Retty インフラチームの幸田です。 6月に実施したマイクロサービス強化月間で公開した記事では、マイクロサービス環境を Terraform を利用して刷新した話を書きました。 engineer.retty.me この記事では前回と重複する箇所もありますが、Terraform の CI/CD にフォーカスした内容を書こうと思います。 CI を整備するにあたって意識したこと 「誰でも」かつ「安全に」利用できるように CI 上ですべての作業を完結させる Pull Request によるレビュー環境の整備 バージョンアップ作業の完全自動化 Terraform のディレクトリ構成について リポジトリの運用フロー Terraform によるリソースの追加、変更、削除 tfmigrate によるステートファイルの操作 CI で実行される job について Pull Request をオープンした時 P
Devin, Coding Agent (Github Copilot), Codex (OpenAI) やJules (Google)のような、バックグランド動作するコーディングエージェントが続々と発表されて、ついに先日のAnthropicのカンファレンスでClaude Codeでも同様のことが行えるようになりました！ Claude CodeのDevin型コーディングエージェントはGithubワークフロー上で動作するのですが、なんと実装のコードがなんと公開されているではありませんか！！ プロンプトやGithubのMCP設定等の実装も垣間見ることが出来ます！ AIエージェントを開発している身からすると常時稼働型エージェントを作りたいと考えており、バックグラウンド型のコーディングエージェントの動作はどうしても深ぼらねばと思っていた矢先に撒き餌が...！ それだけでなく、プロンプト設計自体の完
Pull Requestを小さくする戦略 - 開発チームのパフォーマンス向上のための第一歩 - Agile Journey
Agile Journeyをご覧の皆さん、こんにちは。ZOZOの御立田です。 私が所属する株式会社ZOZOは、「世界中をカッコよく、世界中に笑顔を。」を企業理念として掲げ、ファッションEC「ZOZOTOWN」、ファッションコーディネートアプリ「WEAR」などの各種サービスの企画・開発・運営や、「ZOZOSUIT」「ZOZOMAT」「ZOZOGLASS」などの計測テクノロジーの開発・活用をおこなっています。また、カスタマーサポート、物流拠点「ZOZOBASE」を運営しています。 ファッションコーディネートアプリ「WEAR」やショップスタッフの販売サポートツール「FAANS」を手がける、私が所属するブランドソリューション開発本部では、「開発生産性を3倍に」を目標に掲げ、多くの改善を進めています。 「開発生産性」をどのように定義するかには議論がありますが、まず私たちが向き合ったのは「仕事量の生産
This guide provides tips and tricks for effectively using Claude Code, a command-line tool for agentic coding. Using Claude Code as a Bash CLI Claude Code (often invoked as claude or cc) can be used similarly to other bash-based command-line interfaces. Use CC as a bash CLI You can perform many standard command-line operations. For example, to checkout a new branch and lint the project: claude "ch
2025年の大晦日も目前。 大晦日といえば「除夜の鐘」ですね。 「除夜の鐘」とは、人間にあるとされる108種類の煩悩（悩みや心の迷い、苦しみ）を鐘を1回撞くごとに1つずつ消し去り、清らかな心で新年を迎えるための日本の風習です。 今回、もうすぐ大晦日を迎えるにあたり、「除夜の鐘」をテーマに「業務効率化の難しさや悩み」を「煩悩」に例え、それを解決した108個のAI活用法をまとめました。 スマートバンクは現在約70人ほどの社員数ですが、無理に絞って108個にしたほど全職種で積極的にAI活用をしています。 来年からの、みなさんの業務のご参考になれば幸いです。 このnoteでは、テキスト検索がしやすいように上のスライド内容を全てテキスト化しました。職種ごとに並べているので目次から気になる箇所をクリックしてご参照ください。 ■BizDev/マーケター/PR【001】管理画面のAI判定付き一括更新スクリ
フロントエンド開発では、UIの挙動を含めてアプリ全体を検証するE2E（End-to-End）テストが重要になっています。しかし、導入や運用の難しさから、実践に踏み出せていない方もいるのではないでしょうか。 本記事では、前後編に分けて、シンプルなウェブアプリを題材に、Playwrightプレイライトを用いたE2Eテストの導入から活用までの流れを解説します。 前編では、Playwrightの導入方法やテストコードの基本的な書き方、テスト実行の流れについて紹介しました。後編となる今回は、失敗したテストの原因を特定するのに役立つトレース機能について解説します。さらに、CI環境でテストを自動実行する方法も紹介します。 本記事の対象読者 Playwrightの基本的な使い方を理解し、次のステップに進みたい方 Playwrightをチーム開発やCI環境に組み込みたいと考えている方 本記事のゴール トレー
Renovate の大量の Pull Request を処理する技術 - スタディサプリ Product Team Blog
こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Monorepo に対する Renovate の大量の Pull Request を処理するための技術について紹介します。 背景 過去ブログで何度か紹介しているように、弊プロダクトでは Terraform の Monorepo を管理しています。 先日、 CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました。 blog.studysapuri.jp working directory (state) の数は 400 近くあり、 working directory ごとに以下のような tool のバージョンを管理しています。 Terraform Terraform Provider tflint tflint plugin tfsec etc これ
こんにちは！「家族アルバム みてね」（以下、みてね）SREグループのおじまです。 今回は、みてねの開発プロセスを支えるデプロイパイプライン、特にブランチ戦略を改善し、ステージング環境における占有問題などの課題を解決したお話をご紹介します。 みてねの開発フローとこれまでの課題みてねでは、ブランチ戦略としてGitHub Flowを採用しています。GitHub Flow では、はじめにメインブランチからフィーチャーブランチを作成します。フィーチャーブランチで機能開発を行った後、プルリクエストを作成します。フィーチャーブランチは、プルリクエストにおけるコードレビューを経て、メインブランチにマージされます。メインブランチは常にデプロイ可能な状態に保たれます。GitHub Flowは、シンプルで分かりやすいのが特徴です。 しかし、GitHub Flow自体には、本番環境以外へのデプロイ方法について明確
Devinにお願いしてソースコードからドキュメントを生成してもらえると面白そうなので実験してみた。Devin Wiki や Deep Wiki もあるんだけど、それとは別に自分で指示を出してコントロールできるのもいいかなという気持ち。 どうせ作るなら自分がドキュメントを読みたいやつがいいなぁと思って、ecspresso が好きだから、ecspressoのソースコードからドキュメントを生成してみることにした。 軽い気持ちでやってみたら、思ってたより苦戦した。すごくいい感じにできたわけじゃないので「この記事をめちゃ信じる！」んじゃなくて「へー、ちょっと参考にしとこっか」くらいが良いと思う。 勢いで書かないと書き終わらなさそうだったので、勢いでざーっと書いた。ので長い。 できあがったもの できあがったものを最初に書いておく。わりと気に入ってる。ただ、生成するたびに色々変わるので、雰囲気で参照する
footer: YAPC::Fukuoka 2025 - azu slidenumbers: true autoscale: true theme: Plain Jane, 1 [fit] 読む技術・書く技術・伝える技術 15年続けて分かった持続可能なオープンソース開発 azu (@azu_re) YAPC::Fukuoka 2025 自己紹介 azu GitHub: @azu X/Twitter: @azu_re 2010年から15年間オープンソース開発 今日話したいこと 15年間オープンソース活動のうち 2011年-: JSer.info: JavaScriptの毎週更新の情報ブログ 2014年-: textlint: 自然言語のLinter 2016年-: JavaScript Primer: JavaScript入門書 3つのプロジェクトのタイムライン 問い: なぜ15年も続けてい
はじめに GitHub Script概要 セットアップ context の中身 eSquare Liveでの活用事例 発生した問題 タグの打ち間違い releaseブランチが複数存在する場合のデプロイ先選択の複雑化 解決策としてのGitHub Scriptの活用 機能1 vX.Y.Zのタグがmainブランチのコミットハッシュと一致することを確認する 機能2 releaseブランチは最新バージョンのみ自動で検証環境にデプロイする 完成版スクリプト まとめ はじめに こんにちは、enechainでeSquare Liveを開発しているエンジニアの古瀬(@tsuperis3112)です！ 今回は、マニュアル依存になりがちなデプロイフローの問題を actions/github-script で解消した方法についてお話します。 eSquare Liveの開発では、効率的かつ信頼性の高い開発フローを維
週に一度まとめて更新のようなパターンだと、体調が悪いときなどにその週はスキップされ、また次の週も更新しようとして偶然タイミングが合わなかった場合などに、1ヶ月更新が止まるみたいな状態は起きやすいです。 1ヶ月更新を止めてしまうと、そこで更新する習慣が失われて、この書籍でいう逆戻りが起きるのかなと思っています。 そのため、JSer.infoではタスクを細分化して進められる時にやっていけるような形を作っています。 ライブラリのメンテナンスのリズムをツール化する JavaScript周りは顕著ですが、ライブラリが細かく分かれていることが多いため、リポジトリの数も多いです。 そのため、リポジトリのCI設定や依存ライブラリのアップデートなどをメンテナンスするだけで無限の時間がかかります。 このメンテナンス作業を手動で毎回やるととても疲れるので、自分の場合はツール化していることが多いです。 作ったり、
こんにちは。ブランドソリューション開発本部フロントエンド部の御立田です。フロントエンド部の部長とWEAR Androidのブロック長を兼任しており、普段は部署全体の管理・リスクマネジメントや、Android開発における設計などを行っております。 本記事では、運用改善によるチームパフォーマンス向上のための取り組みについてご紹介します。なお、フロントエンド部WEAR Androidブロックで実施した内容となっており、一部アプリ開発向けの施策ですのであらかじめご了承ください。 目次 目次 はじめに 生産性に対する課題感 改善結果 サイクルタイム平均値 スタッツ 数値分析 問題点の推測 問題点の認識 対応策 レビュー環境への対応策 レビュー会の開催 PR単位でビルドの共有 巨大なPRへの対応策 サブタスクで粒度を下げる 常にアップデートすることへの対応策 開発者リソースの再配分 PRテンプレートを
YAML完全活用マニュアル──AIエージェント開発とプロンプト工学の次世代標準｜hirokaji
はじめに：いま、YAMLを再評価する理由2025年、生成AIとプロンプトエンジニアリングの発展は新たな開発様式をもたらしました。 ChatGPT、Claude、Geminiといったモデルの急速な進化により、LLM（大規模言語モデル）との対話は単なる質問応答を超え、構造化された命令、複雑な推論、そしてマルチエージェント間の協調へと展開しています。 こうした「AIが行動する時代」において、従来のコードやスクリプトだけではカバーしきれない、構成・設定・意味づけのインターフェースとして脚光を浴びているのが YAML です。 YAMLはもともと構成ファイルとして使われてきた言語ですが、 自然な階層構造 可読性の高さ コメントによる意図の明示 データとしての再利用性 JSON互換性 といった特徴により、人間とAI、開発者とエージェントの共通言語としての地位を獲得しつつあります。 特に近年はX（旧Twi
はじめに こんにちは、計測プラットフォーム開発本部SREブロックの近藤です。普段はZOZOMATやZOZOGLASS、ZOZOFITなどの計測技術に関わるシステムの開発、運用に携わっています。 計測プラットフォーム開発本部では、複数のプロダクトを開発運用していますが、リリース作業はプロダクト単位で行っています。プロダクトによってローンチから数年経過し安定傾向のものもあれば、ローンチしたばかりで機能開発が盛んなものもある状態です。 複数のプロダクトを管理する上では当然の状況ですが、プロダクト単位でリリース作業手順が異なり、手順そのものにも課題がある状態でした。 本記事では、リリース作業で課題となっていた部分の紹介と、それぞれの課題に対する対応策についてご紹介します。 目次 はじめに 目次 現状 課題と対応方針 リリース作業の自動化 リリース作業の自動化をする上での必須条件の確認 自動化が必要
GitHub のセキュリティ改善
先日 tj-actions/changed-files などの人気の GitHub Actions のセキュリティインシデントがありました (CVE-2025-30066)。 自分は OSS の開発者として様々な OSS を公開しており、こういったセキュリティインシデントは他人事ではありません。 そこでこの 1 ヶ月弱セキュリティ周りを見直し、かなり改善することが出来ました。 本記事では GitHub のセキュリティを改善する方法について紹介します。 主なターゲットしては自分のような OSS の開発者ですが、 GitHub を使っている方全てに参考になる内容かなと思います。 皆さんが本記事を参考にセキュリティを改善し、セキュリティインシデントを未然に防ぐことが出来れば幸いです。 先日登壇した GitHub Actions 関連の資料 先日 2025-03-11 に GitHub Actio
GitHubは2026年4月1日（米国時間）、オープンソースソフトウェア（OSS）のサプライチェーンを狙った攻撃が増加している件を受け（参考記事）、攻撃の最新動向と開発者に推奨する防御策、GitHubが進めているセキュリティ対策などをブログ記事で紹介した。 GitHubは、攻撃者がAPIキーなどのシークレット（認証情報や秘密鍵）を窃取し、攻撃者が制御するマシンから悪意のあるパッケージを公開するとともに、窃取した認証情報を使って他のプロジェクトにもアクセスし、攻撃を拡散させていることをあらためて報告した。こうした攻撃の多くはCI/CD（継続的インテグレーション／継続的デリバリー）ツール「GitHub Actions」のワークフローを侵害することから始まるという。 GitHubが「今日できる」としている4つの防御策 GitHubは、開発者自身がワークフローの穴をふさぐために即座に実施できる防御
持続可能なシステムを目指してプロダクトをリアーキテクトしました〜 実践編 〜 - DMM Developers Blog
はじめに アーキテクチャ設計の具体変化とコード構成の詳細 アーキテクチャ設計の変化 課題1: 各層の相互依存関係により、仕様変更の修正影響範囲が多い 課題2: service 層に複数の責務が集中し、メンテナンス性が低下していた 課題3: service層のdaoへの依存が大きかった コード構成の詳細 「イベントストーミング」から「実装」への変換プロセス 1.ドメインモデル から実装への変換プロセス 2.イベントから実装への変換プロセス 3. コマンド から実装への変換プロセス 4. 実装とイベントストーミングとの違いの見直しと仕様変更による修正 テストしやすい制約のポイント テスト戦略の変化 ユニットテストと統合テストの責任分離 「壊れやすい構造」から 「テストしやすい構造」 へどう変わったか 設計を「知識」として蓄積する 各層の責任の明確化とそれによるレビュー・開発体験の変化 数値で示
GitHub Copilot：新しいコーディングエージェント
GitHub Copilot に新機能が追加されました。タスクやIssueの内容をもとに実装できるコーディングエージェントで、GitHub Actionsを使ってバックグラウンドで実行し、その作業をプルリクエストとして提出します。 GitHub Copilot に、新しいコーディングエージェントが加わりました。GitHub に直接組み込まれており、GitHub IssueをCopilot に割り当てるとエージェントの作業が始まります。エージェントはGitHub Actions上に安全でカスタマイズ可能な開発環境を自動構築し、作業内容をドラフトプルリクエストへコミットとして随時プッシュします。進捗はエージェントセッションログで随時確認できます。 ブランチ保護など既存のセキュリティポリシーはそのまま適用され、CI/CDの実行前には必ず人間がプルリクエストを承認する仕組みになっているため、ビルド
マイクロソフト公式OSS「ghqr」でGitHub設定をベストプラクティス診断してみた | DevelopersIO
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/microsoft/ghqr/main/scripts/install.ps1')) $ ghqr -v ghqr version v.0.2.1 $ ghqr list-recommendations ID SCOPE CATEGORY SEVERITY TITLE ───────────
こんにちは！バクラク事業部 Platform Engineering 部 SRE チームの id:sadayoshi_tadaです。趣味で筋トレをやっていてこれまでほぼ1人でやっていたのですが、最近社内の人達とトレーニングすることが増えて楽しい今日このごろです。 この記事ではSREチームで行っている、DBマイグレーションにおけるガードレールの取り組みについて紹介します。 DBマイグレーションにまつわる課題について SREチームによるDBマイグレーション時のレビュー ALTER TABLE実行時にALGORITHMを明示するCIを追加 今後の課題 まとめ 最後に DBマイグレーションにまつわる課題について 本題に入る前に、バクラクのデータベースのスキーママイグレーション(以降、DBマイグレーションと呼称します)で起こっていた課題について簡単に触れます。 バクラクではリリースにおいてアプリケー
GitHub Actionsで「OpenAPI の自動バージョニング」から「API Clientのnpmパッケージ生成」までを完全自動化 〜bypass機能を利用してみました〜 - BASEプロダクトチームブログ
Platformグループでマネージャーをしている松田（ @tadamatu ） です。 この記事に書いてあること GitHub Actions を利用し 「OpenAPI の自動バージョニング」から「API Clientのnpmパッケージ生成」までを完全自動化 したのですが、その際に ハマったこと、工夫したこと が結構あったので、シェアしておきたいと思い書かせていただいた記事になります。 具体的には以下のような内容について書いてあります。 Branch protection rulesを維持した状態で、workflowからだけはcommitをさせたい（bypass機能を利用） → 文中の(3-2) 別ブランチの GitHub packages に npm publish したい（通常は何もしなければGitHub Actionsからは同じリポジトリのGitHub packagesにしか np
GitHub - modelcontextprotocol/servers: Model Context Protocol Servers
Official integrations are maintained by companies building production ready MCP servers for their platforms. 21st.dev Magic - Create crafted UI components inspired by the best 21st.dev design engineers. 2slides - An MCP server that provides tools to convert content into slides/PPT/presentation or generate slides/PPT/presentation with user intention. ActionKit by Paragon - Connect to 130+ SaaS inte
さよなら Flaky Test！Devinと共に実現する、CI安定化への道 - Timee Product Team Blog
タイミーでは、Flaky Test がデプロイの妨げになることで開発効率が悪化していました この問題を解決するため、AI エージェント「Devin」を活用し、Flaky Test の検出から修正プルリクエストの作成までを完全に自動化しました 結果、CIは安定し、開発者は本来の業務に集中できるようになったことで、開発体験が向上しました こんにちは！タイミーでバックエンドエンジニアとして働いている 福井 (bary822) です。 皆さんは Flaky Test に悩まされた経験はないでしょうか? タイミーでも、Flaky Test によって CI の信頼性が低下し、開発者の貴重な時間を奪ってしまうという課題を抱えていました。 ある期間においては master ブランチにおけるテスト実行の 4.5% が Flaky Test によって失敗しており、20+回/日 の頻度でデプロイされていることを
Ultimate Guide to Visual Testing with Playwright February 28, 2024 As your web app matures, it becomes challenging to ensure your GUI doesn’t break with any given update. There are a lot of browsers and devices, and countless states for every one of your components. Unit tests ensure your code remains consistent, and E2E tests will ensure your system remains consistent, but neither will catch visu
はじめに こんにちは。ML・データ部/推薦基盤ブロックの佐藤（@rayuron）です。私たちは、ZOZOTOWNのパーソナライズを実現する機械学習を用いた推薦システムを開発・運用しています。また、推薦システムの実績を定常的に確認するためのシステムも開発しています。本記事では、Lookerを用いて推薦システムの実績をモニタリングするシステムの改善に取り組んだ件についてご紹介します。 はじめに 改善の背景と課題 背景 課題 課題解決のために 要件1. 指標異常時の自動アラート 要件2. サマリの定期配信 要件3. 上記2つをSlack通知できること ダッシュボードの候補の比較 要件を満たすための設計 要件の実現方法 開発環境と本番環境 実装 ディレクトリ構成 ダッシュボード ダッシュボード構築の流れ 配信実績に関して 推薦結果に関して GitHub Actions 1. 指標異常時の自動アラー
Intro showModalDialog() は今から考えれば、確かにひどい API だった。 しかし、何か Modal を開き、ユーザにインタラクションをさせ、閉じたらそこで入力された値や選択された結果を取得し、処理を進めたいユースケース自体は、規約への同意取得や、Cookie バナー、ログインなど多々ある。 そういった場面では、ライブラリなどを用いて実装する必要があったが、Modal を実装するのは実際にはそんなに簡単ではなかった。 Modal, Dialog, Modal Dialog 最初に、用語を少し整理しておこう。 Modal Dialog Modal Dialog non-Modal Dialog Dialog とは、そもそも「対話」という意味であり、UI の文脈では入力や選択を求める「対話的な UI」のことを指す。 既に実装されている alert(), confirm()
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は クラウドワークスグループ Advent Calendar 2025 シリーズ1 の 18日目の記事です。 あるときはTerraform職人、またあるときはお豆腐職人の @minamijoyo です。 2023年8月HashiCorpはこれまでMPL2のOSSライセンスで公開していた主要製品をBSL(Business Source License)に変更することを発表し、Terraformはv1.6.0からOSSではなくなりました。このライセンス変更を受けて、OSS版のTerraformを求める人たちで、MPL2時点
はじめに 2023年にZennチームにJoinしたdyoshikawaです。 このたびZennのE2Eテスト基盤をリプレイスしました。このような下回りの改善はユーザへの価値提供との距離が近い機能開発と比べてどうしても後回しになりがちな中、Publication Proという大きなリリースを迎えて少し開発が落ち着いたタイミングであり、E2Eテストを拡充できる土台を整えることで今後より安心して機能を追加していけるようにするために必要だということで実施しました。 各テストを独立実行可能にすることによる開発体験向上、CI（GitHub Actions）の実行時間短縮、そして将来を見据えてのCypressからPlaywrightへの移行を行いました。 本記事ではリプレイス前に抱えていた課題、それに対して打ち出した解決方針、そして具体的にどんなことをやったのかを紹介します。 抱えていた課題 前提として
Terraformとdriftctlで行うGoogle Cloud 権限管理の省力化 - ZOZO TECH BLOG
はじめに こんにちは、ML・データ部MLOpsブロックの岡本です。 MLOpsブロックでは日々複数のGoogle Cloudプロジェクトを管理しています。これらのプロジェクトでは、データサイエンティストやプロジェクトマネージャーなど別チームのメンバーが作業することもあり、必要に応じてメンバーのGoogleアカウントへ権限を付与しています。 権限の付与はプロジェクトの管理者であるMLOpsブロックメンバーが行いますが、これは頻繁に発生する作業でありトイルとなっていました。 また権限付与後はこれらを継続的に管理し、定期的に棚卸しすることで不要になった権限を削除する必要があります。しかし当初の運用だと権限の棚卸しの対応コストが大きく、これが実施されずに不要な権限が残り続けるという課題もありました。 本記事ではMLOpsブロックで抱えていたGoogle Cloudプロジェクト内での権限管理における
Terraformのレビューを自動化するために、Conftestを導入してGithub ActionsでCIまで設定してみる - nariのエンジニアリング備忘録
はじめに 対象読者 OPA/Rego/Conftestとは Regoでポリシールールを記述して、ルール自体のテストも記述しながらCIへ組み込んでいくまで Conftest(OPA/Rego)のセットアップ 前提知識: Terraform plan 結果の構造 ConftestでTerrafom resource tag ルールを書いてみる ConftestでRegoで書いたルール自体のテストを書いて、実行してみる Conftestを実行するCIをGithub Actionで整備する Conftest/Regoで書いたポリシールール自体のfmt/verifyのCIの設定 Conftest testでTerraform plan結果をテストするCIの設定 終わりに 参考文献 English Version: dev.to はじめに メリークリスマス。eureka, inc. でSREをやってい
TerraformとGitHub Actionsで複数のCloud RunをまとめてDevOpsした結果, 開発者体験がいい感じになった話. - Lean Baseball
ざっくり言うと「TerraformとGitHub ActionsでGoogle Cloudなマイクロサービスを丸っとDeployする」という話です. Infrastructure as Code（IaC）は個人開発（趣味開発）でもやっておけ 開発〜テスト〜デプロイまで一貫性を持たせるCI/CDを設計しよう 個人開発（もしくは小規模システム）でどこまでIaCとCI/CDを作り込むかはあなた次第 なお, それなりに長いブログです&専門用語やクラウドサービスの解説は必要最小限なのでそこはご了承ください. あらすじ 突然ですが, 皆さんはどのリポジトリパターンが好きですか? 「ポリレポ（Polyrepo）」パターン - マイクロサービスを構成するアプリケーションやインフラ資材を意味がある単位*1で分割してリポジトリ化する. 「モノレポ（Monorepo）」パターン - アプリケーションもインフラも
先日起きた tj-actions や reviewdog のセキュリティインシデントのレポートを読みました。 その内容を個人的な検証結果や感想を挟みつつかいつまんで書きたいと思います。 詳細は原文を読んでください。 なお、侵害された repository 及び tag は全て修正され、盗まれた Personal Access Token (PAT) も revoke されているはずです。 攻撃の流れ tj-actions/changed-files が侵害されるまでに複数の PAT の流出及びリポジトリの侵害が連鎖的に起こっています。 つまり tj-actions/changed-files が直接的にいきなり侵害されたというより、複数のリポジトリをいわば踏み台のようにして侵害したという感じでしょうか。 攻撃者は PAT が盗まれたりした GitHub Account とは別に複数の Gi
Railsアプリの自動テスト環境をCirlceCIからGitHub Actionsへ移行したときにやったこと - ZOZO TECH BLOG
はじめに こんにちは、WEARバックエンド部バックエンドブロックの塩足です。普段は弊社サービスであるWEARのバックエンド開発・保守を担当しています。 WEARのバックエンドでは、これまで自動テスト環境としてCircleCIを使用していましたが、運用保守の改善を目的にGitHub Actionsへ移行しました。 今回は、GitHub Actionsへ移行する際に取り組んだ以下の3点について紹介します。 効率的にテストを分割してテストを並列実行する方法 失敗したテストのみを再実行する仕組みの構築 GitHubのCheck annotationsを活用して、失敗したテスト情報を表示 また、最後に今回行ったテストカバレッジのレポーティングとGitHub Pagesでのホスティングの方法について紹介します。 目次 はじめに 目次 背景 なぜ自動テスト環境をCircleCIからGitHub Acti
STORES 予約 でwebアプリケーションエンジニアをやっております。ykpythemindです。 Rails開発で、どのようなアプリケーションでも抑えておくとチーム開発が少し楽になるポイントがあります。今回はいくつか実例を載せながら紹介します。 アプリケーションの設計的な部分や実装には踏み込まず、すぐに導入できます。 あくまでRailsアプリケーションについての記事ですが、他言語やフレームワークを用いていても同様のことができます。 1. シードデータが壊れないようにCIで担保する 新しいメンバーが入って環境構築をしてもらう度にシードデータが壊れており、 db/seeds.rb *1 を直すという作業を何回か経験しています。db/seeds.rbで実行する内容をテスト中に実行しておくとメンテされるようになります。 # db/seeds.rb # 定数データが必要であればここで呼ぶ req
GitHub MCP Exploited: Accessing private repositories via MCP
We showcase a critical vulnerability with the official GitHub MCP server, allowing attackers to access private repository data. The vulnerability is among the first discovered by Invariant's security analyzer for detecting toxic agent flows. Invariant has discovered a critical vulnerability affecting the widely-used GitHub MCP integration (14k stars on GitHub). The vulnerability allows an attacker
PacketProxyで探るGemini CLIのコンテキストエンジニアリング 〜AIエージェントを信頼できる相棒に〜 | BLOG - DeNA Engineering
2025.07.18 技術記事 PacketProxyで探るGemini CLIのコンテキストエンジニアリング 〜AIエージェントを信頼できる相棒に〜 by akira.kuroiwa #gemini-cli #ai #security #ai-agent #context-engineering #packetproxy 「なんかよく分からないけど、すごい」で終わらせないために こんにちは、DeNA セキュリティ技術グループの 黒岩 亮 ( @kakira9618 ) です。 AIエージェント、とくに Gemini CLI のようなコーディングを支援してくれるツールは非常に強力で、私たちの開発体験を大きく変えようとしています。しかし、その一方で、こんな風に感じたことはありませんか？ 「このファイルの情報、勝手にAIに送られたりしない？ 大丈夫かな？」 と、情報管理・セキュリティ面で漠然と
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
私のJavaScriptの情報収集法 2024年版
Retty の Terraform CI/CD 解体新書 - Retty Tech Blog
Claude Code Actionのプロンプト設計が、AIエージェント開発にかなり参考になる件
Claude Code: Best Practices and Pro Tips
業務効率化の難しさや悩みを解決した「AI活用108選」をまとめました｜SmartBank
PlaywrightではじめるE2Eテスト入門（後編） - ICS MEDIA
ブランチ戦略（GitHub Flow）を見直してステージング環境の運用を改善しました
Devinにドキュメントを生成してもらう実験 - Mitsuyuki.Shiiba
読む技術・書く技術・伝える技術 - 15年続けて分かった持続可能なオープンソース開発
CI/CD革新 GitHub Script活用術 - enechain Tech Blog
Maintainer Month: オープンソースをメンテナンスするコツ
運用改善によるチームパフォーマンス向上のための取り組み - ZOZO TECH BLOG
GitHub Flow with GitOpsの導入 - ZOZO TECH BLOG
「もう開発者はシークレットを使うな」 GitHubが「今日できる」4つのセキュリティ対策を紹介
DBマイグレーションの安全性を高めるガードレールの実践 - LayerX エンジニアブログ
Ultimate Guide to Visual Testing with Playwright
推薦システムの実績をLookerでモニタリングする - ZOZO TECH BLOG
Dialog と Popover #2 | blog.jxck.io
Terraform職人のためのOpenTofu再入門2025 - Qiita
ZennのE2Eテスト基盤をリプレイスしました（開発体験向上、CI時間の短縮、Playwright移行）
tj-actions のインシデントレポートを読んだ
Rails開発でやっておくと良かったCI設定集 - STORES Product Blog