Rasm:
Hammaga salom! Biz kompaniyaning avtomatlashtirish muhandislarimiz va biz kompaniya mahsulotlarini ishlab chiqishni qo'llab-quvvatlaymiz: ishlab chiquvchilar tomonidan kodlar qatorini topshirishdan tortib, tayyor mahsulotlar va litsenziyalarni yangilash serverlarida nashr etishgacha bo'lgan butun yig'ish quvurini qo'llab-quvvatlaymiz. Bizni norasmiy ravishda DevOps muhandislari deb atashadi. Ushbu maqolada biz dasturiy ta'minot ishlab chiqarish jarayonining texnologik bosqichlari, ularni qanday ko'rishimiz va ularni qanday tasniflashimiz haqida gapirmoqchimiz.
Materialdan siz ko'p mahsulot ishlab chiqarishni muvofiqlashtirishning murakkabligi, texnologik xarita nima ekanligini va u echimlarni soddalashtirish va takrorlashga qanday yordam berishi, ishlab chiqish jarayonining asosiy bosqichlari va bosqichlari, mas'uliyat sohalari qanday ekanligi haqida bilib olasiz. DevOps va kompaniyamizdagi jamoalar o'rtasida.
Chaos va DevOps haqida
Qisqacha aytganda, DevOps kontseptsiyasi ishlab chiqish vositalari va xizmatlarini, shuningdek, ulardan foydalanish bo'yicha metodologiyalar va eng yaxshi amaliyotlarni o'z ichiga oladi. Keling, globalni ajratib ko'rsatamiz цель kompaniyamizda DevOps g'oyalarini amalga oshirishdan: bu mahsulotlarni ishlab chiqarish va texnik xizmat ko'rsatish xarajatlarini miqdoriy ko'rsatkichlarda (odam-soat yoki mashina soatlari, CPU, RAM, Disk va boshqalar) izchil pasaytirishdir. Butun kompaniya darajasida rivojlanishning umumiy xarajatlarini kamaytirishning eng oson va eng aniq usuli tipik ketma-ket vazifalarni bajarish xarajatlarini minimallashtirish ishlab chiqarishning barcha bosqichlarida. Lekin bu bosqichlar nima, ularni umumiy jarayondan qanday ajratish mumkin, ular qanday bosqichlardan iborat?
Kompaniya bitta mahsulotni ishlab chiqsa, hamma narsa ko'proq yoki kamroq aniq: odatda umumiy yo'l xaritasi va rivojlanish sxemasi mavjud. Ammo mahsulot qatori kengayib, ko'proq mahsulot paydo bo'lganda nima qilish kerak? Bir qarashda, ular o'xshash jarayonlar va yig'ish liniyalariga ega va jurnallar va skriptlarda "X farqlarni toping" o'yini boshlanadi. Ammo faol ishlab chiqilayotgan 5+ loyiha mavjud bo'lsa va bir necha yillar davomida ishlab chiqilgan bir nechta versiyalarni qo'llab-quvvatlash kerak bo'lsa-chi? Mahsulot quvurlarida mumkin bo'lgan maksimal miqdordagi echimlarni qayta ishlatishni xohlaymizmi yoki har biri uchun noyob ishlanmaga pul sarflashga tayyormizmi?
O'ziga xoslik va ketma-ket echimlar o'rtasidagi muvozanatni qanday topish mumkin?
Bu savollar bizning oldimizda 2015 yildan beri tez-tez paydo bo'la boshladi. Mahsulotlar soni ko'paydi va biz ushbu mahsulotlarni yig'ish liniyalarini qo'llab-quvvatlaydigan avtomatlashtirish bo'limimizni (DevOps) minimal darajada kengaytirishga harakat qildik. Shu bilan birga, biz mahsulotlar o'rtasida iloji boricha ko'proq echimlarni takrorlashni xohladik. Axir, nima uchun o'nta mahsulotda bir xil narsa turli yo'llar bilan amalga oshiriladi?
Rivojlanish bo'yicha direktor: "Yigitlar, DevOps mahsulotlar uchun nima qilishini qandaydir tarzda baholay olamizmi?"
Biz shundaymiz: "Biz bilmaymiz, biz bunday savol bermadik, lekin qanday ko'rsatkichlarni hisobga olish kerak?"
Rivojlanish bo'yicha direktor: "Kim biladi! O'ylab ko'ring…”
O'sha mashhur filmdagidek: "Men mehmonxonadaman! .." - "Uh ... Menga yo'l ko'rsata olasizmi?" Mulohaza yuritib, biz birinchi navbatda mahsulotning yakuniy holati to'g'risida qaror qabul qilishimiz kerak degan xulosaga keldik; bu bizning birinchi maqsadimizga aylandi.
Shunday qilib, 10 dan 200 kishigacha bo'lgan juda katta jamoalar bilan o'nlab mahsulotni qanday tahlil qilasiz va echimlarni takrorlashda o'lchanadigan ko'rsatkichlarni aniqlaysiz?
1:0 Xaos foydasiga yoki elkama pichoqlaridagi DevOps
Biz BPwin seriyasidan IDEF0 diagrammalari va turli biznes jarayonlar diagrammalarini qo'llashga urinish bilan boshladik. Chalkashlik keyingi loyihaning keyingi bosqichining beshinchi kvadratidan keyin boshlandi va har bir loyiha uchun bu kvadratlarni 50+ qadam ostida uzun pitonning dumiga chizish mumkin. Men xafa bo'ldim va oyga yig'lamoqchi edim - bu umuman mos kelmadi.
Oddiy ishlab chiqarish vazifalari
Ishlab chiqarish jarayonlarini modellashtirish juda murakkab va mashaqqatli ish: siz turli bo'limlar va ishlab chiqarish zanjirlaridan ko'plab ma'lumotlarni to'plashingiz, qayta ishlashingiz va tahlil qilishingiz kerak. Bu haqda ko'proq ma'lumotni maqolada o'qishingiz mumkin "".
Biz ishlab chiqarish jarayonini modellashtirishni boshlaganimizda, bizda aniq maqsad bor edi - kompaniyamiz mahsulotlarini ishlab chiqishda ishtirok etayotgan har bir xodimga va loyiha menejerlariga:
- Mahsulotlar va ularning tarkibiy qismlari kod qatorini kiritishdan boshlab mijozga montajchilar va yangilanishlar ko'rinishida qanday etib borishi;
- mahsulot ishlab chiqarishning har bir bosqichi uchun qanday resurslar ta'minlanadi;
- har bir bosqichda qanday xizmatlar ishtirok etadi,
- har bir bosqich uchun javobgarlik sohalari qanday chegaralanganligi,
- har bir bosqichning kirish va chiqishlarida qanday shartnomalar mavjud.
Rasmni bosish uni to'liq hajmda ochadi.
Kompaniyadagi ishimiz bir nechta funktsional yo'nalishlarga bo'lingan. Infratuzilma yo'nalishi bo'limning barcha "temir" resurslari ishlashini optimallashtirish, shuningdek, virtual mashinalar va ulardagi muhitni joylashtirishni avtomatlashtirish bilan shug'ullanadi. Monitoring yo'nalishi 24/7 xizmat samaradorligini nazorat qilishni ta'minlaydi; biz ishlab chiquvchilar uchun xizmat sifatida monitoringni ham taqdim etamiz. Ish oqimining yo'nalishi guruhlarni ishlab chiqish va sinov jarayonlarini boshqarish, kod holatini tahlil qilish va loyihalar bo'yicha tahlillarni olish uchun vositalar bilan ta'minlaydi. Va nihoyat, webdev yo'nalishi GUS va FLUS yangilanish serverlarida nashrlarni nashr etishni, shuningdek, LicenseLab xizmatidan foydalangan holda mahsulotlarni litsenziyalashni ta'minlaydi. Ishlab chiqarish quvurini qo'llab-quvvatlash uchun biz ishlab chiquvchilar uchun ko'plab turli xil qo'llab-quvvatlash xizmatlarini o'rnatamiz va ularga xizmat ko'rsatamiz (siz ulardan ba'zilari haqidagi hikoyalarni eski uchrashuvlarda tinglashingiz mumkin: и). Shuningdek, biz ichki avtomatlashtirish vositalarini, jumladan, ishlab chiqamiz .
So'nggi besh yil ichida bizning ishimizda bir xil turdagi va muntazam operatsiyalar ko'p to'plangan va bizning boshqa bo'limlardan ishlab chiquvchilarimiz asosan shunday deb ataladiganlardan keladi. tipik vazifalar, uning yechimi to'liq yoki qisman avtomatlashtirilgan, ijrochilar uchun qiyinchilik tug'dirmaydi va katta hajmdagi ishlarni talab qilmaydi. Etakchi yo'nalishlar bilan birgalikda biz bunday vazifalarni tahlil qildik va ishlarning alohida toifalarini aniqlashga muvaffaq bo'ldik, yoki ishlab chiqarish bosqichlari, bosqichlar bo'linmas bosqichlarga bo'lingan va bir necha bosqichlar qo'shilgan ishlab chiqarish jarayoni zanjiri.
Texnologik zanjirning eng oddiy misoli - kompaniya ichida har bir mahsulotimizni yig'ish, joylashtirish va sinovdan o'tkazish bosqichlari. O'z navbatida, masalan, qurish bosqichi ko'plab alohida tipik bosqichlardan iborat: GitLab'dan manbalarni yuklab olish, bog'liqliklar va uchinchi tomon kutubxonalarini tayyorlash, birlik testi va statik kod tahlili, GitLab CI-da qurish skriptini bajarish, repozitoriyda artefaktlarni nashr qilish. Bizning ichki ChangelogBuilder vositamiz orqali reliz yozuvlarini yaratish va yaratish.
Oddiy DevOps vazifalari haqida Habré haqidagi boshqa maqolalarimizda o'qishingiz mumkin: ""Va"".
Ko'p tipik ishlab chiqarish zanjirlari hosil bo'ladi ishlab chiqarish jarayoni. Jarayonlarni tavsiflashning standart yondashuvi funktsional IDEF0 modellaridan foydalanishdir.
Ishlab chiqarish CI jarayonini modellashtirishga misol
Biz uzluksiz integratsiya tizimi uchun namunaviy loyihalarni ishlab chiqishga alohida e’tibor qaratdik. Bu shunday deb atalmishlarni ta'kidlab, loyihalarni birlashtirishga erishishga imkon berdi aktsiyalar bilan qurish sxemasini chiqarish.
Bu qanday ishlaydi. Barcha loyihalar odatiy ko'rinishga ega: ular Artifactory-dagi suratlar omboriga tushadigan yig'ilishlar konfiguratsiyasini o'z ichiga oladi, shundan so'ng ular sinov stendlarida joylashtiriladi va sinovdan o'tkaziladi, so'ngra repozitoriyga ko'tariladi. Artifactory xizmati jamoalar va boshqa xizmatlar o'rtasidagi barcha qurilish artefaktlari uchun yagona tarqatish nuqtasidir.
Agar biz chiqarish sxemamizni sezilarli darajada soddalashtirsak va umumlashtirsak, u quyidagi bosqichlarni o'z ichiga oladi:
- o'zaro platformali mahsulotni yig'ish,
- sinov dastgohlariga joylashtirish,
- funktsional va boshqa testlarni o'tkazish,
- Artifactory-da omborlarni chiqarish uchun sinovdan o'tgan tuzilmalarni targ'ib qilish,
- yangilanish serverlarida relizlar tuzilmalarini nashr etish,
- ishlab chiqarishga yig'ish va yangilanishlarni etkazib berish,
- mahsulotni o'rnatish va yangilashni boshlash.
Masalan, ishlab chiqarishning ushbu tipik sxemasining texnologik modelini (keyingi o'rinlarda oddiygina Model) funktsional IDEF0 modeli ko'rinishida ko'rib chiqing. U CI jarayonimizning asosiy bosqichlarini aks ettiradi. IDEF0 modellari deb ataladiganlardan foydalanadi ICOM belgisi (Kirish-nazorat-chiqish-mexanizm) har bir bosqichda qanday resurslardan foydalanilishini, qanday qoidalar va talablarga asoslanib ish olib borilishini, natija nima ekanligini va qaysi mexanizmlar, xizmatlar yoki odamlar muayyan bosqichni amalga oshirishini tasvirlash.
Rasmni bosish uni to'liq hajmda ochadi.
Qoidaga ko'ra, funktsional modellarda jarayonlarni tavsiflash va batafsil tavsiflash osonroq. Ammo elementlar soni ortib borishi bilan ulardagi biror narsani tushunish qiyinroq bo'ladi. Ammo haqiqiy rivojlanishda yordamchi bosqichlar ham mavjud: monitoring, mahsulotni sertifikatlash, ish jarayonini avtomatlashtirish va boshqalar. O'lchov muammosi tufayli biz ushbu tavsifdan voz kechdik.
Umid tug'ilishi
Bitta kitobda biz texnologik jarayonlarni tavsiflovchi eski sovet xaritalariga duch keldik (aytmoqchi, ular bugungi kunda ham ko'plab davlat korxonalari va universitetlarida qo'llaniladi). Kutib turing, kuting, chunki bizda ham ish jarayoni bor!.. Bosqichlar, natijalar, ko'rsatkichlar, talablar, ko'rsatkichlar va boshqalar bor... Nima uchun bizning mahsulot quvurlarimizga ham oqim jadvallarini qo'llashga harakat qilmaysiz? Bir tuyg'u bor edi: “Mana shu! Biz to'g'ri ipni topdik, uni yaxshilab tortish vaqti keldi!
Oddiy jadvalda biz mahsulotlarni ustunlar, texnologik bosqichlar va mahsulot quvurlari bosqichlarini qatorlar bo'yicha yozishga qaror qildik. Miqdorlar katta narsadir, masalan, mahsulotni yaratish bosqichi. Va qadamlar kichikroq va batafsilroq narsadir, masalan, dastlabki kodni qurish serveriga yuklab olish yoki kodni kompilyatsiya qilish bosqichi.
Xaritaning satrlari va ustunlarining kesishgan joylarida biz ma'lum bir bosqich va mahsulot uchun statuslarni qo'yamiz. Statuslar uchun bir qator holatlar aniqlangan:
- Ma'lumot yo'q - yoki nomaqbul. Mahsulotning bir bosqichiga bo'lgan talabni tahlil qilish kerak. Yoki tahlil allaqachon o'tkazilgan, ammo bosqich hozirda kerak emas yoki iqtisodiy jihatdan oqlanmagan.
- Kechiktirilgan - yoki hozirda tegishli emas. Quvurdagi bosqich kerak, ammo bu yil amalga oshirish uchun kuchlar yo'q.
- Rejalashtirilgan. Bosqich joriy yilda amalga oshirilishi rejalashtirilgan.
- Amalga oshirildi. Quvurdagi bosqich kerakli hajmda amalga oshiriladi.
Jadvalni to'ldirish loyiha bo'yicha boshlandi. Birinchidan, bitta loyihaning bosqichlari va bosqichlari tasniflanib, ularning holati qayd etildi. Keyin ular navbatdagi loyihani oldilar, undagi statuslarni o'rnatdilar va oldingi loyihalarda etishmayotgan bosqich va bosqichlarni qo'shdilar. Natijada, biz butun ishlab chiqarish quvurining bosqichlari va bosqichlarini va ularning ma'lum bir loyihadagi holatini oldik. Bu mahsulot quvur liniyasi malakasi matritsasiga o'xshash narsa chiqdi. Biz bunday matritsani texnologik xarita deb atdik.
Texnologik xarita yordamida biz jamoalar bilan yil uchun ish rejalarini va birgalikda erishmoqchi bo'lgan maqsadlarni metrologik jihatdan oqilona muvofiqlashtiramiz: bu yil loyihaga qaysi bosqichlarni qo'shamiz va qaysi birini keyinroq qoldiramiz. Bundan tashqari, ish jarayonida biz faqat bitta mahsulot uchun yakunlagan bosqichlarda yaxshilanishlarga ega bo'lishimiz mumkin. Keyin biz xaritamizni kengaytiramiz va ushbu yaxshilanishni bosqich yoki yangi qadam sifatida kiritamiz, keyin har bir mahsulot uchun tahlil qilamiz va yaxshilashni takrorlashning maqsadga muvofiqligini aniqlaymiz.
Ular bizga e'tiroz bildirishlari mumkin: "Bularning barchasi, albatta, yaxshi, faqat vaqt o'tishi bilan qadamlar va bosqichlar soni juda katta bo'ladi. Qanday bo'lish kerak?
Biz har bir bosqich va bosqich uchun talablarning standart va etarlicha to'liq tavsiflarini kiritdik, shunda ular kompaniya ichidagi hamma tomonidan bir xil tushuniladi. Vaqt o'tishi bilan, yaxshilanishlar kiritilganda, qadam boshqa bosqichga yoki bosqichga singib ketishi mumkin va keyin ular "qulab tushadi". Shu bilan birga, barcha talablar va texnologik nuanslar umumlashtiruvchi bosqich yoki bosqich talablariga mos keladi.
Ko'paytirish yechimlari ta'sirini qanday baholash mumkin? Biz juda oddiy yondashuvdan foydalanamiz: yangi bosqichni amalga oshirish uchun boshlang'ich kapital xarajatlarni yillik umumiy mahsulot xarajatlariga bog'laymiz va keyin takrorlashda hammaga bo'linadi.
Rivojlanish qismlari allaqachon xaritada muhim bosqichlar va qadamlar sifatida ko'rsatilgan. Biz odatdagi bosqichlar uchun avtomatlashtirishni joriy etish orqali mahsulot tannarxini pasaytirishga ta'sir qilishimiz mumkin. Shundan so'ng, biz sifat ko'rsatkichlari, miqdoriy ko'rsatkichlar va jamoalar tomonidan olingan foyda (tejamkorlikning odam-soati yoki mashina-soati)dagi o'zgarishlarni ko'rib chiqamiz.
Ishlab chiqarish jarayonining texnologik xaritasi
Agar biz barcha bosqichlarimiz va qadamlarimizni olib boradigan bo'lsak, ularni teglar bilan kodlab, ularni bitta zanjirga kengaytirsak, u juda uzun va tushunarsiz bo'lib chiqadi (faqat biz maqolaning boshida gapirgan "piton dumi") :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Bu mahsulotlarni yaratish [Build] bosqichlari, ularni sinov serverlariga joylashtirish [Deploy], sinovdan o'tkazish [Test], sinov natijalariga ko'ra omborlarni chiqarish uchun tuzilmalarni rag'batlantirish [Rag'batlantirish], litsenziyalarni yaratish va nashr etish [Litsenziya], nashr qilish [ Publish] GUS yangilash serverida va FLUS yangilash serverlariga yetkazib berish, Mahsulot konfiguratsiyasini boshqarish [Oʻrnatish] yordamida mijoz infratuzilmasida mahsulot komponentlarini oʻrnatish va yangilash, shuningdek oʻrnatilgan mahsulotlardan telemetriya [Telemetry] toʻplami.
Ularga qo'shimcha ravishda alohida bosqichlarni ajratib ko'rsatish mumkin: infratuzilma holati monitoringi [InfMonitoring], manba kodini versiyalash [SourceCodeControl], qurish muhitini tayyorlash [Tayyorlash], loyihalarni boshqarish [Ish oqimi], jamoalarni aloqa vositalari bilan ta'minlash [Aloqa], mahsulotni sertifikatlash [ sertifikatlash] va CI jarayonlarining o'zini o'zi ta'minlash [CISelfSufficiency] (masalan, yig'ilishlarning Internetdan mustaqilligi). Bizning jarayonlarimizdagi o'nlab qadamlar hatto hisobga olinmaydi, chunki ular juda aniq.
Agar shaklda taqdim etilsa, butun ishlab chiqarish jarayonini tushunish va ko'rish ancha oson bo'ladi texnologik xarita; Bu jadval bo'lib, unda Modelning alohida ishlab chiqarish bosqichlari va parchalangan bosqichlari satrlarda va ustunlarda har bir bosqichda yoki bosqichda bajarilgan ishlar tavsifi yoziladi. Asosiy e'tibor har bir bosqichni ta'minlaydigan resurslarga va mas'uliyat sohalarini chegaralashga qaratilgan.
Biz uchun xarita o'ziga xos tasniflagichdir. U mahsulot ishlab chiqarishning yirik texnologik qismlarini aks ettiradi. Buning yordamida bizning avtomatlashtirish guruhimiz ishlab chiquvchilar bilan o'zaro hamkorlik qilish va avtomatlashtirish bosqichlarini amalga oshirishni birgalikda rejalashtirish, shuningdek, buning uchun qanday mehnat xarajatlari va resurslar (inson va apparat) talab qilinishini tushunish osonlashdi.
Kompaniyamiz ichida xarita avtomatik ravishda jinja shablonidan oddiy HTML fayl sifatida yaratiladi va keyin GitLab Pages serveriga yuklanadi. To'liq yaratilgan xarita misoli bilan skrinshotni ko'rish mumkin .
Rasmni bosish uni to'liq hajmda ochadi.
Xulosa qilib aytganda, texnologik xarita ishlab chiqarish jarayonining umumlashtirilgan tasviri bo'lib, unda tipik funksionallikka ega bo'lgan aniq tasniflangan bloklar aks ettiriladi.
Bizning yo'l xaritamizning tuzilishi
Xarita bir nechta qismlardan iborat:
- Sarlavha maydoni - bu erda xaritaning umumiy tavsifi, asosiy tushunchalar kiritiladi, ishlab chiqarish jarayonining asosiy resurslari va natijalari aniqlanadi.
- Boshqaruv paneli - bu erda siz alohida mahsulotlar uchun ma'lumotlarning ko'rinishini boshqarishingiz mumkin, amalga oshirilgan bosqichlar va umuman barcha mahsulotlar uchun qadamlar haqida qisqacha ma'lumot berilgan.
- Texnologik xarita - texnologik jarayonning jadvalli tavsifi. Xaritada:
- barcha bosqichlar, bosqichlar va ularning kodlari berilgan;
- bosqichlarning qisqa va to‘liq tavsiflari berilgan;
- har bir bosqichda foydalaniladigan kirish resurslari va xizmatlar ko'rsatilgan;
- har bir bosqich va alohida bosqich natijalari ko'rsatilgan;
- har bir bosqich va bosqich uchun javobgarlik sohasi ko'rsatilgan;
- HDD (SSD), RAM, vCPU kabi texnik resurslar va ushbu bosqichdagi ishni qo'llab-quvvatlash uchun zarur bo'lgan ish soatlari, hozirgi vaqtda ham - haqiqat, ham kelajakda - reja aniqlangan;
- har bir mahsulot uchun uning qaysi texnologik bosqichlari yoki bosqichlari amalga oshirilganligi, amalga oshirish rejalashtirilgan, ahamiyatsiz yoki amalga oshirilmaganligi ko'rsatiladi.
Texnologik xarita asosida qaror qabul qilish
Xaritani o'rganib chiqqandan so'ng, ba'zi harakatlarni amalga oshirish mumkin - xodimning kompaniyadagi roliga qarab (ishlab chiqish menejeri, mahsulot menejeri, ishlab chiquvchi yoki sinovchi):
- haqiqiy mahsulot yoki loyihada qanday bosqichlar etishmayotganligini tushunish va ularni amalga oshirish zaruriyatini baholash;
- agar ular turli bosqichlarda ishlayotgan bo'lsa, bir nechta bo'limlar o'rtasidagi mas'uliyat sohalarini chegaralash;
- bosqichlarning kirish va chiqishlarida shartnomalarni kelishib olish;
- ish bosqichini umumiy rivojlanish jarayoniga integratsiyalash;
- bosqichlarning har birini ta'minlaydigan resurslarga bo'lgan ehtiyojni aniqroq baholash.
Yuqorida aytilganlarning barchasini umumlashtirish
Marshrutlash ko'p qirrali, kengaytiriladigan va parvarish qilish oson. Qattiq akademik IDEF0 modeliga qaraganda bu shakldagi jarayonlar tavsifini ishlab chiqish va saqlash ancha oson. Bundan tashqari, jadvalli tavsif funktsional modelga qaraganda sodda, tanish va yaxshiroq tuzilgan.
Bosqichlarni texnik amalga oshirish uchun bizda CrossBuilder maxsus ichki vositasi mavjud - CI tizimlari, xizmatlari va infratuzilmasi o'rtasidagi qatlam vositasi. Ishlab chiquvchi o'z velosipedini kesishi shart emas: bizning CI tizimimizda CrossBuilder vositasining skriptlaridan birini (vazifa deb ataladigan) ishga tushirish kifoya, bu bizning infratuzilmamiz xususiyatlarini hisobga olgan holda uni to'g'ri bajaradi. .
natijalar
Maqola juda uzun bo'lib chiqdi, ammo murakkab jarayonlarni modellashtirishni tavsiflashda bu muqarrar. Oxir-oqibat, men asosiy g'oyalarimizni qisqacha ta'riflamoqchiman:
- Kompaniyamizda DevOps g'oyalarini amalga oshirishdan maqsad kompaniya mahsulotlarini ishlab chiqarish va ularga texnik xizmat ko'rsatish xarajatlarini miqdoriy ko'rsatkichlarda (odam-soat yoki mashina soatlari, vCPU, RAM, Disk) izchil ravishda kamaytirishdir.
- Rivojlanishning umumiy xarajatlarini kamaytirish usuli odatiy ketma-ket vazifalarni bajarish xarajatlarini minimallashtirishdan iborat: texnologik jarayonning bosqichlari va bosqichlari.
- Oddiy vazifa - bu to'liq yoki qisman avtomatlashtirilgan, ijrochilar uchun qiyinchilik tug'dirmaydigan va katta mehnat xarajatlarini talab qilmaydigan vazifa.
- Ishlab chiqarish jarayoni bosqichlardan iborat bo'lib, bosqichlar bo'linmas bosqichlarga bo'linadi, ular har xil miqyos va hajmdagi tipik vazifalardir.
- Turli xil tipik vazifalardan biz ishlab chiqarish jarayonining murakkab texnologik zanjirlari va ko'p darajali modellariga keldik, ularni funktsional IDEF0 modeli yoki oddiyroq texnologik xarita bilan tavsiflash mumkin.
- Texnologik xarita ishlab chiqarish jarayonining bosqichlari va bosqichlarini jadval shaklida aks ettiradi. Eng muhimi: xarita butun jarayonni to'liq hajmda, ularni batafsil ko'rsatish imkoniyati bilan katta qismlarda ko'rish imkonini beradi.
- Texnologik xaritaga asoslanib, muayyan mahsulotga bosqichlarni joriy etish zaruriyatini baholash, mas'uliyat sohalarini belgilash, bosqichlarning kirish va chiqishlarida shartnomalarni kelishish va resurslarga bo'lgan ehtiyojni aniqroq baholash mumkin.
Keyingi maqolalarda xaritamizda muayyan texnologik bosqichlarni amalga oshirish uchun qanday texnik vositalar qo'llanilishini batafsilroq tasvirlab beramiz.
Maqola mualliflari:
- — Positive Technologies kompaniyasining avtomatlashtirish (DevOps) bo'limi boshlig'i
- - Deputat Positive Technologies kompaniyasining avtomatlashtirish bo'limi (DevOps) boshlig'i
Manba: www.habr.com