GitLab дээр бид програм хангамжийн засварыг гараар болон автоматаар хоёр аргаар боловсруулдаг. gitlab.com-д автоматжуулсан байршуулалтаар дамжуулан чухал шинэчлэлтүүдийг үүсгэж, хүргэх хувилбарын менежерийн ажил, мөн хэрэглэгчдэд өөрсдийн суулгац дээр ажиллах засваруудын талаар үргэлжлүүлэн уншина уу.
Ухаалаг цагиндаа сануулга тавихыг би зөвлөж байна: сар бүрийн 22-нд GitLab-тай ажиллаж байгаа хэрэглэгчид манай бүтээгдэхүүний одоогийн хувилбарын шинэчлэлтийг харах боломжтой. Сар бүрийн хувилбар нь шинэ боломжууд, одоо байгаа зүйлсийн хөгжүүлэлтийг агуулдаг бөгөөд олон нийтийн хүсэлтийн эцсийн үр дүнг ихэвчлэн багаж хэрэгсэл эсвэл нэгтгэх талаар харуулдаг.
Гэхдээ практикээс харахад програм хангамжийн хөгжүүлэлт нь алдаа дутагдалгүй ховор байдаг. Алдаа эсвэл аюулгүй байдлын эмзэг байдал илэрсэн тохиолдолд хүргэх багийн хувилбарын менежер манай хэрэглэгчдэд суулгацын хамт нөхөөсийг үүсгэдэг. Gitlab.com нь CD процессын явцад шинэчлэгддэг. GitLab дээрх CD функцийг төөрөгдүүлэхгүйн тулд бид энэхүү CD процессыг автоматаар байршуулах гэж нэрлэдэг. Энэ үйл явц нь хэрэглэгчид, үйлчлүүлэгчид болон манай дотоод хөгжлийн багийнхны ирүүлсэн татах хүсэлтийн саналыг нэгтгэж болох бөгөөд ингэснээр засваруудыг гаргах уйтгартай асуудлыг шийдвэрлэх нь хоёр өөр аргаар шийдэгдэх болно.
«Бид хөгжүүлэгчдийн хийсэн бүх зүйлийг GitLab.com дээр гаргахаасаа өмнө өдөр бүр бүх орчинд байршуулж байгаа эсэхийг баталгаажуулдаг."гэж тайлбарлав , Дэд бүтцийн газрын Техникийн ахлах менежер. "Өөрийн суулгалтын хувилбаруудыг gitlab.com-ийн байршуулалтад зориулсан агшин зуурын зураг гэж төсөөлөөд үз дээ. Бид багц үүсгэх тусдаа алхмуудыг нэмсэн бөгөөд ингэснээр хэрэглэгчид үүнийг суулгацдаа суулгаж болно.".
Алдаа болон эмзэг байдлаас үл хамааран gitlab.com-ын хэрэглэгчид нийтлэгдсэний дараа удалгүй засваруудыг хүлээн авах бөгөөд энэ нь автоматжуулсан CD процессын давуу тал юм. Өөрийн суулгацтай хэрэглэгчдэд зориулсан засваруудыг хувилбарын менежерээр тусад нь бэлтгэх шаардлагатай.
Хүргэлтийн баг багасгахын тулд хувилбаруудыг бий болгоход оролцдог ихэнх үйл явцыг автоматжуулахын тулд шаргуу ажиллаж байна (үйлдвэрлэх хүртэлх дундаж хугацаа, өөрөөр хэлбэл үйлдвэрлэлд зарцуулсан хугацаа), хөгжүүлэгчийн нэгтгэх хүсэлтийг боловсруулахаас эхлээд gitlab.com дээр байршуулах хүртэлх хугацаа.
«Хүргэлтийн багийн зорилго бол бид компаний хувьд илүү хурдан хөдөлж чадна, эсвэл ядаж хүргэлтийн хүмүүсийг илүү хурдан ажиллуулж чадна гэдэгт итгэлтэй байх явдал юм.гэж Марин хэлэв.
gitlab.com-ын хэрэглэгчид болон тэдгээрийн суулгацын хэрэглэгчид хоёулаа мөчлөгийн хугацааг багасгаж, байршуулалтыг хурдасгах хүргэлтийн багийн хүчин чармайлтаас ашиг тус хүртдэг. Энэ нийтлэлд бид эдгээр хоёр аргын ижил төстэй болон ялгаатай талуудыг тайлбарлах болно. , мөн манай хүргэлтийн баг өөрсдийн байгууламж дээр ажиллаж байгаа хэрэглэгчдэд зориулж засваруудыг хэрхэн бэлтгэдэг, мөн gitlab.com-ийг автоматжуулсан байршуулалтыг ашиглан хэрхэн шинэчлэгдэж байгаа эсэхийг тайлбарлах болно.
Хувилбарын менежер юу хийдэг вэ?
Багийн гишүүд сар бүр хувилбаруудын хооронд тохиолдож болох засварууд болон аюулгүй байдлын хувилбаруудыг багтаасан өөрсдийн байгууламжид байгаа хэрэглэгчдэд бидний хувилбарууд. Тэд мөн компанийг автоматжуулсан, тасралтгүй байршуулалтад шилжүүлэх ажлыг удирдан чиглүүлэх үүрэгтэй.
Өөрөө суулгах хувилбарууд болон gitlab.com хувилбарууд нь ижил төстэй ажлын урсгалыг ашигладаг боловч өөр өөр цаг үед ажилладаг гэж Марин тайлбарлав.
Юуны өмнө, хувилбарын менежер нь хувилбарын төрлөөс үл хамааран GitLab-ийг gitlab.com дээр ажиллуулж эхэлснээс хойш ашиглах боломжтой бөгөөд аюулгүй байдлыг хангадаг бөгөөд үүний дотор хэрэглэгчдийн дэд бүтцэд ижил асуудал гарахгүй байхыг баталгаажуулдаг. өөрийн хүчин чадал.
GitLab-д алдаа эсвэл эмзэг байдлыг зассан гэж тэмдэглэгдсэний дараа хувилбарын менежер үүнийг суулгацын хамт хэрэглэгчдэд зориулсан засварууд эсвэл аюулгүй байдлын шинэчлэлтүүдэд оруулах болно гэдгийг үнэлэх ёстой. Хэрэв тэр алдаа эсвэл эмзэг байдлыг шинэчлэх шаардлагатай гэж үзвэл бэлтгэл ажил эхэлнэ.
Хувилбарын менежер нь засвар бэлтгэх эсэх, эсвэл хэзээ ашиглахаа шийдэх ёстой бөгөөд энэ нь нөхцөл байдлын нөхцөл байдлаас ихээхэн хамаарна "Энэ хооронд машинууд хүмүүс шиг нөхцөл байдлыг удирдахдаа тийм ч сайн байдаггүй"гэж Марин хэлэв.
Энэ бүхэн засварын тухай юм
Засвар гэж юу вэ, бидэнд яагаад хэрэгтэй вэ?
Хувилбарын менежер алдааны ноцтой байдалд үндэслэн засварыг гаргах эсэхийг шийддэг.
Алдаа нь ноцтой байдлаас хамааран өөр өөр байдаг. Тиймээс S4 эсвэл S3 алдаа нь пиксел эсвэл дүрсний шилжилт гэх мэт стилист байж болно. Энэ нь тийм ч чухал биш боловч хэн нэгний ажлын урсгалд мэдэгдэхүйц нөлөө үзүүлэхгүй бөгөөд энэ нь ийм S3 эсвэл S4 алдааг засах магадлал бага байна гэж Марин тайлбарлав.
Гэсэн хэдий ч S1 эсвэл S2 эмзэг байдал нь хэрэглэгч хамгийн сүүлийн үеийн хувилбар руу шинэчлэх ёсгүй, эсвэл хэрэглэгчийн ажлын урсгалд нөлөөлж буй томоохон алдаа байна гэсэн үг юм. Хэрэв тэдгээрийг трекерт оруулсан бол олон хэрэглэгчид тэдэнтэй тулгарсан тул хувилбарын менежер тэр даруй засварыг бэлдэж эхэлдэг.
S1 эсвэл S2 эмзэг байдлын нөхөөс бэлэн болмогц хувилбарын менежер нөхөөсийг гаргаж эхэлнэ.
Жишээлбэл, GitLab 12.10.1 засварыг блоклосон хэд хэдэн асуудлыг илрүүлж, хөгжүүлэгчид үүсгэж буй үндсэн асуудлыг зассаны дараа бүтээсэн. Хувилбарын менежер өгөгдсөн хүндийн түвшний зөв эсэхийг үнэлж, баталгаажуулсны дараа блоклох асуудал илэрсэнээс хойш XNUMX цагийн дотор бэлэн болсон засварыг гаргах үйл явцыг эхлүүлсэн.
Маш олон S4, S3, S2 хуримтлагдах үед хувилбарын менежер тухайн засварыг яаралтай гаргах шаардлагатайг тодорхойлохын тулд контекстийг хардаг бөгөөд тэдгээрийн тодорхой тоонд хүрсэн үед бүгдийг нэгтгэж, гаргадаг. Гаргасны дараах засварууд эсвэл аюулгүй байдлын шинэчлэлтүүдийг блог нийтлэлд нэгтгэн харуулав.
Хувилбарын менежер хэрхэн засваруудыг үүсгэдэг
Бид засваруудыг үүсгэхийн тулд GitLab CI болон ChatOps зэрэг бусад функцуудыг ашигладаг. Хувилбарын менежер нь манай дотоод суваг дээрх ChatOps багийг идэвхжүүлснээр засварын хувилбарыг эхлүүлнэ #releases Slack-д.
/chatops run release prepare 12.10.1ChatOps нь өөр өөр үйл явдлуудыг өдөөх зорилгоор Slack дотор ажилладаг бөгөөд дараа нь GitLab боловсруулж, гүйцэтгэдэг. Жишээлбэл, хүргэлтийн баг засваруудыг гаргахын тулд янз бүрийн зүйлийг автоматжуулах зорилгоор ChatOps-ийг суулгасан.
Хувилбарын менежер ChatOps багийг Slack-д ажиллуулсны дараа бусад ажил нь CICD ашиглан GitLab дээр автоматаар хийгдэнэ. Хувилбарын менежер нь процессын зарим гол алхмуудыг идэвхжүүлдэг тул суллах явцад ChatOps in Slack болон GitLab хооронд хоёр талын харилцаа холбоо байдаг.
Доорх видео нь GitLab-д зориулж нөхөөс бэлтгэх техникийн үйл явцыг харуулж байна.
gitlab.com дээр автомат байршуулалт хэрхэн ажилладаг талаар
Gitlab.com-г шинэчлэхэд ашигладаг процесс болон хэрэгслүүд нь засваруудыг үүсгэхэд ашигладагтай төстэй. gitlab.com-ийг шинэчлэхэд хувилбарын менежерийн үүднээс авч үзвэл гар ажиллагаа бага шаарддаг.
ChatOps ашиглан байршуулалтыг ажиллуулахын оронд бид CI функцуудыг ашигладаг, жишээ нь. , үүний тусламжтайгаар хувилбарын менежер шаардлагатай цагт гүйцэтгэх тодорхой үйлдлүүдийг төлөвлөх боломжтой. Гарын авлагын процессын оронд GitLab төслүүдэд хийсэн шинэ өөрчлөлтүүдийг татаж авч, багцалж, байршуулах хуваарийг тохируулан, автоматаар туршилт, QA болон бусад шаардлагатай алхмуудыг гүйцэтгэдэг цаг тутамд нэг удаа ажилладаг дамжуулах хоолой байдаг.
"Тиймээс бид gitlab.com-оос өмнө өөр өөр орчинд олон тооны байршуулалтуудыг ажиллуулж байгаа бөгөөд тэдгээр орчин сайн төлөвт орж, туршилт сайн үр дүн гарсны дараа хувилбарын менежер gitlab.com-ийг байршуулах үйлдлүүдийг эхлүүлдэг" гэж Марин хэлэв.
Gitlab.com-ын шинэчлэлтийг дэмжих CICD технологи нь хувилбарын менежер нь үйлдвэрлэлийн орчныг gitlab.com-д байршуулах ажлыг гараар эхлүүлэх хүртэл бүх процессыг автоматжуулдаг.
Марин доорх видеон дээр gitlab.com-ийн шинэчлэлтийн үйл явцын талаар дэлгэрэнгүй тайлбарласан.
Хүргэлтийн баг өөр юу хийдэг вэ?
Gitlab.com-ийн шинэчлэлтийн процессууд болон засваруудыг дотооддоо хэрэглэгчдэд хүргэх хоёрын гол ялгаа нь сүүлийн процесс нь хувилбарын менежерээс илүү их цаг хугацаа, илүү их гар ажиллагаа шаарддаг явдал юм.
Марин хэлэхдээ: "Бид заримдаа мэдээлсэн асуудал, багаж хэрэгслийн асуудал, нэг засварыг гаргахдаа анхаарах ёстой олон нюансуудаас шалтгаалж хэрэглэгчдэд засваруудыг суулгаж өгөхийг хойшлуулдаг."
Хүргэлтийн багийн богино хугацааны зорилтуудын нэг бол хувилбарыг түргэсгэхийн тулд хувилбарын менежерийн гар ажиллагаатай ажлын хэмжээг багасгах явдал юм. Баг нь суллах үйл явцыг хялбарчлах, оновчтой болгох, автоматжуулахаар ажиллаж байгаа бөгөөд энэ нь бага зэргийн ноцтой асуудлуудыг (S3 ба S4, ойролцоогоор. орчуулагч). Хурд дээр анхаарлаа төвлөрүүлэх нь гүйцэтгэлийн гол үзүүлэлт юм: MTTP-ийг нэгтгэх хүсэлтийг хүлээн авснаас хойш үр дүнг gitlab.com-д байршуулах хүртэлх хугацааг одоогийн 50 цагаас 8 цаг хүртэл бууруулах шаардлагатай.
Хүргэлтийн баг нь gitlab.com сайтыг Kubernetes-д суурилсан дэд бүтэц рүү шилжүүлэхээр ажиллаж байна.
Редакторын NB: Хэрэв та Kubernetes технологийн талаар аль хэдийн сонссон (мөн танд байгаа гэдэгт эргэлзэхгүй байна), гэхдээ гараараа хүрч амжаагүй байгаа бол онлайн эрчимжүүлсэн сургалтанд хамрагдахыг зөвлөж байна. , 28-р сарын 30-XNUMX-нд болох ба 14-р сарын 16-XNUMX-нд болно. Энэ нь танд итгэлтэйгээр жолоодож, технологитой ажиллах боломжийг олгоно.
Эдгээр нь ижил зорилготой хоёр арга юм: gitlab.com болон тэдний байгууламж дахь үйлчлүүлэгчдэд зориулсан шинэчлэлтүүдийг хурдан хүргэх.
Бидний хувьд ямар нэгэн санаа, зөвлөмж байна уу?
Хүн бүр GitLab-д хувь нэмрээ оруулахыг урьж байна, бид уншигчдынхаа санал хүсэлтийг хүлээн авна уу. Хэрэв танд манай хүргэлтийн багт ямар нэгэн санаа байгаа бол бүү эргэлз мэдэгдлийн хамт team: Delivery.
Эх сурвалж: www.habr.com