프로토콜 버퍼 또는 Protobuf는 언어에 구애받지 않습니다.
데이터를 직렬화하는 메커니즘.
Protobuf 스키마는 업계에서 가장 인기 있고 널리 채택된IDL 프로토콜 버퍼 언어를 사용하여 지정됩니다.

Protobuf는 서비스 간 통신을 위해 RPC 서비스에서 가장 일반적으로 사용됩니다. 공용 인터페이스에 대한 사용도 증가하고 있으며 최근에는 Apache Kafka과 같은 도구에 채택되었습니다.

Used correctly 정방향 및 역방향 호환 메시지 생성 및 소비를 모두 가능하게 합니다. 즉, 이전 소비자/클라이언트(이전 Protobuf 스키마 사용)는 새 생산자/서버의 메시지를 사용할 수 있으며 그 반대의 경우도 마찬가지입니다. 나에게 이것은 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 저장소 참조이거나 Buf의 image built일 수 있습니다.

특정 분기를 확인하려면 다음을 실행할 수 있습니다.

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

특정 코드 개정판을 참조하는 다른 모든 방법에 대해서는 Buf'sexcellent docs를 참조할 수 있습니다.

적절한 호환성 제약 조건 보장

모든 시스템이 동일한 Protobuf를 사용하는 것은 아니며 일부는 메시지를 JSON로 직렬화하고 다른 시스템은 바이너리 메시지에만 의존합니다. Buf는 프로젝트에 대한 적절한 호환성 수준을 정의하는 측면에서 유연합니다.

Buf의 문서는 많은 지원 규칙overview을 제공합니다.

Gitlab CI를 사용하여 브레이킹 체인지 감지

병합 요청 기반 흐름을 사용하는 경우 일반적으로 대상 분기에 대한 호환성 손상 변경에 대한 모든 병합 요청을 확인하는 것으로 충분합니다.

이 솔루션은 모든 상황, 특히 병합 요청을 사용하지 않고 변경 사항이 도입되는 경우를 다루지는 않지만 모든 경우를 지원하려면 buf 이미지를 빌드하고 저장해야 합니다.

정적 바이너리 외에도 Buf는 도커 이미지도 제공합니다. 이를 사용하면 작업 흐름이 단순화됩니다.

모든 병합 요청을 확인하려면 다음 스니펫을 저장소.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는 git clone에 제공할 수 있는 URL로 확장됩니다. 여기에는 토큰이 포함되므로 액세스 관리는 중요하지 않습니다.

다른 CI 솔루션을 사용하여 브레이킹 체인지 감지

Buf's repository에는 다음에 대한 예시적인 워크플로 정의가 포함되어 있습니다.

트래비스 CI

Github 작업

서클 CI

코드 스타일 검사

Linter는 파일 간에 코드 스타일 일관성을 보장하는 데 도움이 됩니다. Protobuf도 다르지 않습니다.

buf를 사용한 Linting은 수월하며 buf lint를 실행하여 수행할 수 있습니다.
buf에서 오류 또는 경고가 표시되는 경우 함부로 수정하려고 하지 마십시오. 프로덕션 환경에서 스키마를 사용하면 문제가 발생합니다. 대신 조금씩 점진적으로 변경하고 비호환성을 확인하십시오. 문제가 발생하면make an exclusion 향후 인터페이스 버전에서 실수를 수정할 수 있습니다.

Gitlab CI를 사용하여 자동으로 Lint

모든 분기의 모든 커밋을 확인하려면 다음을 .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 단계에 연결된 규칙은 병합 요청에 대해 여러 파이프라인이 실행되는 것을 방지합니다.

Linting과 브레이킹 체인지 감지의 결합

위에서 설명한 예제를 하나의 예제로 쉽게 결합할 수 있습니다.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으로 이동합니다.