Как да разделим сложен конвейер на управляеми модули

Сценарий

Вие изграждате тръбопровод, който помага на вашия екип да нулира тестовите данни в различни непроизводствени среди, като Test и Sandbox.

Във всяка среда има няколко приложни услуги или бази данни за изчистване. Нека ги наречем A, B и C.

Тривиален подход

Можете да създадете 3 отделни работни места за всяка среда

Ще работи. Но има 2 сериозни проблема с този подход:

  • Високо дублиране на код: 2-те задания за 2 различни среди споделят почти поне 90% от своите кодове
  • Проблемна поддръжка: Само си представете какво трябва да направите, за да добавите нова услуга или по-лошо, да поддържате нова среда
stages:
  - test
  - sandbox


# TEST jobs 
Reset Service A - Test:
  stage: test
  script: |
    echo "Resetting service A's data in TEST"
    echo "...busy-ing..."
    echo "Reset A done"

Reset Service B - Test:
  stage: test
  script: |
    echo "Resetting service B's data in TEST"
    echo "...busy-ing..."
    echo "Reset B done"

Reset Service C - Test:
  stage: test
  script: |
    echo "Resetting service C's data in TEST"
    echo "...busy-ing..."
    echo "Reset C done"

# SANDBOX jobs 
Reset Service A - Sandbox:
  stage: sandbox
  script: |
    echo "Resetting service A's data in SANDBOX"
    echo "...busy-ing..."
    echo "Reset A done"

Reset Service B - Sandbox:
  stage: sandbox
  script: |
    echo "Resetting service B's data in SANDBOX"
    echo "...busy-ing..."
    echo "Reset B done"

Reset Service C - Sandbox:
  stage: sandbox
  script: |
    echo "Resetting service C's data in SANDBOX"
    echo "...busy-ing..."
    echo "Reset C done"

Подход родител-дете

Този подход решава двата проблема, идентифицирани по-рано. Има точно 1 работа за 2 (или в бъдеще повече) среди. Добавянето на ново задание не изисква дублирането му във всички среди. Поддържането на нова среда не изисква дублиране и модифициране на всичките 3 работни места.

Нека го видим в действия

Родителският тръбопровод

Това е основният тръбопровод, където конфигурираме 2 среди: „test“ и „sandbox“ като стойности на stages. След това дефинираме едно задание за всяка среда, като всяко разширява .common дефиницията на задание, но предоставя свои собствени променливи (напр. ENV: "TEST" или ENV: "SANDBOX”). Ключовият фактор в .common заданието е trigger:include конфигурацията, която, когато бъде изпълнена, ще задейства заданията, дефинирани във файла .gitlab-reset-data.yml — дъщерния конвейер.

stages:
  - test
  - sandbox

.common:
  allow_failure: true
  rules:
    - when: manual
  trigger:
    include: .gitlab-reset-data.yml


Reset Test Data:
  stage: test
  extends: .common
  variables:
    ENV: "TEST"


Reset Sandbox Data:
  stage: sandbox
  extends: .common
  variables:
    ENV: "SANDBOX"

Детският тръбопровод

Това е мястото, където се дефинират заданията за нулиране за всяка услуга A, B и C. Както виждаме, има само 1 задание на услуга за ВСИЧКИ среди.

stages:
- reset

Reset Service A:
  stage: reset
  script: |
    echo "Resetting service A's data in $ENV environment"
    echo "...busy-ing..."
    echo "Reset A done"

Reset Service B:
  stage: reset
  script: |
    echo "Resetting service B's data in $ENV environment"
    echo "...busy-ing..."
    echo "Reset B done"

Reset Service C:
  stage: reset
  script: |
    echo "Resetting service C's data in $ENV environment"
    echo "...busy-ing..."
    echo "Reset C done"

Примерни кодове

Вижте примерния код в моето хранилище на GitLab

За тривиалния подход щракнете тук.

Кодиране на ниво нагоре

Благодарим ви, че сте част от нашата общност! Преди да тръгнеш:

🚀👉 Присъединете се към колектива за таланти Level Up и намерете невероятна работа