Бид чадах чинээгээрээ DevOps-ийг хөгжүүлсэн. Бид 8 хүн байсан бөгөөд Вася Windows дээр хамгийн дажгүй нь байсан. Гэнэт Вася явахад надад Windows хөгжүүлэлтийн нийлүүлсэн шинэ төслийг эхлүүлэх даалгавар ирлээ. Би Windows-ийн хөгжүүлэлтийн стекийг бүхэлд нь ширээн дээр хаяхдаа нөхцөл байдал үнэхээр хэцүү байгааг ойлгосон ...
Түүх ингэж эхэлдэг Александра Синчинова тухай . Windows-ийн тэргүүлэх мэргэжилтэн компанийг орхиход Александр одоо юу хийхээ гайхаж байв. Мэдээжийн хэрэг, Линукс руу шилжих! Александр 100 эцсийн хэрэглэгчдэд зориулсан дууссан төслийн жишээг ашиглан Windows-ийн хөгжүүлэлтийн нэг хэсгийг Линукс руу хэрхэн шилжүүлж чадсанаа танд хэлэх болно.
Хэрхэн TFS, Puppet, Linux .NET core ашиглан төслийг RPM-д хялбар, хүндрэлгүйгээр хүргэх вэ? Хэрэв хөгжүүлэлтийн баг Postgres болон Flyway гэсэн үгсийг анх удаа сонссон бөгөөд эцсийн хугацаа нь маргааш болвол төслийн мэдээллийн сангийн хувилбарыг хэрхэн дэмжих вэ? Docker-тэй хэрхэн нэгтгэх вэ? .NET хөгжүүлэгчдэд Windows болон смүүтиг орхиж, Хүүхэлдэй болон Линуксийг дэмжихэд хэрхэн түлхэц өгөх вэ? Хэрэв Windows-ийг үйлдвэрлэхэд хүч чадал, хүсэл эрмэлзэл, нөөц байхгүй бол үзэл суртлын зөрчлийг хэрхэн шийдвэрлэх вэ? Энэ тухай, мөн Вэб байршуулах, турших, CI, одоо байгаа төслүүдэд TFS ашиглах туршлага, мэдээжийн хэрэг эвдэрсэн суга таяг, ажлын шийдлүүдийн талаар Александрын тайлангийн хуулбарын талаар.
Тиймээс, Вася явлаа, даалгавар над дээр байна, хөгжүүлэгчид сэрээтэй тэвчээргүй хүлээж байна. Эцэст нь Васяг буцааж өгөх боломжгүйг мэдээд би ажилдаа оров. Эхлэхийн тулд би манай флот дахь Win VM-ийн хувийг үнэлсэн. Оноо Windows-ийн талд байсангүй.
Бид DevOps-ийг идэвхтэй хөгжүүлж байгаа тул шинэ програм хүргэх арга барилд ямар нэг зүйлийг өөрчлөх шаардлагатай гэдгийг би ойлгосон. Зөвхөн нэг шийдэл байсан - боломжтой бол бүх зүйлийг Линукс руу шилжүүлээрэй. Google надад тусалсан - тэр үед .Net аль хэдийн Линукс руу шилжсэн байсан бөгөөд энэ бол шийдэл гэдгийг би ойлгосон!
Яагаад .NET цөмийг Линукстэй хослуулсан бэ?
Үүнд хэд хэдэн шалтгаан байсан. "Мөнгө төлөх" болон "төлөхгүй" хоёрын хооронд олонхи нь над шиг хоёр дахьыг сонгох болно. MSDB-ийн лиценз нь ойролцоогоор 1 долларын үнэтэй; Windows виртуал машинуудын флотыг хадгалахад хэдэн зуун долларын үнэтэй байдаг. Том компанийн хувьд энэ бол маш их зардал юм. Тийм ч учраас хэмнэлт - эхний шалтгаан. Хамгийн чухал нь биш, гэхдээ хамгийн чухал зүйлүүдийн нэг.
Windows виртуал машинууд нь Линуксийн ах дүү нараас илүү их нөөцийг ашигладаг. тэд хүнд байна. Томоохон компанийн цар хүрээг харгалзан бид Линуксийг сонгосон.
Энэ систем нь одоо байгаа CI-д энгийн байдлаар нэгдсэн. Бид өөрсдийгөө дэвшилтэт DevOps гэж үздэг, бид Bamboo, Jenkins, GitLab CI ашигладаг тул бидний ихэнх ажил Линукс дээр ажилладаг.
Сүүлийн шалтгаан нь тохиромжтой дагалдах хэрэгсэл. Техникийн хэсгийг ойлгодог, тасралтгүй үйлчилгээгээр хангадаг, хоёр дахь шугамаас үйлчилгээ үзүүлдэг залуус болох "дагалдан яваа хүмүүс"-д орох саадыг багасгах хэрэгтэй байв. Тэд Линуксийн стекийг аль хэдийн мэддэг байсан тул Windows платформд зориулсан програм хангамжийн ижил функцийг ойлгохын тулд нэмэлт нөөц зарцуулахаас илүү шинэ бүтээгдэхүүнийг ойлгох, дэмжих, хадгалах нь тэдэнд илүү хялбар байдаг.
шаардлага
Юуны түрүүнд - хөгжүүлэгчдэд зориулсан шинэ шийдлийн тав тухтай байдал. Тэд бүгд өөрчлөлтөд бэлэн биш байсан, ялангуяа Линукс гэдэг үгийг хэлсний дараа. Хөгжүүлэгчид өөрсдийн дуртай Visual Studio TFS-г угсралт болон смүүтид зориулсан автомат тесттэй байхыг хүсдэг. Үйлдвэрлэлд хүргэх нь тэдний хувьд чухал биш юм. Тиймээс бид ердийн процессыг өөрчлөхгүй байхаар шийдсэн бөгөөд Windows хөгжүүлэлтийн хувьд бүх зүйлийг өөрчлөхгүй байхаар шийдсэн.
Шинэ төсөл хэрэгтэй байна одоо байгаа CI-д нэгтгэх. Төмөр зам аль хэдийн тэнд байсан бөгөөд тохиргооны удирдлагын систем, хүлээн зөвшөөрөгдсөн хүргэлтийн стандарт, хяналтын системийн параметрүүдийг харгалзан бүх ажлыг хийх ёстой байв.
Дэмжлэг, үйл ажиллагааны хялбар байдал, өөр өөр хэлтэс болон туслах хэлтсийн бүх шинэ оролцогчдын элсэлтийн хамгийн бага босго байх нөхцөл болгон.
Эцсийн хугацаа - өчигдөр.
Win Development Group
Тэр үед Windows-ын баг юутай ажиллаж байсан бэ?
Одоо би үүнийг итгэлтэйгээр хэлж чадна IdentityServer4 Энэ нь ижил төстэй чадвартай ADFS-ийн үнэгүй хувилбар юм Entity Framework Core - хөгжүүлэгчийн хувьд диваажин бөгөөд та SQL скрипт бичихэд төвөг удах шаардлагагүй, харин мэдээллийн санд байгаа асуулгыг OOP хэллэгээр тайлбарлах болно. Харин дараа нь, үйл ажиллагааны төлөвлөгөөг хэлэлцэх үеэр би энэ стекийг зөвхөн PostgreSQL болон Git-ийг таних Шумерын дөрвөлжин бичиг мэт харав.
Тэр үед бид идэвхтэй ашиглаж байсан Тоглоом тохиргооны удирдлагын систем болгон. Ихэнх төслүүддээ бид ашигласан GitLab CI, Мэдрэмжтэй, тэнцвэртэй өндөр ачаалалтай үйлчилгээг ашиглан HAProxy бүх зүйлийг хянаж байсан Заббик, шөрмөс Графана и Prometheus, Jeger, энэ бүхэн төмрийн хэсгүүд дээр эргэлдэж байв HP c ESXi тухай VMware. Хүн бүр үүнийг мэддэг - энэ төрлийн сонгодог.
Эдгээр бүх хөндлөнгийн оролцоог эхлүүлэхээсээ өмнө юу болсныг харж, ойлгохыг хичээцгээе.
Юу болов
TFS бол хөгжүүлэгчээс эцсийн үйлдвэрлэлийн машин руу кодыг хүргэдэг нэлээд хүчирхэг систем бөгөөд янз бүрийн үйлчилгээтэй маш уян хатан нэгтгэх цогц систем юм - платформ хоорондын түвшинд CI-ийг хангах.
Өмнө нь эдгээр нь хатуу цонхнууд байсан. TFS нь олон төслийг угсрахад ашигласан хэд хэдэн Build agent ашигласан. Агент бүр даалгавруудыг зэрэгцүүлж, үйл явцыг оновчтой болгохын тулд 3-4 ажилтантай байдаг. Дараа нь, хувилбарын төлөвлөгөөний дагуу TFS шинэхэн шатаасан Build-ийг Windows програмын серверт хүргэв.
Бид юунд хүрэхийг хүссэн бэ?
Бид хүргэх, хөгжүүлэхэд TFS ашигладаг бөгөөд Линукс Програмын сервер дээр програмыг ажиллуулдаг бөгөөд тэдгээрийн хооронд ямар нэгэн ид шид байдаг. Энэ Шидэт хайрцаг Цаашид ажлын давс байна. Үүнийг салгахаасаа өмнө би нэг алхам хойшилж, хэрэглээний талаар хэдэн үг хэлье.
Төсөл
Уг програм нь урьдчилсан төлбөрт карттай ажиллах боломжийг олгодог.
Клиент
Хоёр төрлийн хэрэглэгчид байсан. Эхнийх нь SSL SHA-2 сертификатыг ашиглан нэвтэрснээр хандалт авсан. У хоёрдугаарт нэвтрэх болон нууц үг ашиглан нэвтрэх боломжтой байсан.
HAProxy
Дараа нь үйлчлүүлэгчийн хүсэлт HAProxy-д очсон бөгөөд энэ нь дараах асуудлуудыг шийдсэн.
- анхан шатны зөвшөөрөл;
- SSL цуцлалт;
- HTTP хүсэлтийг тааруулах;
- өргөн нэвтрүүлгийн хүсэлтүүд.
Үйлчлүүлэгчийн гэрчилгээг гинжин хэлхээний дагуу баталгаажуулсан. Бид - эрх бүхий байгууллага Бид өөрсдөө үйлчилгээний үйлчлүүлэгчдэд гэрчилгээ олгодог тул бид үүнийг төлж чадна.
Гурав дахь зүйлд анхаарлаа хандуулаарай, бид үүнийг хэсэг хугацааны дараа эргэн харах болно.
Арын арын хэсэг
Тэд Линукс дээр backend хийхээр төлөвлөж байсан. Backend нь өгөгдлийн сантай харилцаж, шаардлагатай давуу эрхийн жагсаалтыг ачаалж, дараа нь эрх бүхий хэрэглэгч ямар давуу эрхтэй байгаагаас хамааран санхүүгийн баримт бичигт гарын үсэг зурах, гүйцэтгэхэд илгээх, эсвэл ямар нэгэн тайлан гаргах боломжийг олгодог.
HAProxy ашиглан хэмнэлт хийх
Үйлчлүүлэгч бүрийн чиглүүлж байсан хоёр контекстээс гадна таних контекст бас байсан. IdentityServer4 зүгээр л нэвтрэх боломжийг олгодог, энэ нь үнэгүй бөгөөд хүчирхэг аналог юм ADFS - Active Directory холбооны үйлчилгээ.
Иргэний үнэмлэхний хүсэлтийг хэд хэдэн үе шаттайгаар боловсруулсан. Эхний алхам - үйлчлүүлэгч арын хэсэгт орлоо, энэ сервертэй холбогдож, үйлчлүүлэгчийн токен байгаа эсэхийг шалгасан. Хэрэв энэ нь олдоогүй бол хүсэлтийг буцаж ирсэн контекст руу буцаасан боловч дахин чиглүүлэлттэй бөгөөд дахин чиглүүлэлтийн хамт таних тэмдэг рүү очсон.
Хоёр дахь алхам - хүсэлтийг хүлээн авлаа IdentityServer дахь зөвшөөрлийн хуудас руу, Үйлчлүүлэгч хаана бүртгүүлсэн бөгөөд удаан хүлээсэн токен нь IdentityServer мэдээллийн санд гарч ирэв.
Гурав дахь алхам - үйлчлүүлэгчийг буцааж чиглүүлсэн үүссэн нөхцөл байдалд.
IdentityServer4 нь дараах онцлогтой. Энэ нь буцах хүсэлтийн хариуг HTTP-ээр дамжуулан буцаана. Бид серверээ тохируулах гэж хэчнээн их тэмцэж байсан ч, бид бичиг баримтын талаар хэчнээн гэгээрсэн ч гэсэн HTTPS-ээр дамжуулан ирсэн URL-тай үйлчлүүлэгчийн анхны хүсэлтийг хүлээн авах бүртээ IdentityServer ижил контекстийг буцаадаг, гэхдээ HTTP-тэй. Бид цочирдсон! Бид энэ бүгдийг таних контекстээр дамжуулан HAProxy руу шилжүүлсэн бөгөөд толгой хэсэгт HTTP протоколыг HTTPS болгон өөрчлөх шаардлагатай болсон.
Сайжруулалт нь юу вэ, хаана хадгалсан бэ?
Бид IdentityServer4-ийг тусдаа сегментэд тусдаа зангилаа болгон байрлуулаагүй, харин програмын арын хэсэг ажилладаг нэг сервер дээрх backend-тэй хамт ашигласан тул бид бүлэг хэрэглэгчдэд зөвшөөрөл олгох үнэгүй шийдлийг ашиглан мөнгө хэмнэсэн. .
Энэ нь хэрхэн ажиллах ёстой
Тиймээс, миний амласан ёсоор - Шидэт хайрцаг. Бид Линукс руу шилжих баталгаатай гэдгээ аль хэдийн ойлгосон. Шийдэл шаардлагатай тодорхой ажлуудыг томъёолъё.
Хүүхэлдэйн илэрхийлэл. Үйлчилгээ болон хэрэглээний тохиргоог хүргэх, удирдахын тулд гайхалтай жор бичих шаардлагатай байв. Нэг өнхрөх харандаа нь үүнийг хэр хурдан, үр дүнтэй хийснийг уран яруу харуулж байна.
Хүргэлтийн арга. Стандарт нь RPM юм. Линукс дээр үүнгүйгээр хийх боломжгүй гэдгийг бүгд ойлгодог, гэхдээ уг төсөл нь угсралтын дараа гүйцэтгэгдэх DLL файлуудын багц байсан. Тэдний 150 орчим нь байсан, төсөл нь нэлээд хэцүү байсан. Цорын ганц эв нэгдэлтэй шийдэл бол энэ хоёртын файлыг RPM болгон багцалж, үүнээс програмыг байрлуулах явдал юм.
Хувилбар хийх. Бид маш олон удаа гаргах шаардлагатай байсан бөгөөд бид багцын нэрийг хэрхэн бүрдүүлэхээ шийдэх ёстой байв. Энэ бол TFS-тэй интеграцчлалын түвшинтэй холбоотой асуудал юм. Бидэнд Линукс дээр бүтээх агент байсан. TFS нь боловсруулагч-ажилчин руу даалгаврыг Build агент руу илгээхдээ түүнд зохицуулагч процессын орчинд дуусдаг олон тооны хувьсагчдыг дамжуулдаг. Эдгээр орчны хувьсагч нь Build нэр, хувилбарын нэр болон бусад хувьсагчдыг агуулна. Энэ талаар "RPM багц бүтээх" хэсгээс дэлгэрэнгүй уншина уу.
TFS-г тохируулж байна Pipeline байгуулахаар ирсэн. Өмнө нь бид Windows-ийн бүх төслүүдийг Windows агентууд дээр цуглуулдаг байсан бол одоо Линукс агент гарч ирж байна. Энэ нь бүтээх бүлэгт багтах, зарим олдворуудаар баяжуулах, энэ Build агент дээр ямар төрлийн төслүүдийг бүтээхийг зааж өгөх шаардлагатай. , ямар нэгэн байдлаар дамжуулах хоолойг өөрчлөх.
IdentityServer. ADFS бол бидний арга биш, бид Нээлттэй эхийн төлөө явж байна.
Бүрэлдэхүүн хэсгүүдийг нь авч үзье.
Шидэт хайрцаг
Дөрвөн хэсгээс бүрдэнэ.
Linux Build агент. Линукс, учир нь бид үүнд зориулж бүтээдэг - энэ нь логик юм. Энэ хэсгийг гурван үе шаттайгаар хийсэн.
- Ажилчдыг тохируулах төсөл дээр хуваарилагдсан ажил хүлээгдэж байсан тул ганцаараа биш.
- .NET Core 1.x суулгана уу. Стандарт репозиторт 1 бэлэн байхад яагаад 2.0.x гэж? Учир нь хөгжүүлж эхлэхэд тогтвортой хувилбар нь 1.09 байсан бөгөөд түүн дээр тулгуурлан төслөө хийхээр болсон.
- Git 2.x.
RPM-репозитор. RPM багцуудыг хаа нэг газар хадгалах шаардлагатай байв. Бид бүх Linux хостуудад ашиглах боломжтой ижил корпорацийн RPM агуулахыг ашиглах болно гэж таамаглаж байсан. Тэд ийм зүйл хийсэн. Хадгалах серверийг тохируулсан вэб дэгээ шаардлагатай RPM багцыг заасан байршлаас татаж авсан. Багцын хувилбарыг Build agent webhook-д мэдээлсэн.
GitLab. Анхаар! Энд байгаа GitLab-ийг хөгжүүлэгчид биш, харин үйлдлийн хэлтэс нь програмын хувилбарууд, багцын хувилбаруудыг хянах, бүх Линукс машинуудын статусыг хянах, жорыг хадгалахад ашигладаг - бүх Хүүхэлдэйн манифест.
Тоглоом - бүх маргаантай асуудлыг шийдэж, Gitlab-аас бидний хүссэн тохиргоог яг таг хүргэж өгдөг.
Бид шумбаж эхэлдэг. RPM руу DLL хүргэлт хэрхэн ажилладаг вэ?
DDL-ийг RPM хүртэл хүргэх
Бидэнд .NET хөгжүүлэлтийн рок од байна гэж бодъё. Энэ нь Visual Studio ашигладаг бөгөөд хувилбарын салбар үүсгэдэг. Үүний дараа үүнийг Git-д байршуулдаг бөгөөд Git нь TFS байгууллага, өөрөөр хэлбэл хөгжүүлэгчийн хамтран ажилладаг програмын репозитор юм.
Үүний дараа TFS шинэ үүрэг ирсэнийг хардаг. Аль апп? TFS тохиргоонд тухайн Build агент ямар нөөцтэй болохыг харуулсан шошго байдаг. Энэ тохиолдолд тэр биднийг .NET Core төсөл барьж байгааг хараад Linux Build агентыг сангаас сонгоно.
Build agent эх сурвалжийг хүлээн авч, шаардлагатай зүйлсийг татаж авдаг хамаарал .NET репозитороос, npm гэх мэт. мөн програмыг өөрөө болон дараагийн багцыг бүтээсний дараа RPM багцыг RPM репозитор руу илгээдэг.
Нөгөө талаар дараахь зүйл тохиолддог. Үйл ажиллагааны хэлтсийн инженер нь төслийг хэрэгжүүлэхэд шууд оролцдог: тэр багцын хувилбаруудыг өөрчилдөг Хиера програмын жор хадгалагдаж байгаа агуулахад, үүний дараа Хүүхэлдэй гох Yum, репозитороос шинэ багцыг татаж аваад програмын шинэ хувилбарыг ашиглахад бэлэн боллоо.
Бүх зүйл үгээр энгийн боловч Build agent дотор юу болдог вэ?
DLL RPM багц
TFS-ээс төслийн эх сурвалж болон бүтээх ажлыг хүлээн авсан. Агент бүтээх эх үүсвэрээс төслийг өөрөө барьж эхэлдэг. Угсарсан төслийг иж бүрдэл хэлбэрээр авах боломжтой DLL файлууд, файлын системийн ачааллыг багасгах зорилгоор зип архивт багцалсан.
ZIP архивыг хаясан RPM багц бүтээх лавлах руу. Дараа нь Bash скрипт нь орчны хувьсагчдыг эхлүүлж, Build хувилбар, төслийн хувилбар, бүтээх лавлах замыг олж, RPM-build-ийг ажиллуулдаг. Барилга дууссаны дараа багцыг нийтлэнэ орон нутгийн репозитор, Build agent дээр байрладаг.
Дараа нь Build агентаас RPM репозитор дахь сервер рүү JSON хүсэлтийг илгээсэн хувилбар болон бүтээх нэрийг зааж өгнө. Өмнө нь ярьсан Webhook нь Build agent дээрх локал репозитороос яг энэ багцыг татаж аваад шинэ угсралтыг суулгах боломжтой болгодог.
Яагаад энэ багцыг RPM репозитор руу хүргэх схем байгаа юм бэ? Яагаад би угсарсан багцыг хадгалах газар руу шууд илгээж болохгүй гэж? Үнэн хэрэгтээ энэ нь аюулгүй байдлыг хангах нөхцөл юм. Энэ хувилбар нь зөвшөөрөлгүй хүмүүс RPM багцуудыг бүх Линукс машинуудад хандах боломжтой серверт байршуулах боломжийг хязгаарладаг.
Өгөгдлийн сангийн хувилбар
Хөгжүүлэгчийн багтай зөвлөлдсөний дараа залуус MS SQL-тэй илүү ойр байсан нь тогтоогдсон ч Windows бус ихэнх төслүүдэд бид PostgreSQL-ийг бүх хүч чадлаараа ашиглаж байсан. Бид төлбөртэй бүх зүйлээ орхихоор шийдсэн тул PostgreSQL-г энд бас ашиглаж эхэлсэн.
Энэ хэсэгт би өгөгдлийн санг хэрхэн хувилбарласан, Flyway болон Entity Framework Core хоёрын хооронд хэрхэн сонголт хийснээ хэлэхийг хүсч байна. Тэдний давуу болон сул талуудыг харцгаая.
Минусы
Flyway зөвхөн нэг л замаар явдаг, бид бид буцах боломжгүй - Энэ бол мэдэгдэхүйц сул тал юм. Та үүнийг Entity Framework Core-тэй бусад аргаар харьцуулж болно - хөгжүүлэгчийн тав тухтай байдлын хувьд. Бид үүнийг тэргүүн эгнээнд тавьсан бөгөөд гол шалгуур нь Windows хөгжүүлэлтийн хувьд юу ч өөрчлөхгүй байх явдал байсныг та санаж байна.
Flyway бидний хувьд ямар нэг төрлийн боодол хэрэгтэй байсанзалуус бичихгүйн тулд SQL асуулга. Тэд OOP нөхцөлөөр ажиллахад илүү ойр байдаг. Бид өгөгдлийн сангийн объектуудтай ажиллах зааврыг бичиж, SQL query үүсгэж, гүйцэтгэсэн. Мэдээллийн сангийн шинэ хувилбар бэлэн, туршиж үзсэн - бүх зүйл хэвийн, бүх зүйл ажилладаг.
Entity Framework Core нь сул талтай - хүнд ачааллын үед оновчтой бус SQL асуулга үүсгэдэг, мөн мэдээллийн сан дахь бууралт нь ихээхэн ач холбогдолтой байж болно. Гэхдээ манайд ачаалал ихтэй үйлчилгээ байхгүй учраас хэдэн зуун RPS-ээр ачааллаа тооцдоггүй тул эдгээр эрсдэлийг хүлээн зөвшөөрч, асуудлыг ирээдүйд хариуцуулсан.
Плюсы
Entity Framework Core хайрцагнаас гарч ажиллах бөгөөд боловсруулахад хялбар, болон Flyway Одоо байгаа CI-д хялбархан нэгтгэгдэнэ. Гэхдээ бид үүнийг хөгжүүлэгчдэд тохиромжтой болгодог :)
Өнхрөх журам
Хүүхэлдэй нь шилжилт хөдөлгөөнийг хариуцдаг багц хувилбарт өөрчлөлт орж байгааг харж байна. Нэгдүгээрт, энэ нь шилжих скриптүүд болон мэдээллийн сантай холбоотой функцуудыг агуулсан багцыг суулгадаг. Үүний дараа мэдээллийн сантай ажилладаг програм дахин ачаалагдана. Дараа нь үлдсэн бүрэлдэхүүн хэсгүүдийг суурилуулах ажил эхэлнэ. Багцуудыг суулгаж, програмуудыг эхлүүлэх дарааллыг Хүүхэлдэйн манифест дээр тайлбарласан болно.
Програмууд нь жетон, өгөгдлийн сангийн нууц үг гэх мэт эмзэг өгөгдлийг ашигладаг бөгөөд энэ бүгдийг Хүүхэлдэйн мастераас тохиргоонд татаж, шифрлэгдсэн хэлбэрээр хадгалдаг.
TFS-ийн асуудлууд
Бид шийдэж, бүх зүйл бидний төлөө ажиллаж байгааг ойлгосны дараа би TFS дахь Win хөгжүүлэлтийн хэлтэст зориулж бусад төслүүд дээр юу болж байгааг харахаар шийдсэн - бид хурдан барьж байна уу, үгүй юу, мөн. хурдтай холбоотой томоохон асуудлуудыг илрүүлсэн.
Гол төслүүдийн нэгийг угсрахад 12-15 минут шаардагддаг - энэ бол урт хугацаа, та ингэж амьдарч чадахгүй. Шуурхай дүн шинжилгээ нь I/O-д аймшигтай бууралтыг харуулсан бөгөөд энэ нь массив дээр байсан.
Үүнийг бүрэлдэхүүн хэсгүүдээр нь шинжилсний дараа би гурван голомтыг тодорхойлсон. Эхлээд - "Касперскийн антивирус", энэ нь бүх Windows Build агентууд дээрх эх сурвалжийг сканнердаж байна. Хоёрдугаарт - Windows Индексжүүлэгч. Үүнийг идэвхгүй болгоогүй бөгөөд байршуулах явцад бүх зүйлийг Build agents дээр бодит цаг хугацаанд нь индексжүүлсэн.
Гуравдугаарт - Npm суулгах. Ихэнх Дамжуулах хоолойд бид яг ийм хувилбарыг ашигласан нь тогтоогдсон. Тэр яагаад муу юм бэ? Npm суулгах процедур нь хамаарлын мод үүсэх үед ажиллана package-lock.json, төслийг бүтээхэд хэрэглэгдэх багцуудын хувилбаруудыг бүртгэнэ. Сул тал нь Npm install нь багцын хамгийн сүүлийн хувилбарыг интернетээс авах бүртээ татаж авдаг бөгөөд томоохон төслийн хувьд энэ нь маш их цаг зарцуулдаг.
Хөгжүүлэгчид заримдаа тухайн хэсэг эсвэл бүхэлдээ төсөл хэрхэн ажилладагийг шалгахын тулд орон нутгийн машин дээр туршилт хийдэг. Заримдаа орон нутагт бүх зүйл сайхан байсан ч тэд үүнийг угсарч, өнхрүүлж, юу ч хийсэнгүй. Бид асуудал юу болохыг олж харж эхэлдэг - тийм ээ, хамаарал бүхий багцуудын өөр өөр хувилбарууд.
шийдвэр
- AV-н үл хамаарах эх сурвалжууд.
- Индексжүүлэхийг идэвхгүй болгох.
- Руу явах npm ci.
npm ci-ийн давуу тал нь бид Бид хараат байдлын модыг нэг удаа цуглуулдаг, мөн бид хөгжүүлэгчийг хангах боломжийг олж авдаг одоогийн багцуудын жагсаалт, үүнтэй тэрээр хүссэнээрээ орон нутагт туршилт хийх боломжтой. Энэ цаг хэмнэдэг код бичдэг хөгжүүлэгчид.
Тохиргоо
Одоо хадгалах сангийн тохиргооны талаар бага зэрэг. Түүхийн хувьд бид ашигладаг Nexus агуулахыг удирдахад зориулагдсан, үүнд Дотоод РЕПО. Энэхүү дотоод репозитор нь бидний дотоод зорилгоор ашигладаг бүх бүрэлдэхүүн хэсгүүдийг агуулдаг, тухайлбал, өөрөө бичсэн хяналт.
Бид ч бас ашигладаг NuGet, учир нь энэ нь бусад багц менежерүүдтэй харьцуулахад илүү сайн кэштэй.
үр дүн
Бид бүтээх агентуудыг оновчтой болгосны дараа бүтээх дундаж хугацааг 12 минутаас 7 болгон бууруулсан.
Хэрэв бид Windows-д ашиглаж болох байсан ч энэ төсөлд Линукс руу шилжсэн бүх машинуудаа тооцвол бид 10 доллар хэмнэсэн. Энэ нь зөвхөн лиценз дээр байгаа бөгөөд агуулгыг нь харгалзан үзвэл илүү их зүйл юм.
Төлөвлөгөө
Ирэх улиралд бид код хүргэх ажлыг оновчтой болгохоор төлөвлөсөн.
Урьдчилан бүтээсэн Docker дүрс рүү шилжиж байна. TFS бол Docker дүрсийг гох дээр суурилсан угсралт гэх мэт Pipeline-д нэгтгэх боломжийг олгодог олон залгаастай гайхалтай зүйл юм. Бид энэ гохыг ижилхэнд зориулж хийхийг хүсч байна package-lock.json. Төслийг бүтээхэд ашигласан бүрэлдэхүүн хэсгүүдийн бүтэц ямар нэг байдлаар өөрчлөгдвөл бид шинэ Docker дүрсийг бүтээнэ. Дараа нь угсарсан програмтай савыг байрлуулахад ашигладаг. Одоо тийм биш байгаа ч бид Кубернетес дэх микро үйлчилгээний архитектурт шилжихээр төлөвлөж байгаа бөгөөд энэ нь манай компанид идэвхтэй хөгжиж, үйлдвэрлэлийн шийдлүүдэд удаан хугацаагаар үйлчилж байна.
Хураангуй
Би хүн бүрийг Windows-ийг хаяхыг уриалж байна, гэхдээ энэ нь яаж хоол хийхээ мэдэхгүй байгаадаа биш юм. Шалтгаан нь ихэнх Opensource шийдлүүд байдаг Линукс стек. чи зүгээр үү нөөцийг хэмнэх. Миний бодлоор ирээдүй нь хүчирхэг нийгэмлэг бүхий Линукс дээрх Нээлттэй эхийн шийдлүүдэд хамаарна.
Александр Сынчиновын илтгэгчийн танилцуулга .
нь мэргэжилтнүүдэд зориулсан хөгжүүлэлт, туршилт, ашиглалтын үйл явцыг нэгтгэх хурал юм. Тийм ч учраас Александрын ярьсан төсөл? хэрэгжиж, ажиллаж байгаа бөгөөд тоглолт болох өдөр хоёр амжилттай хувилбар гарсан. Асаалттай 27-р сарын 28, XNUMX-нд эмч нараас үүнтэй төстэй хэрэг гарах болно. Та одоо ч гэсэн сүүлчийн тэрэг рүү үсэрч болно эсвэл цаг заваа аваарай тасалбар. Сколковод бидэнтэй уулзаарай!
Эх сурвалж: www.habr.com