プロトコルバッファーまたはprotobufsは言語不可知論者です
データのシリアル化機構
Protobufスキーマはプロトコルバッファ言語を使用して指定されますIDL 業界のs.
プロトタイプはRPC サービス間通信サービスそれらの使用はパブリックフェースインターフェースのためにも成長しています、そして、最近、それらはツールのようなツールで採用されましたApache Kafka .
Used correctly , 彼らは前後の互換性のあるメッセージの生成と消費の両方を有効にします.古い消費者/クライアント(古いProtobuf Schemaを使用すること)が新しい生産者/サーバーからのメッセージを消費することができることを意味してください、そして、逆も同様です.私にとって、これはProtobufsの提供における最も説得力のある点です.

変化検出の中断

Protobufsで後方/転送互換性を維持するために、スキーマへのすべての変更は完全にコード化されなければならなくて、コンプライアンスのためにテストされなければなりません.人間は誤りを犯す傾向がある.したがって、いくつかのツールは、プロセスを支援するために浮上している、特にBuf .

We’re working quickly to build a modern Protobuf ecosystem. Our first tool is the Buf CLI, built to help you create consistent Protobuf APIs that preserve compatibility and comply with design best practices. The tool is currently available on an open-source basis.

現在の作業コピーが以前のリビジョンと互換性があるかどうかを確認するには、呼び出すことができます.

buf check --against 'reference-to-a-previous-revision'

どこreference-to-a-previous-revision Gitリポジトリリファレンスかimage built bufによって.
特定のブランチをチェックするには、

buf check --against '.git#branch=master'

特定のコードリビジョンを参照する他のすべての方法についてはexcellent docs .

適切な互換性制約の確保

全てのシステムがprotobufsを等しくしているわけではなく、JSON 下の行は、他のバイナリメッセージだけに依存します.BUFは、プロジェクトの適切な互換性レベルを定義することで柔軟です.
BUFのドキュメントは素晴らしいoverview サポートされている規則.

GITLAB CIを用いた破壊変化の検出

マージ要求ベースのフローを使用する場合は、通常、ターゲットブランチに対する互換性違反の変更のためのすべてのマージ要求をチェックするのに十分です.
解決はすべての状況をカバーしません、特に変更がマージ要求を使用せずに導入されるとき、すべてのケースを支持することはbufイメージを構築して、保存することを必要とするでしょう.
静的なバイナリの他に、bufもDockerイメージを提供します.それを使用してワークフローを簡素化します.
すべてのマージ要求をチェックするには、次のスニペットをリポジトリに紹介します.gitlab-ci.yml :

stages:
  - ensure backwards compatibility

validate merge request:
  stage: ensure backwards compatibility
  image: 
    name: bufbuild/buf:0.41.0
    entrypoint: [""]
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  script:
    - buf breaking --against "${CI_REPOSITORY_URL}#branch=${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}"

CI_REPOSITORY_URL に提供するURLに展開しますgit clone . これは、トークンを含んでいるので、アクセス管理は無関係です.

他のCI解を用いた破壊変化の検出

Buf's repository のための典型的なワークフロー定義を含みます:

トラリスシス

ギタブアクション

サークルCI

コードスタイルチェック

は、ファイル間のコードの一貫性を確保するのに役立ちます.Protobufで、それは異なりません.
bufとの接続は楽であり、実行することで行うことができますbuf lint .
エラーや警告が発生した場合buf , 彼らを無遠慮に修正しようとしないでください.スキーマが生産環境で使用されている場合は、中断します.代わりに、小さく、インクリメンタルな変更を行い、非互換性をチェックします.いずれかが発生すると、することができますmake an exclusion そして、将来のインターフェイスのバージョンであなたのミスを修正します.

GITLAB CIを使用して自動的にリント

すべてのブランチですべてのコミットをチェックするには、次のように.gitlab-ci.yml .

stages:
  - lint

lint:
  stage: lint
  image: 
    name: bufbuild/buf:0.41.0
    entrypoint: [""]
  script:
    - buf lint
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
      when: never
    - if: '$CI_COMMIT_BRANCH'

LINTステージに接続された規則は、マージ要求のために実行されている複数のパイプラインを防止します.

断線変化検出とリンギングの結合

簡単に上記の例を1つでまとめることができます.gitlab-ci.yml :

image: 
  name: bufbuild/buf:0.41.0
  entrypoint: [""]

stages:
  - lint
  - ensure backwards compatibility

lint:
  stage: lint
  script:
    - buf lint
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
      when: never
    - if: '$CI_COMMIT_BRANCH'

validate merge request:
  stage: ensure backwards compatibility
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  script:
    - buf breaking --against "${CI_REPOSITORY_URL}#branch=${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}"

私は下にサンプルリポジトリを作成しているhttps://gitlab.com/mionskowski/protobuf-ci . 移動するMerge Requests の両方を見て失敗したパイプラインを参照してください.