Visual Studio Extension Teams Should Stop Releasing by Habit and Start Releasing by Pipeline

Emiliano Montesdeoca — Thu, 23 Jul 2026 00:00:00 +0000

オリジナルソース: Automating your Visual Studio extension builds with GitHub Actions

Visual Studio 拡張をメンテナンスしていて、リリースの重要な部分を依然として手動で実行しているなら、これがモダナイズのシグナルである。

この記事で示されているワークフローは意図的に実用的である: バージョンスタンプ、ビルド、テスト用アーティファクトをギャラリーに公開、安定版ビットを Marketplace に公開。重いプラットフォーム儀式はなく、決定論的なリリース動作のみである。

私が最も気に入っているのは、バージョニングがリリース前のチェックリスト項目ではなく、パイプライン状態として扱われることである。そのひとつの判断で、驚くほど多くのミスが排除される: 不一致のメタデータ、古いアセンブリバージョン、一貫性のないリリースノート。

ギャラリー公開と Marketplace 公開の分割も運用上成熟している。チームには、公式リリースのセマンティクスを持たない迅速な検証ビルドのための場所が必要である。すべてを直接 Marketplace にプッシュすることは摩擦が大きく、リスクのある近道を助長する。

拡張チームのための強力なリリースパターン

プルリクエストと main コミット時には、CI VSIX アーティファクトを生成し、テスター向けにギャラリーに公開する。
タグ付きリリース時には、署名され検証されたパッケージを Marketplace に公開する。
トークン処理は最小限に、専用シークレットと最小特権スコープを使用する。

私の意見を明確に述べる:拡張エコシステムは、アプリエコシステムに比べて CI 規律で遅れている。なぜなら、小規模チームは手動ワークフローが管理可能だと想定するからだ。それらは管理可能だが、そうでなくなる瞬間が来る。ひとつの慌てたパッチ、ひとつの壊れたパッケージ、ひとつの忘れられたマニフェスト更新で、信頼は低下する。

これらの再利用可能アクションが有用なのは、繰り返されるリリースロジックを一度エンコードし、チームがパッケージングの仕組みではなく拡張品質に集中できるようにするからである。

それでもエンジニアリング判断は必要である。Marketplace 公開は品質チェックの後ろにゲートし、公開マニフェストは監査済みリリースアーティファクトとして扱うべきである。しかし、ベースラインパイプラインの複雑さは、手動のみのリリースがほとんど技術負債となるほど低くなった。

拡張開発をリードしているなら、これを今すぐ全リポジトリで標準化せよ。より良いトレーサビリティ、より簡単なオンボーディング、そしてより少ない一人リリースボトルネックを得られる。

推奨ロールアウト

ひとつの拡張でビルドとギャラリー公開から始める。
マニフェスト-ソースの規約を検証した後、バージョンスタンピングを導入する。
シークレット管理とリリースゲートが整ってから Marketplace 公開を追加する。

これは DevOps ファッションを追うことではない。ツールをインストールし、更新が正常に機能することを期待する人々のための信頼性に関するものである。

安定した拡張エコシステムは、安定したアプリケーションと同じ方法で構築される: 人間の推測を取り除く、退屈で反復可能な自動化である。

Vsix | The .NET Blog

Visual Studio Extension Teams Should Stop Releasing by Habit and Start Releasing by Pipeline

拡張チームのための強力なリリースパターン

推奨ロールアウト