テーマ： continuous-integration

• 継続的インテグレーションのパイプラインを設計する

  CI パイプラインは速く、自己テストを行い、どの変更にも同じ処理を適用する必要がある。クリーンなチェックアウトからビルドし、リンターとテストを段階的に実行し、失敗を明確に知らせる。全体の時間は、人が結果を待てる長さに保つ。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• Keeping CI and local checks identical: one entry point, pinned tools, same container

  A check that passes locally should pass in CI and vice versa: define every check once as a named task, pin the toolchain in a committed manifest that both the bootstrap and the pipeline install from, run CI in the same container image as the dev environment, fix locale and timezone, and treat any CI-only failure as a parity bug to eliminate before fixing the symptom.

  methodology · en · reviewed · 知識の基準日 2026-09-17

• 統合テストでコンテナ内の使い捨てデータベースを使う

  テストの実行ごとに、使い捨てコンテナで実際のデータベースエンジンを起動し、データをメモリー上に置きます。テンプレートデータベースに一度だけマイグレーションを適用し、テストファイルごとに複製します。テストはインメモリーの代替物ではなく、本物のプランナー、制約、分離の振る舞いを検証できます。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• グラフ探索で依存順序を求める：BFS、DFS、トポロジカルソート

  依存関係を有向グラフとして表し、幅優先または深さ優先探索で変更の影響範囲を求めます。Kahn のアルゴリズムや DFS の帰りがけ順で、循環を隠さず報告するビルド・移行順序を作ります。graphlib と tsort がこのソートを実装しています。

  methodology · ja · reviewed · 知識の基準日 2026-09-16

• 生存ミュータントに埋もれずにミューテーションテストを運用する

  一つのモジュールでツールを実行し、生き残ったミュータントを、アサーション不足、ケース不足、等価な変異に分類します。前の二つを直し、三つ目は除外します。差分や増分実行で時間を抑え、スコアは全体目標ではなく、モジュールごとに前回を下回らない基準として使います。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• Automated game tests: combine headless checks with rendering evidence

  Design a practical game test suite with isolated logic tests, reproducible scene checks and controlled screenshot comparisons, including clear failure and baseline policies.

  article · en · unreviewed · 知識の基準日 2026-10-11

• Which pre-deployment checks have actually stopped a bad release in the last year, and which have never fired?

  Open question: pipelines accumulate gates (tests, scans, smoke checks, canary analysis, manual approvals, rollout deadlines), and the Kubernetes documentation notes that a stalled Deployment is only reported, not rolled back; which gates have a record of stopping a bad release, which never fired, and which fired only falsely?

  question · en · reviewed · 知識の基準日 2026-09-16

• Consumer-driven contract tests: verifying integrations without a shared environment

  A consumer-driven contract records the requests a consumer makes and the minimal response it relies on; the consumer tests against a mock built from that record, and the provider replays it against its real code. Both sides run in their own pipelines, and a version matrix answers whether a release is compatible with what is deployed.

  article · en · reviewed · 知識の基準日 2026-09-15

• ビルドの来歴証明：SLSA が記録する内容と検証方法

  SLSA の Build トラックは、成果物の来歴の信頼性を「来歴が存在する」（L1）から強化されたビルド基盤（L3）まで評価します。来歴は、成果物のダイジェスト、ビルダー、ビルドタイプとその外部パラメーターを示す in-toto アテステーションです。利用側は使用前に、信頼の起点と期待値に照らして検証します。

  article · ja · reviewed · 知識の基準日 2026-09-15

• ブランチごとのプレビュー環境：プルリクエストごとに1つデプロイし、マージ時に破棄する

  各プルリクエストに専用URLで動くアプリケーションのコピーを用意します。コミットごとに1回だけビルドし、プルリクエスト番号で命名し、ローカルの初期データを投入し、外部サービスのサンドボックスへ接続します。URLをプルリクエストに投稿し、同時実行数を制限し、マージ、クローズ、非活動時にコピーとデータを削除します。

  methodology · ja · reviewed · 知識の基準日 2026-09-17

• トランクベース開発と短命なブランチ

  少なくとも毎日、全員の作業を一つの共有された開発ラインに統合し、ブランチを短命に保ち、未完成の作業をフラグの背後に隠すことで、マージの衝突が減り、継続的インテグレーションが実態を持つ。

  article · ja · reviewed · 知識の基準日 2026-09-15

• Git hooks for fast local checks

  Client-side hooks such as pre-commit run formatters and quick linters before a commit exists; they save review time but must stay fast, must not be the only gate, and are not versioned by Git itself.

  article · en · reviewed · 知識の基準日 2026-09-15

• 不安定なテストを診断して解消する

  不安定なテストは、コードが変わらなくても成功したり失敗したりします。よくある原因は、共有状態、タイミングの仮定、実行順序への依存、実際の外部サービスです。隔離し、再現し、原因を直します。単に再実行するだけではいけません。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

機械可読： JSON