#Continuous Integration DevOps capabilitiesの1つ、Fast Feedbackに分類される CIを実現するには次の要素が必要としている 自動化されたビルドプロセス 自動化されたテストスイート チェックイン毎の自動ビルドとテスト また次の2つも効果に繋がる Trunk-based development Working in small batches メンテナンス容易な自動化テストのためにはTDDを実践すると良い DORA | Capabilities: Continuous integration

#Continuous Integration トランクベース開発。DevOps capabilitiesの1つで、Fast Flowに分類される Working in small batchesをベースに少なくとも1日に一回はトランクブランチにマージをする テストの自動化も重要な要素となる DORA | Capabilities: Trunk-based Development

#Continuous Integration DevOps capabilitiesの1つ、Fast Flowに分類される 価値提供フローの可視化、チームによる実験、顧客フィードバックの可視化と組み合わせることで高いソフトウェアデリバリパフォーマンスに寄与する バッチサイズの最小化にはINVESTの原則を用いると良い DORA | Capabilities: Working in small batches

#Continuous Integration Dockerfileの構文チェック、ベストプラクティス検証、セキュリティ脆弱性検出を行うSASTツール Haskellで実装され、ShellCheckを統合することでRUN命令内のbashスクリプトも検証する 主な機能: Dockerfileの構文エラー検出 ベストプラクティス違反の警告（例: Non-root User、マルチステージビルド） セキュリティ脆弱性の検出 CIパイプラインへの統合が容易 Dockerイメージとしても配布されており、ローカル環境へのインストール不要で実行可能 hadolint.yamlで出力形式やルールをカスタマイズ可能 https://hadolint.dev/ https://github.com/hadolint/hadolint

#Security #Continuous Integration #Continuous Delivery DevOpsにセキュリティを統合したアプローチ ソフトウェア開発ライフサイクル（SDLC）の全段階にセキュリティを組み込む 主要な原則 シフトレフトセキュリティ 開発初期段階からセキュリティを考慮 自動化 CI/CDパイプラインへのセキュリティテストの統合 SAST / DAST の併用 コラボレーション 開発・セキュリティ・運用チームの協働 https://www.devsecops.org/

#Security #Continuous Integration GitHub Actionsワークフローの静的解析を行うSASTツール。サプライチェーン攻撃や認証情報窃取につながる workflow 設定の不備を検出する Rust製。.github/workflows/ 配下の YAML を解析し、命名された audit ID 単位で検出 / ignore を行える 主な audit カテゴリ: dangerous-triggers template-injection unpinned-uses excessive-permissions overprovisioned-secrets https://zizmor.sh/ https://github.com/zizmorcore/zizmor

#Continuous Integration 依存とロックファイルの更新 Pull Request を自動生成するツール。公式は "Automated dependency updates. Multi-platform and multi-language." を標榜し、90+ のパッケージマネージャに対応する Mend.io が維持する OSS（AGPL-3.0-only）で、GitHub / GitLab / Bitbucket / Azure DevOps / Gitea / Forgejo / AWS CodeCommit / Gerrit など 9 つの Git プラットフォームで動く 特徴 リポジトリ内の依存定義を自動検出し、設定スケジュールに沿って更新 PR を作成（monorepo も検出） 設定は renovate.json / .renovaterc などを配置（最初に見つかった 1 つで停止）。preset で設定を共有・再利用できる Dependency Dashboard — 全更新の状態を 1 つの Issue に集約して可視化 grouping で複数更新を 1 PR にまとめ、automerge で条件を満たした PR を自動マージ 非推奨依存の置き換え（replacement）を提案 npm パッケージ / Docker イメージとしてセルフホストするほか、Mend Renovate App（ホスト型）も使える https://docs.renovatebot.com/ https://github.com/renovatebot/renovate

2009年に10+ Deploys Per Day: Dev and Ops Cooperation at Flickrにて初めて登場した言葉 開発とオペレーションを一つのチーム内で両立させる 広義な用語ではあるが、共通して以下のような手法が定義されることが多い #Continuous Integration #Continuous Delivery Infrastructure as Code マイクロサービス

