Как да разделим сложен конвейер на управляеми модули
Сценарий
Вие изграждате тръбопровод, който помага на вашия екип да нулира тестовите данни в различни непроизводствени среди, като 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
За тривиалния подход щракнете тук.
Кодиране на ниво нагоре
Благодарим ви, че сте част от нашата общност! Преди да тръгнеш:
- 👏 Аплодирайте за историята и следвайте автора 👉
- 📰 Вижте повече съдържание в Публикация за кодиране на ниво нагоре
- 🔔 Последвайте ни: Twitter | LinkedIn | Бюлетин
🚀👉 Присъединете се към колектива за таланти Level Up и намерете невероятна работа