歴史的な記事です。 これは v1 のアナウンスで、Stitch がどこから始まったかを示すために保存しています。v1 は Python パッケージで、CI ジョブとして動き、PyPI で配布されていました。Stitch はその後ゼロから書き直されました。現行バージョンは Stitch 2.0 is here を、書き直しの振り返りは What we got wrong with Stitch v1 をご覧ください。
CI パイプラインは壊れます。どんなチームでも、毎週起きることです。不安定なテスト、欠けた依存関係、誰かが忘れた lint ルール。修正自体はたいてい単純ですが、コストはそうではありません。コンテキストスイッチ、再実行の待ち時間、本来の仕事への集中の喪失。
Stitch は、まさにそれを処理するために作られたオープンソースの AI エージェントです。CI パイプラインを監視し、失敗を検知し、根本原因を診断し、修正を push します。人の介入は不要です。
仕組み
既存の CI 設定に2つのジョブを追加します。1つ目は通常のパイプライン。2つ目が Stitch です。パイプラインが失敗すると、Stitch が失敗を拾い、ログを読み、何が起きたかを理解し、パッチを生成します。
当て推量はしません。実際のエラー出力を読み、ソースまで遡り、的を絞った修正を適用します。修正が通れば commit を push します。通らなければ、発見した内容を報告するので、あなたが完全なコンテキストを持って引き継げます。
何が違うのか
ほとんどの CI/CD ツールはオーケストレーションに焦点を当てています。これを実行し、次にあれを実行し、ここにデプロイする、といった具合です。Stitch はリカバリに焦点を当てます。パイプラインツールの代替ではありません。既存のパイプラインを自己修復型にするための追加物です。
主要な設計判断:
- 管理すべきサーバーなし。 Stitch はサービスではなく CI ジョブとして動きます。メンテナンスすべきインフラはありません。
- 2つのジョブ以外に設定なし。
.gitlab-ci.ymlや GitHub Actions ワークフローに入れるだけ。それで完了です。 - クライアントサイド JavaScript ゼロ。 ランディングページとドキュメントは完全に静的です。
- オープンソース、MIT ライセンス。 CI リカバリプロセスはあなたのものです。
対象ユーザー
パイプラインの子守りに疲れたチーム。同じ lint エラーを1週間で3回直したり、20分待った再実行で import 漏れが判明したりした経験があるなら、Stitch はあなたのワークフローのために作られています。
GitLab CI と GitHub Actions で動作します。他の CI プラットフォームのサポートはロードマップにあります。
これから
Stitch は活発に開発中です。中核の検知とパッチのループは安定しています。今後の作業には、大規模パイプライン向けのプロキシローテーション、より賢いマルチジョブのグルーピング、カスタムな修正戦略のためのプラグインシステムが含まれます。
今日試してみてください。2つのジョブ。それがセットアップです。