#Cloud Native #Continuous Integration Google Cloudが提供するフルマネージドなコンテナイメージおよび言語パッケージのレジストリサービス Docker/OCIイメージに加え、Maven・npm・Python・Go・apt・yum・Helmなど複数の形式に対応する 旧サービスのContainer Registryの後継として位置付けられている Artifact Registry のドキュメント | Google Cloud

#Continuous Integration Martin Fowlerが示した、抽象化レイヤーを介して大規模な変更を段階的に行う手法 BranchByAbstraction

#Continuous Integration #Continuous Delivery HashiCorp が提供する Terraform のマネージド SaaS（旧称 Terraform Cloud、2024 に HCP 傘下へ改称）。リモート実行（run）・共有 state・VCS 連携の plan/apply・private module registry・Sentinel/OPA による policy as code を提供する。 CLI からは cloud {} ブロックで接続（旧 remote backend 相当）。料金は managed resource 数ベースで Free 枠あり。自社環境に置く self-hosted 版は Terraform Enterprise https://developer.hashicorp.com/terraform/cloud-docs

#Security #Continuous Integration Cilium を題材に CI/CD 依存の固定・審査戦略を解説した CNCF ブログ記事（全3回の第2回） GitHub Actions の SHA pin: タグではなく 40 字コミット SHA で参照し、tag 書き換えによるサプライチェーン攻撃を防ぐ Renovate 自動更新: pinGitHubActionDigests preset で SHA を自動管理、minimumReleaseAge 5 日クールダウンで公開直後の悪意バージョンを回避 Go ベンダリング: vendor/ をリポジトリに commit し CI で go.mod/go.sum を検証、proxy 改ざんをレビュー可視に actionlint で pin 漏れ・runner image タグ未固定を検出 CODEOWNERS で vendor/ 変更者を限定し依存変更の承認ゲートを構築 https://www.cncf.io/blog/2026/06/12/securing-ci-cd-for-an-open-source-project-locking-down-dependencies/

StranglerFigApplication #Continuous Integration Martin Fowlerによる理論。既存のシステムを置き換える際、既存のシステムの周辺に新規のシステムを追加していき段階的に置き換える。 イチジクの成長段階に似ていることからFigの命名を含んでいる。 原文はこちら

#Cloud Native #Security #Continuous Integration Red Hatが提供するコンテナイメージレジストリサービス コンテナイメージの保存・配布を行い、SAST脆弱性スキャナーClairによる自動セキュリティスキャンを統合している 3つの提供形態がある Quay.io - Red Hatが運用するホスト型サービス。パブリックリポジトリは無料 Red Hat Quay - オンプレミスまたはプライベートクラウドにデプロイ可能。Operatorとしても提供 Project Quay - Apache 2.0ライセンスのOSS版 Docker Hubの代替として、エンタープライズ向けのアクセス制御やイメージ署名機能を備える https://quay.io/ https://www.projectquay.io/

#Continuous Integration GitHub を IaC で宣言管理する公式 Terraform provider（integrations/github）。repo・team・branch protection・ruleset・Actions secrets/variables・org settings・webhook など 80+ リソースを HCL で扱う。Terraform / OpenTofu 両対応。 owner に user / org を指定（個人 owner も可）。認証は GitHub App 経由（app_auth で PEM からトークン生成、または外部発行した installation token を渡す）か PAT で、GHES は base_url で指定 https://registry.terraform.io/providers/integrations/github/latest/docs

#Data Engineering #Continuous Integration #Continuous Delivery #Documentation データベーススキーマの最新の状態をコードとして管理し、変更時の差分を元に自動でマイグレーションクエリを生成してくれるようなDevOpsツール PostgreSQLやMySQLといった代表的なデータベース管理システムに対応している Atlas CloudによってWeb上での可視化も可能 Ariga社によって開発されている https://atlasgo.io/docs

#Continuous Integration Rust 製 Git hook manager。pre-commit や pre-push などのフック契機で linter / formatter を実行する 並行実行を file lock で安全化し、staged 変更を守りつつ並列度を最大化する性能設計 主要 linter / formatter を組み込み、外部 tool 提供は mise と統合 設定は Pkl で型付き記述する https://github.com/jdx/hk https://hk.jdx.dev/

#Continuous Integration GitHub Actions の workflow 内で、PR / push で変更されたファイルの一覧を出力する community action tj-actions/changed-files。後続 step は出力を参照し、変更パスに応じて処理を分岐できる https://github.com/tj-actions/changed-files

