[GitLab CI] Monorepo (단일 리포지토리)에 여러 배포 가능한 디렉토리가있는 경우

マイクロサービスモノレポ (단일 리포지토리)로 관리하고 있는 경우, 루트에 놓인 .gitlab-ci.yml 만으로 기술하고 있으면 파일이 비대화하는 경향이 있습니다. 또한 프런트/백엔드 소스를 단일 리포지토리에 포함하는 경우에도 마찬가지입니다.

마이크로서비스 등의 독립적으로 배포 가능한 단위의 소스를 별도의 리포지토리로 관리하는 경우도 있다고 생각합니다만, 특히 프로그램의 규모가 그다지 크지 않은 경우는, 단일 리포지토리로 관리하는 편이, 취급 쉽다고 생각합니다.

덧붙여서 Wikipedia에는 ​​Google이나 Facebook등에서도 매우 대규모의 소스를 モノレポ 구성으로 관리하고 있다고 써 있습니다. 1 (영어에서는 monorepo=모노레포)

Google,[5] Facebook,[6] Microsoft,[7] Uber,[8] Airbnb and Twitter[9] all employ very large monorepos with varying strategies to scale build systems and version control software with a large volume of code and daily 변경.

이번에는 GitLab 12.7 에서 도입된 親子関係のパイプラインOnlyChanges 키워드를 조합한 구성을 소개합니다.


モノリシック 한 서비스의 경우나, 단순하게 .gitlab-ci.yml 가 비대화했을 경우의 대처법으로서는, include 키워드로 파일을 나누거나, extends 키워드로 리팩토링하는 방법이 있다고 생각합니다.

구성안



리포지토리의 디렉토리 구성 예


+ .gitlab-ci.yml  # ルートにあるCI/CD構成スクリプト
+ my_service_a # デプロイ可能なソースディレクトリ
|  + .my_service_a.yml
|  + ...
+ my_service_b # 別のデプロイ可能なソースディレクトリ
|  + .my_service_b.yml
|  + ...
|  ...
  • 만약 서비스의 디렉토리가 더 깊은 서브 디렉토리에 있어도 문제 없음.

  • 상위 파이프라인 정의


    .gitlab-ci.yml 내용
    image: alpine:3.7  # 参考用に軽いalpineに変更
    
    stages:
      - triggers
    
    my_service_a:
      stage: triggers
      only:
        refs: # ブランチを限定する場合
          - develop
          - stage
        changes: # 以下ディレクトリ内に変更があった場合のみトリガーされる
          - my_service_a/**/*
      trigger:
        include: my_service_a/.my_service_a.yml # 子パイプライン定義
        strategy: depend
    
    my_service_b:
      stage: triggers
      only:
        refs:  # ブランチを限定する場合
          - develop
          - stage
        changes: # 以下ディレクトリ内に変更があった場合のみトリガーされる
          - my_service_b/**/*
      trigger:
        include: my_service_b/.my_service_b.yml # 別の子パイプライン定義
        strategy: depend
    

    포인트


  • 무대는 triggers 전용
  • 전개 가능한 단위에 열거 (아래에서는 my_service_a, my_service_b)
  • only > refs 는 브랜치를 한정
  • only> changes는 푸시시 변경 사항이있는 경우에만 트리거합니다.
  • trigger 키워드로 참조 할 스크립트 지정
  • strategy: depend 에서 자식 파이프라인이 모두 성공할 때까지 부모도 성공 상태로 하지 않는다.

  • 하위 파이프라인 정의


    .my_service_a.yml (내용은 자유이지만 참고까지 일단 기재)
    image: alpine:3.7
    
    stages:
      - one
      - two
      - three
    
    stage_one_one:
      stage: one
      script:
        - echo "ONE"
    
    stage_two_one:
      stage: two
      script:
        - echo "TWO ONE"
    
    stage_two_two:
      stage: two
      allow_failure: false
      only:
        refs:
          - develop
      script:
        - echo "TWO TWO"
    
    stage_three_two:
      stage: three
      when: on_success
      only:
        refs:
          - develop
      script:
        - echo "THREE TWO"
    

    트리거



    develop 브랜치에서 my_service_a/ 또는 my_service_b/ 의 디렉토리 아래의 소스를 커밋하여 원격으로 푸시.



    요약


  • 각종 배포 가능한 디렉토리의 루트에 CI/CD의 구성을 쓰는 것으로 알기 쉽게 되었다.
  • Changes 키워드를 사용하여 커밋 할 때 변경 사항이있는 경우에만 실행하고 쓸데없는 실행을 생략했습니다.

  • 단점은 작은 파이프 라인 스크립트의 코드 공통화 범위가 부분적으로 제한됩니다. (예 : .my_service_a.yml ⇔ .my_service_b.yml 사이)

  • 참고 링크


  • GitLab CI/CD 파이프라인 구성 참조
  • How to get started with Parent-child pipelines



  • 출처: Wikipedia - Monorepo 

    좋은 웹페이지 즐겨찾기