GitLab CI/CD (Continuous Delivery гэж юу вэ?)
2B | +1% better 2day | dev.008
Манай компани төслийн менежмент дээрээ Redmine, Github, GitLab 3-г хэрэглэдэг ч ихэнх төслүүд нь GitLab дээр явагддаг. UMS-н хувьд GitLab CE-г 2014 оноос хойш ашиглаж ирсэн бол 2015 оны сүүлээр 8.0 хувилбар дээр CI/CD гэсэн хэсэгтэй болсон байдаг.
Тэгвэл өнөөдөр энэхүү CI/CD хэсэг тэр дотроо CD-г хэрхэн хөгжүүлэлтийн явцдаа ашиглах талаар бичлээ.
CI гэж юу вэ?
Less manual work, more automation
Ямар ч апп/систем дээр шинэчлэл хийгдэх үед хуучин байсныгаа эвдлэх аюул байдаг. Түүнийг шалгахын тулд нэг бол бүх case-ээр гараар шалгах эсвэл автомат тестээр шалгах гэсэн 2 сонголт бий.
(Огт шалгадаггүй хүмүүсийг бурхан өршөөг 🙌)
Харин Continuous Integration (CI) гэдэг нь автоматаар шалгах сонголт нь юм. Товчхондоо бол source code байгаа repo-руу code commit хийх болгонд тест код ажилладаг. Ингэснээр системийг алдаагүй ажиллаж байгаа, бусад системүүдтэй асуудалгүй интеграци хийгдэж байгааг шалгах боломжтой болдог.
Source Code → New commit → CI [Build →Test]
CD гэж юу вэ?
Ensures that every change to the system is releasable
Системийн өөрчлөлт бүр release хийх боломжтой, бас ганцхан товч дараад л хэрэглэгчийн гар дээр очдог байвал ямар вэ?
Гоё үү? 👍
Continuous Delivery (CD) гэдэг нь CI-н дараачийн алхам бөгөөд хэрэглэгчийн гар дээр бүтээгдэхүүнийг хүргэх тэр процессыг автоматжуулахыг хэлдэг. Тестээ давчихсан бүтээгдэхүүнээ package-лаад бэлдээд тавьчихдаг. Хүсвэл 1 товч дараад л хэрэглэгчдээ хүргэчих боломжтой.
Тэгсэн чинь хүний оролцоог бүр хасмаар байвал яах уу? ❌👤
Тэгвэл дахиад нэг CD болох Continuous Deployment-руу шилжинэ дээ. Энэ тохиолдолд танаас хамааралгүйгээр бүх зүйл АВТОМАТ-аар хийгдэх болно. Хөгжүүлэгч кодоо push* хийлээ, автоматаар CI ажиллана, дараа нь автоматаар CD ажиллаад эцсийн хэрэглэгчийн апп хамгийн сүүлчийн хувилбараар шинэчлэгдсэн байх болно.
GitLab CI/CD with AWS EC2
Үндсэн зорилго : GitLab CI дээр нэгжийн тест тохируулсан Node.js суурьтай системийг Continuous Delivery-тэй болгох.
- CI ажиллаж байгаа учраас GitLab Runner тохируулчихсан,
.gitlab-ci.ymlфайл байгаа гэсэн үг. (stages : build & test) .gitlab-ci.ymlдотор дараачийн алхам болох deploy stage-г нэмж өгөх, тухайн stage-н хэзээ, ямар үйлдэл хийхийг тохируулах хэрэгтэй.- Тест хийж, зөв ажиллаж байгаа эсэхийг шалгана. Зөвхөн 1 branch дээр нэгжийн тест давсны дараа, shell script-н ажиллагаа асуудалгүй гэдгийг.
За тэгээд шууд ажилруугаа оръё
1. CI (runner, .gitlab-ci.yml file, jobs, MR)
GitLab CI ашиглах, runner тохируулах болон нэгжийн тестийг ажиллуулахыг аль хэдийн хийчихсэн гэж үзэх тул энэ нийтлэлд тайлбарлахгүй болно. Харин тэдгээр нь заавал ажиллаж байх ёстой тул жишээ зургуудыг орууллаа.
— #1 GitLab runner тохируулсан байх
— #2 .gitlab-ci.yml файл
— #3 CI jobs амжилттай ажиллаж байх
— #4 Merge Request дээр CI ажиллаж байх
#2 .gitlab-ci.yml file in project root
2. Add `deploy` stage
GitLab CI хувьд үндсэн build, test, deploy гэсэн 3 stage-тэй. Build stage дотор ажлууд нэгэн зэрэг ажиллах бөгөөд бүгд амжилттай болбол дараачийн stage-н ажлууд эхэлдэг байна. Хүсвэл өөр custom stage үүсгэж ч бас болдог юм билээ. Өнөөдрийн хувьд test stage байгаа тул шууд deploy stage үүсгээд ашиглахад асуудалгүй.
Гэхдээ deploy stage-г зөвхөн онцгойлсон branch дээр ажиллуулахаар тохируулах байгаа. Merge Request (MR) болгон дээр нэгжийн тестийг ажиллуулаад, онцгой branch дээр нэгжийн тест + системийн шинэчлэл хийх 2 ажлыг тохируулна.
— #1 ONLY unit test on MRs
— #2 [Unit test + Deploy] on specific branch
Түүнээс гадна deploy stage-н скрипт нь хэрэгтэй зарим тохиргоог Settings → CI/CD → Variables дотор хадгална. AWS дээрх дэд бүтэц нь системийн FrontEnd нь нэг EC2 instance дээр, BackEnd нь нэг EC2 instance дээр харин энэ 2 луугаа зөвхөн Bastion host-оор дамжиж орж болохоор зохицуулсан. Тиймээс public IP, хэн гэдэг хэрэглэгч, ямар түлхүүр ашиглаж хандах тохиргоо хэрэг болно. Түүнээс гадна FrontEnd, BackEnd, Database migration-ий скриптийг ажиллуулах эсэхийг тохиргооноос авахаар хийсэн.
Скриптийн хувьд эхлээд Bastion host-рүү хандаж, тэндээсээ яг систем ажиллаж байгаа EC2 instance-руу private IP ашиглан нэвтэрнэ. Тэгэх явцдаа нэвтэрч орсны дараа энэ скриптийг ажиллуулна гэдгээ дамжуулдаг. Тэр скрипт нь харин тухайн орчиндоо шинэчлэлтэй холбоотой үйлдлүүдээ хийнэ.
(Git pull, prepare .env, npm install, pm2 restart etc…)
3. Test
За тэгээд дээрх тохиргоо, скриптүүд маань зөв ажиллаж байгаа эсэхийг шалгах хэрэгтэй болно. GitLab CI/CD маань зөв ажиллаж байна уу, Variables-с зөв утгаа авч байна уу, скрипт маань алдаагүй байна уу, шинэчлэл амжилттай хийгдээд дуусаж байна уу гэх мэт…
— #1 Гараар ажиллуулах stage-г харуулах
— #2 Deploy job амжилттай ажиллах
— #3 deploy stage амжилттай дуусах
— #4 Системийн ажиллагааг шалгах (integration test & manual verification)
stage-г харуулах
deploy stage амжилттай дуусах
За ингээд ямар ч байсан CI-аа сайжруулаад CD-тэй болгочихлоо. Гэхдээ энэ нь хангалттай биш бөгөөд дөнгөж эхний хувилбар гэж болно. Цаашлаад variables-г хэрхэн ашиглах, CI/CD best practice-г оруулах гэх мэт сайжруулах зүйлс зөндөө бий.
Одоогийн энэ хувилбар маань release хийх явцад гарж болох буруу бичих, branch андуурах, үйлдэл алгасах, maintenance хугацаанд амжихгүй байх гэх мэт хэд хэдэн асуудлыг шийдсэн байгаа. Түүнээс гадна terminal дээр баахан урт юм бичих, уйтгартай нэг ажлыг хөнгөвчилж байгаа шүү. 🤣
Сайжруулах санал, зөвлөгөө байвал сэтгэгдэл дээр үлдээгээрэй.