#Continuous Integration GitHub の最上位プラン GitHub Enterprise を、GitHub がホスト（github.com 上の SaaS）する形態で提供するもの。略称 GHEC。もう一方の提供形態は self-hosted の GitHub Enterprise Server (GHES)。 複数 organization を束ねる「enterprise アカウント」を持ち、ポリシー・課金・ruleset を enterprise レベルで一元管理できる https://docs.github.com/en/get-started/learning-about-github/githubs-plans https://github.com/pricing

#Programming #Continuous Integration GitHub公式のコード品質機能。Code scanning を拡張し、Pull Request 上でコード品質の問題を検出して修正提案までを提供する。 2025 年に public preview として公開。GitHub Team / Enterprise Cloud の組織リポジトリのみ対応（Enterprise Server 非対応）で、別途 Copilot / Code Security ライセンスは不要 ルールベース解析（CodeQL エンジン）と AI 解析の 2 系統で、保守性・信頼性・パフォーマンス・複雑度・重複/デッドコード・テストカバレッジなどを検出する 指摘は PR 上にインライン表示され、GitHub Copilotによるワンクリック autofix と reliability/maintainability スコアを提示する スキャンはGitHub Actions上で実行され、Actions minutes を消費する 適応度関数のコード品質カテゴリに該当する https://docs.github.com/en/code-security/concepts/about-code-quality

#Continuous Integration Terraform GitHub provider の resource で、GitHub リポジトリ内の単一ファイルの内容を宣言管理する（repository / file（パス）/ content / branch を指定し commit として反映）。 .github/workflows/*.yml を対象にすれば GitHub Actions のワークフローを配布でき、for_each で複数リポジトリへ撒ける コピーして終わりではなく宣言内容へ収束し続ける点が要: 配布先での手動編集も drift として plan で検出され apply で是正される https://registry.terraform.io/providers/integrations/github/latest/docs/resources/repository_file

#Continuous Integration Terraform GitHub provider の resource で、repo 単位の ruleset を宣言する（name / target(branch|tag) / enforcement(active|evaluate|disabled) / conditions(ref_name) / rules / bypass_actors）。 rules に required_status_checks（require status checks）・pull_request（承認人数 required_approving_review_count 等）などを宣言。repo レベルなので個人 owner でも使える（public は無料） https://registry.terraform.io/providers/integrations/github/latest/docs/resources/repository_ruleset

#Continuous Integration Terraform GitHub provider の resource で、org 単位の ruleset を宣言する。conditions の repository_name(include/exclude) または repository_id で対象 repo 群を絞る。 rules に各種ルールを宣言でき、特に org/enterprise 専用の required_workflows（require workflows）を扱えるのが repo 単位版との違い https://registry.terraform.io/providers/integrations/github/latest/docs/resources/organization_ruleset

#Continuous Integration Terraform GitHub provider の resource で、GitHub App のインストールがアクセスできる repo を宣言管理する（installation_id ＋ repository）。App 登録自体は TF では作れないので、これは既存インストールの repo 付け外しを IaC 化するもの。 install の repo 操作は classic PAT（repo scope）専用で、App 認証（installation token）も fine-grained PAT も不可（403）。PAT を避けるなら installation は UI 管理にして TF 外へ https://registry.terraform.io/providers/integrations/github/latest/docs/resources/app_installation_repository

#Continuous Integration 指定した status check（CI チェック）の成功を PR マージの条件にする GitHub の ruleset ルール（正式名 "Require status checks to pass before merging"）。repository / organization どちらのレベルでも設定できる。 status check は GitHub Actions のジョブ・外部 CI（Commit Status API）・GitHub App から付与され、base 追従を必須化する up-to-date オプションを持つ https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets

Infrastructure as Code #Continuous Integration #Continuous Delivery インフラストラクチャとしてのプロセスや環境、設定等をコードで管理し文書化する方針 Infrastructure as Code とは - IaC の説明 - AWS

