CI/CD гэж юу вэ? Continuous Integration болон Delivery-г энгийнээр тайлбарлая
CI/CD бол код өөрчлөлт бүрийг автоматаар бүтээж, тестлэж, тэнцсэн тохиолдолд гаргахад бэлтгэх эсвэл гаргах програм хангамж гаргах арга юм. CI (continuous integration) гэдэг нь өөрчлөлтүүдийг байнга нэгтгэж, үе бүр автомат тестээр шалгахыг хэлнэ. CD (continuous delivery эсвэл deployment) гэдэг нь тэнцсэн өөрчлөлтүүдийг багцлаж, хэрэглэгчдэд бага эсвэл огт гар ажилгүйгээр хүргэхийг хэлнэ.
Гол санаа энгийн: алдааг хэдэн долоо хоногийн дараа харилцагч олохын оронд, гаргасны дараахан минутуудад нь барих.
AI-аар бүтээхэд CI/CD яагаад чухал вэ
AI builder код өөрчлөлтийг хурдан хийдэг. Нэг prompt арав хүртэл файлд хүрч болно. Энэ хурд маш сайн боловч төлбөрийн хуудсанд хийсэн өөрчлөлт нэвтрэх хуудсыг чимээгүй эвдэж, хэрэглэгч имэйл бичих хүртэл хэн ч анзаардаггүй үед хүнд болдог.
CI/CD яг энэ зорилгод зориулсан сүлжээний аюулгүй байдал юм. Өөрчлөлт бүр зөв гэж итгэхийн оронд pipeline нь ижил шалгалтуудыг үе бүр ажиллуулдаг:
- Апп алдаагүйгээр бүтээгдэж байгаа хэвээр юу?
- Автомат тестүүд хэвээр тэнцэж байна уу?
- Код төслийн дүрмийг (төрөл, формат, аюулгүй байдлын шалгалт) дагаж байна уу?
Аль нэг шалгалт бүтэлгүйтвэл өөрчлөлт хэрэглэгчдэд хүрэхээсээ өмнө зогсдог. Код чинь хурдан өөрчлөгдөх тусам, ядрахгүй, алхамаа алгасдаггүй шалгалт илүү үнэтэй болдог.
Өдөр тутмын жишээ
Өглөө бүр дэлгүүрүүдэд талх нийлүүлдэг талхны газрыг бодоорой.
- CI/CD-гүй бол талхчин бүр долоо хоног тусдаа жорыг өөрийнхөөрөө тохируулдаг, дараа нь бүгд баасан гарагийн шөнө нэгтгэж, талх хэвээр өндөрлөнө гэж найдна. Тэгэхгүй бол хэн өөрчлөлтөөс болсныг хэн ч мэдэхгүй.
- CI-тай бол жор бүрийн жижиг өөрчлөлтийг тэр даруй туршилтын талх болгон жигнэж, амт, жин, хэлбэрийг шалгадаг. Муу өөрчлөлтийг тэр өдөртөө барьж, аль нь мөн болохыг яг мэддэг болно.
- CD-тэй бол шалгалтанд тэнцсэн талхнууд шууд хүргэлтийн фургон руу багцлагдаж, ижил журмаар шошголлоо гардаг, харин хэн нэгэн өглөөний 5 цагт хайрцаг гараар савладаггүй.
Шалгалт талхчдыг илүү сайн болгодоггүй. Энэ нь тэдний алдааг хямд болгодог.
CI/CD pipeline хэрхэн ажилладаг вэ
Pipeline гэдэг нь аливаа зүйл тохиолдоход (ихэвчлэн хэн нэгэн GitHub зэрэг repository рүү код түлхэхэд) CI/CD үйлчилгээ автоматаар ажиллуулдаг алхмуудын жагсаалт юм. Ердийн pipeline ийм харагддаг:
| Алхам | Юу болдог | Юуг барьж авдаг |
|---|---|---|
| 1. Эхлүүлэгч | Код түлхэгдэх эсвэл pull request нээгдэх | — |
| 2. Суулгах | Шинэ машин код болон түүний dependency-уудыг татдаг | Алга болсон эсвэл эвдэрсэн багцууд |
| 3. Build | Апп хөрвүүлэгдэж эсвэл багцлагдана | Синтаксийн болон төрлийн алдаа, эвдэрсэн import |
| 4. Тест | Автомат тестүүд ажиллана | Ажиллахаа больсон функцууд |
| 5. Шалгалт | Linting, formatting, аюулгүй байдлын скан | Загварын асуудал, мэдэгдэж буй эмзэг багцууд, задарсан key-үүд |
| 6. Staging руу deploy | Апп продакшний туршилтын хуулбар руу орно | Зөвхөн жинхэнэ орчинд гарч ирдэг асуудлууд |
| 7. Продакшн руу deploy | Апп амьд болно — автоматаар эсвэл зөвшөөрөлтэй | — |
Алхам бүр хэн нэгний лаптоп биш, цэвэр машин дээр ажилладаг тул «миний компьютер дээр ажилладаг» гэдэг шалтаг зогсдог. Хэрэв алхам бүтэлгүйтвэл pipeline зогсож, өөрчлөлт хийсэн хүнд мэдэгддэг.
Алхамууд нь кодтой хамт байдаг тохиргооны файлд тодорхойлогддог. Жишээлбэл GitHub Actions-д энэ нь repository-ийн .github/workflows фолдер дахь YAML файл юм.
Continuous delivery ба continuous deployment
«CD» гэдэг нь ойлгомжгүй бөгөөд хүмүүс үүнийг хоёр аргаар ашигладаг:
| Continuous delivery | Continuous deployment | |
|---|---|---|
| Тест автоматаар ажиллана | Тийм | Тийм |
| Гаргалт автоматаар багцлагдана | Тийм | Тийм |
| Автоматаар амьд руу гарна | Үгүй — хүн «гаргах» товчийг дарна | Тийм — тэнцсэн өөрчлөлт бүр гарна |
| Тохиромжтой | Ихэнх жижиг баг, төлбөртэй хэрэглэгчтэй апп | Сайн тестийн хамрах хүрээ, мониторинг бүхий баг |
Continuous deployment зөвхөн тест сайн байвал сайн ажилладаг. Хэрэв таны тест төлбөрийн хэсгийг хамраагүй бол continuous deployment эвдэрсэн төлбөрийн хэсгийг хайхрамжгүй гаргах болно.
Жишээ: pipeline-тай захиалгын апп
Та гоо сайхны салоны захиалгын апптай, кодоо GitHub repository-д хадгалдаг гэж бодъё. Та AI builder-оос «анх удаа ирж буй харилцагчдад 10% хөнгөлөлт нэм» гэж хүсдэг.
- Өөрчлөлт шинэ branch руу түлхэгдэж, pull request нээгдэнэ.
- Pipeline эхэлнэ. Багц суулгаж, апп-ыг бүтээнэ — энэ тэнцэнэ.
- Тест ажиллана. Нэг тест, «буцаж ирсэн харилцагч бүтэн үнээр төлнө», бүтэлгүйтнэ: хөнгөлөлтийг бүх хүнд хэрэглэж байна.
- Pull request дээр улаан загалмай гарна. Өөрчлөлтийг нэгтгэх боломжгүй.
- Та AI-аас засахыг хүснэ. Тэр засвар түлхэнэ; pipeline дахин ажиллаж бүгд тэнцэнэ.
- Өөрчлөлт нэгтгэгдэж, pipeline үүнийг staging орчин руу deploy хийнэ. Тэнд та туршилтын захиалга хийж үзнэ.
- Та зөвшөөрч, продакшн руу deploy хийгдэнэ.
Pipeline-гүй бол 3-р алхам таны харилцагчдын дансанд аль хэдийн нөлөөлсөн байх байсан.
Гол нэр томьёо
| Нэр томьёо | Утга |
|---|---|
| Pipeline | Өөрчлөлт бүр дээр ажилладаг автомат алхмуудын дараалал. |
| Build | Эх кодыг ажиллах боломжтой зүйл болгон хөрвүүлэх. |
| Автомат тест | Бусад кодыг зөв ажиллаж байгааг шалгадаг код. |
| Pull request (PR) | Нэгтгэхээс өмнө бусад хүмүүс (мөн pipeline) шалгах санал болгосон өөрчлөлт. GitHub гэж юу вэ гэдгийг үзнэ үү. |
| Branch | Явагдаж буй ажил үндсэн кодонд нөлөөлөхгүйн тулд тусдаа өөрчлөлтийн мөр. |
| Staging | Хэрэглэгчид харахаас өмнө өөрчлөлтийг шалгах, продакшнийг дуурайдаг аппын хувийн хуулбар. |
| Продакшн | Таны хэрэглэгчид ашигладаг амьд апп. |
| Rollback | Гаргалт буруу болоход өмнөх ажиллаж байсан хувилбар руу буцах. |
| Ногоон / улаан build | Pipeline-ийн ажиллагаа тэнцсэн / бүтэлгүйтсэн. |
Түгээмэл буруу ойлголтууд
- «CI/CD гэдэг нь миний апп тестлэгдсэн гэсэн үг.» Pipeline зөвхөн таны байгаа тестийг ажиллуулна. Тест байхгүй бол CI зөвхөн аппыг бүтээж байгааг баталдаг — өөр юу ч биш. Хамгийн чухал урсгалуудад тест бичихийг AI-аасаа асуугаарай.
- «CI/CD зөвхөн том компаниудад зориулагдсан.» GitHub Actions зэрэг hosted хэрэгслүүд тохируулахад богино тохиргооны файл шаарддаг бөгөөд жижиг багууд байнга ашигладаг. Хүчин чармайлт гардаг нь хэрэгслээс биш, тестээс.
- «Автомат deployment гэдэг нь хэн ч юу ч шалгахгүй гэсэн үг.» Сайн pipeline шалгалтыг нэмдэг, хасдаггүй. Олон баг продакшнээс өмнө хүний зөвшөөрлийн алхмыг хадгалдаг.
- «Pipeline ногоон бол апп ажилладаг.» Энэ нь автомат шалгалтууд тэнцсэн гэсэн үг. Та өөрчлөлтийг өөрөө, дээрээс нь урьдчилан харах орчинд эсвэл staging дээр туршиж үзэх хэрэгтэй.
- «CI/CD нөөц хуулбарыг орлодог.» Үгүй. Тестэнд тэнцсэн муу өгөгдлийн сангийн migration жинхэнэ өгөгдөлд хохирол учруулж болно. Нөөц хуулбар болон буцаах арга хадгал.
AI builder-оосоо юу асуух вэ
- «Бүртгүүлэх, нэвтрэх, төлбөрийн хэсэгт автомат тест бич, мөн тэдгээрийг хэрхэн ажиллуулахаа харуул.»
- «Pull request болгонд хамаарлыг суулгаж, аппыг бүтээж, тестийг ажиллуулдаг GitHub Actions workflow тохируул.»
- «Pipeline-д type check болон linter нэм, алдаа гарвал бүтэлгүйтдэг болго.»
- «Pipeline-ийн алхам бүр юу хийдгийг энгийн хэлээр тайлбарла.»
- «Deploy хагас замдаа бүтэлгүйтвэл юу болох вэ? Би яаж буцаах вэ?»
- «Repository-д эсвэл pipeline-ийн logs дээр нууц мэдээлэл код дотор бичигдээгүй, хэвлэгдээгүй эсэхийг шалга.»
Хэрэв таны апп API key ашигладаг бол pipeline-д тэд хэрэгтэй — CI хэрэгсэлд шифрлэгдсэн secret хэлбэрээр хадгалагдана, тохиргооны файлд хэзээ ч биш. Environment variable ба secret гэдгийг үзнэ үү.
CI/CD ба Mythex
Mythex таны оронд CI pipeline ажиллуулдаггүй боловч ижил хэрэгцээний хэд хэдэн хэсгийг өөрийн аргаар хангадаг:
- Checkpoint. Агентын амжилттай эргэлт бүрийн дараа Mythex git checkpoint хадгалдаг, мөн өөрчлөлт буруу болбол Энэ цэг рүү буцаах нь төслийг буцаадаг. Чат хуудсыг үзнэ үү.
- App Testing.
/testгэж бичвэл агент таны амьд урьдчилан харалтыг хэрэглэгч шиг дарж, эвдэрсэн урсгалуудыг мэдээлдэг — нийтлэх бүрийн өмнө хэрэгтэй. App Testing хуудсыг үзнэ үү. - Нийтлэх нь зориудаар хийдэг алхам. Өөрчлөлтүүд эхлээд хувийн урьдчилан харах орчинд гарна; таны нийтийн апп зөвхөн дахин нийтлэхэд шинэчлэгдэнэ — continuous deployment-аас илүү continuous delivery-д ойр.
- GitHub sync (Pro). Төслөө GitHub repository-тэй синк хийвэл түлхэх бүрт тест ажиллуулах өөрийн GitHub Actions workflow нэмж болно. GitHub болон экспорт хуудсыг үзнэ үү.
Нийтлэхийн өмнө гараар юу тестлэх вэ гэсэн жагсаалтын хувьд аппаа нээлтийн өмнө хэрхэн тестлэх вэ гэдгийг, хувилбарын хяналттай ажиллах талаар AI-аар бүтээсэн аппд Git хэрхэн ашиглах вэ гэдгийг үзнэ үү.
Асуултууд
CI/CD гэдэг нь юуны товчлол вэ?
CI нь continuous integration гэсэн утгатай: код өөрчлөлт бүрийг байнга нэгтгэж, автоматаар бүтээж, тестлэдэг. CD нь continuous delivery эсвэл continuous deployment гэсэн утгатай: тестэнд тэнцсэн өөрчлөлтүүд гаргахад бэлтгэгдэнэ (delivery) эсвэл гар аргаар алхам хийхгүйгээр хэрэглэгчдэд гаргагдана (deployment).
Continuous delivery болон continuous deployment-ийн ялгаа юу вэ?
Continuous delivery-д pipeline-аас тэнцсэн өөрчлөлт бүр гаргахад бэлэн боловч хэзээ амьд руу гаргахаа хүн шийднэ. Continuous deployment-д тэнцсэн өөрчлөлт бүр хүний зөвшөөрөлгүйгээр автоматаар амьд руу гарна.
AI-аар бүтээсэн жижиг аппдаа CI/CD хэрэгтэй юу?
Эхний өдрөөсөө шаардлагагүй. Цөөн хэрэглэгчтэй жижиг апп урьдчилан харах орчинд тестлэж, гараар нийтлэх замаар явж болно. CI/CD нь хэд хэдэн хүн код өөрчилж эхлэх, жинхэнэ харилцагчид аппаас хамаарч эхлэх, эсвэл өмнө нь ажиллаж байсан зүйлүүд эвдрэх дутагдал гарч эхлэх үед үнэ цэнээ өгдөг.
CI/CD-д ямар хэрэгсэл ашигладаг вэ?
Түгээмэл нь GitHub Actions, GitLab CI/CD, CircleCI болон Jenkins, мөн hosting платформуудын суурилуулсан deploy pipeline-ууд. Тэд бүгд нэг үндсэн ажлыг хийдэг: код өөрчлөгдөх бүрт алхмуудын жагсаалтыг автоматаар ажиллуулах.