CI/CD

Экосистемийн бүх репо GitHub Actions ашиглана. Энэ хуудас нь нийтлэг загвар, конвенцийг тайлбарлана.

Үндсэн зарчим

1. PR дээр шалгана, main дээр байршуулна. PR нь build + тест ажиллуулна, юу ч deploy хийхгүй. main руу нэгтгэсний дараа л deploy асна.
2. Өөрчлөгдсөнийг л барина. paths-filter-ээр аль хэсэг өөрчлөгдсөнийг тодорхойлж, зөвхөн тэр үйлчилгээг дахин барина.
3. Зэрэг deploy хийхгүй. concurrency бүлгээр production deploy нь дараалалд орно, зэрэг ажиллахгүй.
4. Нууц мэдээлэл зөвхөн GitHub Secrets-д. Workflow файлд хэзээ ч бичигдэхгүй.

Ердийн workflow бүтэц

name: deploy

on:
  push:
    branches: [main]
    paths:
      - 'backend/**'
      - 'frontend/**'
      - '.github/workflows/deploy.yml'
  workflow_dispatch:          # гараар ажиллуулах боломж

concurrency:
  group: deploy-production
  cancel-in-progress: false   # deploy-г дундаас нь таслахгүй

cancel-in-progress: false чухал

Deploy дунд нь тасрах нь хагас байршуулалт үлдээж болно — шинэ контейнер асаагүй, хуучин нь унтарсан төлөв. Deploy-г дуустал нь ажиллуулж, дараагийнхыг дараалалд оруулна.

Шалгалтын үе шат (PR)

Шалгалт	Юу хийдэг
Build	Код эмхэтгэгдэж байгаа эсэх
Unit тест	Бизнес логик
Интеграц тест	testcontainers — бодит PostgreSQL/Redis
Lint	Кодын хэв маяг
Баримтын strict build	Эвдэрсэн холбоос, дутуу файл илрүүлэх

Баримтын strict шалгалт

MkDocs-ийг --strict горимоор build хийнэ. Энэ горимд анхааруулга нь алдаа болдог:

• эвдэрсэн дотоод холбоос,
• nav-д заасан ч байхгүй файл,
• байгаа ч nav-д ороогүй файл.

Ингэснээр баримтын эвдрэл production-д хүрэхгүй.

Deploy үе шат

SSH-ээр хост руу холбогдож ажиллуулна. Шаардлагатай secrets (нийтлэг нэршил):

Secret	Утга
DEPLOY_HOST	Серверийн хаяг
DEPLOY_USER	SSH хэрэглэгч
DEPLOY_SSH_KEY	Хувийн түлхүүр
DEPLOY_PORT	SSH порт (сонголтоор, default 22)
DEPLOY_PATH	Хост дээрх зам

Нууц үг биш, SSH түлхүүр

Deploy-д SSH түлхүүр ашиглана, нууц үг биш. Түлхүүр нь хүчингүй болгоход хялбар, лог-д санамсаргүй ил гарах магадлал бага, олон хүнд тараахгүйгээр ротаци хийж болно.

Хэсэгчилсэн build

Монорепо-д нэг өөрчлөлт бүх үйлчилгээг барихыг шаарддаггүй:

- uses: dorny/paths-filter@v3
  id: filter
  with:
    filters: |
      backend: 'backend/**'
      frontend: 'frontend/**'
      edge: 'nginx/**'

Дараа нь зөвхөн өөрчлөгдсөн үйлчилгээг дахин барина. Edge (nginx) өөрчлөгдсөн бол бүтэн rebuild биш, зөвхөн конфиг синк + nginx -t + reload.

Edge конфигийн deploy

Edge nginx-ийн conf.d нь git-ээр удирдагдана. Deploy-ийн дараалал:

1. Хост дээрх репо-г git fetch && git reset --hard хийж синк,
2. docker exec <nginx> nginx -t — конфигийг шалгах,
3. Амжилттай бол nginx -s reload.

nginx -t алгасаж болохгүй

Буруу конфигтой reload хийвэл nginx асахаа болино — тэр үед бүх домэйн унана. nginx -t нь reload-оос өмнө ажиллаж, алдаатай бол deploy-г зогсоох ёстой.

Self-hosted runner

iOS болон Windows-ийн build-д (гарын үсэг зурах, notarization, MSIX багцлах) self-hosted macOS / Windows runner ашиглана. Эдгээр нь платформын тодорхой хэрэгсэл, гэрчилгээ шаарддаг тул үүлэн runner-т ажиллахгүй.

Хувилбарлалт ба rollback

• Image-ууд tag-тай. Хост дээрх <SVC>_IMAGE_TAG хувьсагчаар тодорхой хувилбарт пин хийж болно.
• Статик сайтын хувьд өмнөх build-ийн архивыг буцааж задална.

Энэ репо-гийн CI/CD

docs-gerege-mn репо нь хоёр workflow-той:

Workflow	Хэзээ	Юу хийдэг
ci.yml	PR + main push	MkDocs --strict build; артефакт үлдээнэ
deploy.yml	main push + гараар	Build → хуулах → контейнер шинэчлэх → edge vhost суулгах → амьд сайт шалгах

Дэлгэрэнгүйг Энэ баримтын платформ хуудаснаас үзнэ үү.