#Continuous Integration #Continuous Delivery HashiCorp 製の Infrastructure as Code ツール。API を宣言的な設定ファイルにコード化し、インフラの作成・変更・バージョン管理を安全かつ予測可能に行う provider がクラウド / SaaS の API を抽象化し、低レベル（compute / storage / network）から高レベル（DNS・SaaS 機能）まで同じ記法で扱う 設定は HCL で記述し、現状を state ファイルで追跡。write → plan → apply のワークフローで plan が適用前の差分を提示する 2023-08 にライセンスを MPL 2.0 → BUSL 1.1（source-available の非 OSS）へ変更 https://developer.hashicorp.com/terraform

#Security #Continuous Integration Gitleaks の開発元が手がける、シークレット（API キー・トークン・認証情報）を検出するスキャナー。GitHub/GitLab などの Git リポジトリ（Organization 単位も可）、S3、ローカルディレクトリなど複数のソースに対応する DevSecOps のシフトレフトとして CI に組み込み、コードや成果物へのシークレット混入を検出する https://github.com/betterleaks/betterleaks

#Security #Cloud Native #Continuous Integration GitHub Actions / GitLab CI/CD のジョブをeBPFでカーネルレベルに監視し、実行時のサプライチェーン攻撃を検出するオープンソースのランタイムセキュリティセンサー（"Think EDR, but for CI/CD Pipelines"） CI/CD が握る認証情報・署名鍵・トークンを狙う攻撃に対し、汚染された依存がジョブ内で「何を実行したか」のランタイム可視性と事後調査の手段を与える 検出の仕組み: プロセス系譜分析 - 例として npm install から派生したプロセスによる認証情報アクセス シグナル相関 - 例として 1 ジョブ内での複数カテゴリの認証情報アクセス 構成要素: Sensor - eBPF ベースのランタイムモニタ Action - GitHub Actions 統合。run ごとにレポートと build attestation を生成 Manager - ログを S3 / GCS / Pub/Sub 等のクラウドシンクへルーティング（データはユーザー管理下） 2026 年時点で pre-release・活発に開発中 https://github.com/cicd-sensor/cicd-sensor

#Continuous Integration GitHub の organization / enterprise レベル専用の ruleset ルールで、指定した GitHub Actions ワークフローの成功を PR マージの条件にする（正式名 "Require workflows to pass before merging"、旧 Required workflows）。各リポジトリにファイルを追加せず適用でき、GitHub Enterprise Cloud 等の GitHub Enterprise プランが必要。 repo 単位でチェック成功を必須化する別ルール require status checks とは別物 https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets

#Continuous Integration Renovate を自前インフラで運用する Mend 公式の商用セルフホスト版（Community Edition / Enterprise Edition）。GitHub では自分で GitHub App を登録し、その bot として依存更新 PR を回す GitHub Action が workflow から CLI を都度実行するのに対し、こちらは Docker コンテナで常駐するサーバーとして動くのが違い 特徴 組み込みジョブスケジューラ（デフォルト毎時）が全リポジトリをキューに投入し、cron の構築・監視が不要 webhook リスナー（/webhook）で App 追加・main への設定変更・Renovate PR の close/merge 等に即応し、優先度付きキューで処理する ホスト型のクラウド Mend Renovate App とは別で、GitHub Enterprise Server など自前環境向け https://github.com/mend/renovate-ce-ee

#Continuous Integration Renovate を GitHub Actions 上でセルフホストする公式 Action renovatebot/github-action。ホスト型 Mend Renovate App を使わず、自前リポジトリの workflow から依存更新 PR を回す前提のセットアップ 設定 workflow の on.schedule（cron）で定期実行する（例: 0/15 * * * *） 設定ファイルは configurationFile で指定（JS / JSON）。RENOVATE_ 接頭辞の環境変数はそのままコンテナへ渡る renovate-version で実行する Renovate（Docker イメージ）のバージョンを固定できる https://github.com/renovatebot/github-action

#Security #Continuous Integration GitHub Actions の action / reusable workflow の参照を full-length commit SHA に pin する CLI（@suzuki-shunsuke 製）。タグは可変で改ざんの余地があり、SHA 固定だけが不変なリリース参照になる、というサプライチェーン攻撃対策。 pinact run で参照を SHA に pin（# v3.5.1 のバージョンコメント付き）。--update で更新、整合の検証にも対応 --no-api で API なしの構文チェック、--min-age でリリース直後の参照を弾く https://github.com/suzuki-shunsuke/pinact

#Continuous Integration git commit 実行時に自動で呼ばれる Git クライアントサイド hook。.git/hooks/pre-commit に実行可能スクリプトを置くだけで有効になる コミット作成前に実行され、非ゼロで終了すると commit が中断される 引数は渡されず、ステージ済みの変更を検査する用途が一般的（lint・format・シークレットスキャン等） git commit --no-verify で bypass できる https://git-scm.com/docs/githooks#_pre_commit

#Security #Continuous Integration LayerX のコーポレートエンジニアリング室（アプリケーショングループ）による、ソフトウェアサプライチェーン攻撃対策の運用事例（2026-02 の発表）。使う技術を絞り、少人数でもスケールする状態を目指す。 依存を pin する: lockfile（pnpm-lock.yaml・go.sum）に加え、GitHub Actions の pinning を CI で強制。org ruleset の require workflows で org 全体に共有 workflow を適用し、その共有 workflow で pinact を実行して未 pin の action を検知。Docker イメージは sha256、CI/CD ツールは aqua で checksum 検証 cooldown: リリースから N 日以内のパッケージを入れない（pnpm・Renovate の minimumReleaseAge、Dependabot の cooldown.default-days）。security fix のみ人間確認後に minimumReleaseAgeExclude で除外 まとめ: 迅速な修正・pinning・cooldown に加え、検知・遮断・影響範囲の局所化も併せて進める https://speakerdeck.com/yuyatakeyama/supply-chain-security-at-layerx-corporate-engineering

個人やチームの認知容量に対する負荷のこと 認知負荷は3つに分類することができる 課題内在性認知負荷 問題領域のタスクの難易度に関する負荷、研修・技術選定・ペアプログラミング等で解消する 課題外在性認知負荷 タスクを実施する環境に関する負荷、#Continuous Integrationによる自動化等で解消する 学習関連負荷 知識の構築に関する負荷、学習によって増やすべき負荷とされる 情報過多にご用心！生産性の低下を招く「認知的過負荷」への対処法 ── 海の向こうからオピニオン その70 (1/2) - チームの教科書｜アトラシアン株式会社

#Continuous Integration Git hooks マネージャ。Go 製単一バイナリで lefthook.yml に hook 定義を書き、lefthook install で .git/hooks/ に展開する。Evil Martians がメンテナンス pre-commit / pre-push / commit-msg 等の hook 種別をサポートし、カスタムタスクグループも作れる ジョブを並列実行でき、glob / regex によるファイル絞り込み、tag でグループ単位の実行制御 ローカル上書き用に lefthook-local.yml を分離可能 https://lefthook.dev/ https://github.com/evilmartians/lefthook

#Agile #Team Organization #Continuous Integration #Continuous Delivery Swarmingをコンセプトに掲げたアジャイルチームのベストプラクティスについての、XP祭り2024での自身の発表 関連Scrapは以下 自己組織化 ストラングラーフィグアプリケーション トランクベース モノリスからマイクロサービスへ 関数型ドメインモデリング

#Continuous Integration リポジトリ設定を policy-as-code で組織横断に宣言・適用する GitHub App（Probot ベース）。admin リポジトリに設定を集中管理し、各 repo の実設定を GitHub API 経由で宣言状態へ収束させる、repo 設定版の Infrastructure as Code。Platform Engineering の guardrails 実装の一つ 設定は admin repo の 3 階層（.github/settings.yml=org / suborgs/*.yml / repos/*.yml）で各 repo にマージ適用、優先度は repo > suborg > org full sync（CRON）で drift を検出・修正、PR では nop モードで dry-run 差分を提示 管理対象は GitHub API で扱う設定のみ（branch protection / labels / collaborators / teams / topics / custom properties / environments / rulesets 等）。ファイル内容は扱えず .github/workflows/*.yml の配布はできない（GitHub Actions の強制は ruleset / require workflows 経由） Organization 専用で個人アカウントでは動かない https://github.com/github/safe-settings

#Continuous Integration GitHub Actions の workflow 内で GitHub App のインストールアクセストークンを発行する公式 Action actions/create-github-app-token。App の ID と private key を渡すと、対象を絞ったトークンを払い出す 特徴 発行されるインストールトークンは 1 時間で失効する短命トークン。post step で自動 revoke され、明示しない限り他 job へは渡らない owner / repositories でアクセス先リポジトリを限定し、権限を細かく絞れる デフォルトの GITHUB_TOKEN（権限が制限的で後続 CI をトリガできない）や PAT の代替として使い、GitHub App の bot 名義で commit / comment できる https://github.com/actions/create-github-app-token

#Continuous Integration GitHub Actions が各 workflow run の開始時に自動発行する組み込みトークン。secrets.GITHUB_TOKEN または github.token で参照でき、その run 内で GitHub API / Git 認証に使う 実体は github-actions[bot] という GitHub App のインストールアクセストークンで、job が終わると失効する短命トークン（最長 24 時間） 特徴 権限は workflow の permissions キーで制御し、最小権限の付与が推奨される 権限のスコープは workflow が置かれたリポジトリに限定される GITHUB_TOKEN で起こしたイベントは新たな workflow run をトリガしない（再帰実行の防止）。このため bot 起点で後続 CI を回すには GitHub App トークンや PAT が必要になる https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication

Buf Schema Registory #Continuous Integration #Continuous Delivery Bufが提供するProtocol Buffersツール群のうちの一つ Protobufファイル群をモジュールとしてバージョン管理することができる。 モジュールとしてのドキュメンテーションをサポートし依存関係管理も可能 Overview - Buf Docs

#Continuous Integration #Continuous Delivery

#Continuous Integration Bufが提供するProtocol Buffersツール群のうちのCLIツール protoc に代わる高速なコンパイルやスタブ生成が可能。その他CIに組み込むようなlinterや破壊的変更検出の機能を有している https://buf.build/docs/cli/

Static Application Security Testing #Security #Testing ソースコード、バイトコード、バイナリを解析してセキュリティ脆弱性を検出するテスト手法 ホワイトボックステストとも呼ばれ、アプリケーションを実行せずにコードを分析する 特徴 DevSecOpsのシフトレフトを実現 #Continuous Integrationパイプラインに統合可能 SQLインジェクション、XSS、バッファオーバーフロー等を検出 https://owasp.org/www-project-devsecops-guideline/latest/02a-Static-Application-Security-Testing

#Security #Cloud Native #Continuous Integration コンテナイメージ、Kubernetes、IaC、リポジトリを対象とした包括的な脆弱性・設定ミス・シークレットスキャナー Aqua Securityによって開発されたオープンソースツール 主な機能: 脆弱性スキャン - コンテナイメージ、ファイルシステム、gitリポジトリ IaC設定ミス検出 - Dockerfile、Kubernetesマニフェスト、Terraformなど シークレット検出 - APIキー、パスワード等の機密情報 SBOM生成 - ソフトウェア部品表の作成と検出 ライセンススキャン DevSecOpsのシフトレフトセキュリティを実現し、CI/#Continuous Deliveryパイプラインに統合可能 SASTツールの一種として静的解析を実行する。--format sarif で SARIF 出力に対応し GitHub Code Scanning に取り込める https://trivy.dev/ https://github.com/aquasecurity/trivy

#Security #Testing #Continuous Integration #Programming コード品質とセキュリティを継続的に検査するオープンソースの静的解析プラットフォーム 35以上のプログラミング言語に対応し、バグ、脆弱性、セキュリティホットスポット、コードスメルを検出する 主な機能 Quality Gates - デプロイ可否を判断するカスタマイズ可能な品質基準 SAST機能 - 静的コード解析によるセキュリティ脆弱性の検出 AI CodeFix - AIによるコード品質・セキュリティ問題の自動修正提案 IDE統合 - リアルタイムフィードバックと修正提案 DevSecOpsのシフトレフトセキュリティを実現し、適応度関数のコード品質カテゴリに該当する https://www.sonarsource.com/products/sonarqube/

#Continuous Integration Platform Engineering Go 言語で書かれた、多数の Git リポジトリへ一括で変更を加える CLI ツール。マイクロサービス のように小さなリポジトリが多数に分かれた構成で有用と公式は述べている init → clone → plan → push → merge の 5 段階のワークフローで、ターゲットリポジトリの選定からスクリプトベースの一括編集・差分プレビュー・PR 作成・マージまでを順に進める。バックエンドは GitHub と GitLab（self-hosted 含む） https://github.com/Clever/microplane

#Testing #Continuous Integration テスト実行において偽陽性として不安定に落ちるテストのこと