Сурет:
Бәріңе сәлем! Біз компанияның автоматтандыру инженерлеріміз және біз компания өнімдерінің дамуын қолдаймыз: әзірлеушілердің кодтар сызығын тапсыруынан бастап, жаңарту серверлерінде дайын өнімдер мен лицензияларды жариялауға дейінгі барлық құрастыру құбырын қолдаймыз. Бейресми түрде бізді DevOps инженерлері деп атайды. Бұл мақалада біз бағдарламалық жасақтаманы өндіру процесінің технологиялық кезеңдері, оларды қалай көретініміз және оларды қалай жіктейтініміз туралы сөйлескіміз келеді.
Материалдан сіз көп өнімді әзірлеуді үйлестірудің күрделілігі туралы, технологиялық карта дегеніміз не және ол шешімдерді ретке келтіруге және қайталауға қалай көмектесетіні туралы, әзірлеу процесінің негізгі кезеңдері мен қадамдары қандай, жауапкершілік аймақтары туралы біле аласыз. DevOps және біздің компаниядағы командалар арасында.
Хаос және DevOps туралы
Қысқаша айтқанда, DevOps тұжырымдамасы әзірлеу құралдары мен қызметтерін, сондай-ақ оларды пайдаланудың әдістемелері мен озық тәжірибелерін қамтиды. Жаһандықты бөліп алайық цель DevOps идеяларын біздің компаниямызда жүзеге асырудан: бұл сандық мәнде (адам-сағат немесе машина сағаты, CPU, RAM, Disk және т. Бүкіл компания деңгейінде дамудың жалпы құнын төмендетудің ең оңай және ең айқын жолы типтік сериялық тапсырмаларды орындау құнын азайту өндірістің барлық кезеңдерінде. Бірақ бұл қандай кезеңдерден тұрады, оларды жалпы процестен қалай ажыратуға болады, олар қандай кезеңдерден тұрады?
Компания бір өнімді жасағанда, бәрі азды-көпті түсінікті болады: әдетте ортақ жол картасы мен даму схемасы болады. Бірақ өнім желісі кеңейіп, өнімдер көп болған кезде не істеу керек? Бір қарағанда, оларда ұқсас процестер мен құрастыру желілері бар, журналдар мен сценарийлерде «X айырмашылықтарын табу» ойыны басталады. Бірақ белсенді әзірленуде 5+ жоба бар болса және бірнеше жылдар бойы әзірленген бірнеше нұсқаларды қолдау қажет болса ше? Біз өнім құбырларында шешімдердің максималды ықтимал санын қайта пайдаланғымыз келе ме, әлде әрқайсысы үшін бірегей әзірлеуге ақша жұмсауға дайынбыз ба?
Бірегейлік пен сериялық шешімдер арасындағы тепе-теңдікті қалай табуға болады?
Бұл сұрақтар біздің алдымызда 2015 жылдан бастап жиі туындай бастады. Өнімдердің саны өсті және біз осы өнімдердің құрастыру желілерін қолдайтын автоматтандыру бөлімін (DevOps) барынша кеңейтуге тырыстық. Сонымен қатар, біз өнімдер арасында мүмкіндігінше көп шешімдерді қайталағымыз келді. Ақыр соңында, неге он өнімде бірдей нәрсе әртүрлі жолмен жасалады?
дамыту жөніндегі директор: "Балалар, біз DevOps өнімдер үшін не істейтінін қандай да бір түрде бағалай аламыз ба?"
біз: «Біз білмейміз, біз мұндай сұрақ қойған жоқпыз, бірақ қандай көрсеткіштерді ескеру керек?»
дамыту жөніндегі директор: «Ал кім біледі! Ойлау…»
Сол атақты фильмдегідей: «Мен қонақүйдемін!..» - «Уф... Маған жол көрсете аласыз ба?». Ой жүгірте келе, біз ең алдымен өнімнің соңғы күйлері туралы шешім қабылдауымыз керек деген қорытындыға келдік; бұл біздің бірінші мақсатымыз болды.
Сонымен, 10-нан 200 адамға дейін үлкен топтары бар ондаған өнімді қалай талдайсыз және шешімдерді қайталау кезінде өлшенетін көрсеткіштерді қалай анықтауға болады?
1:0 Хаос немесе иық пышақтарында DevOps пайдасына
Біз BPwin сериясынан IDEF0 диаграммаларын және әртүрлі бизнес-процесс диаграммаларын қолдану әрекетінен бастадық. Шатасу келесі жобаның келесі кезеңінің бесінші шаршысынан кейін басталды және әрбір жоба үшін бұл квадраттарды 50+ қадамның астындағы ұзын питонның құйрығына салуға болады. Мен мұңайып, айға жылағым келді - бұл мүлдем сәйкес келмеді.
Типтік өндірістік міндеттер
Өндірістік процестерді модельдеу өте күрделі және қиын жұмыс: әртүрлі бөлімдер мен өндірістік тізбектерден көптеген деректерді жинау, өңдеу және талдау қажет. Бұл туралы толығырақ мақаладан оқи аласыз »«.
Өндірістік процесті модельдеуді бастаған кезде біздің компанияның өнімдерін әзірлеуге қатысатын әрбір қызметкерге және жоба менеджерлеріне жеткізу үшін нақты мақсат қойдық:
- өнімдер мен олардың құрамдас бөліктері код жолын орындаудан бастап орнатушылар мен жаңартулар түрінде тұтынушыға қалай жететінін,
- өнім өндірудің әрбір кезеңі үшін қандай ресурстар қарастырылған,
- әр кезеңде қандай қызметтер қатысады,
- әр кезең үшін жауапкершілік аймақтары қалай бөлінген,
- әр кезеңнің кіру және шығуында қандай келісім-шарттар бар.
Суретті басу оны толық көлемде ашады.
Біздің компаниядағы жұмысымыз бірнеше функционалдық бағыттарға бөлінген. Инфрақұрылымның бағыты бөлімнің барлық «темір» ресурстарының жұмысын оңтайландырумен, сондай-ақ виртуалды машиналарды және оларға қоршаған ортаны орналастыруды автоматтандырумен айналысады. Мониторинг бағыты тәулік бойы қызмет көрсетуді бақылауды қамтамасыз етеді; біз әзірлеушілерге қызмет ретінде мониторингті де ұсынамыз. Жұмыс үрдісінің бағыты командаларды әзірлеу және тестілеу процестерін басқару, код күйін талдау және жобалар бойынша аналитика алу үшін құралдармен қамтамасыз етеді. Соңында, webdev бағыты GUS және FLUS жаңарту серверлерінде шығарылымдарды жариялауды, сондай-ақ LicenseLab қызметін пайдаланып өнімдерді лицензиялауды қамтамасыз етеді. Өндіріс құбырын қолдау үшін біз әзірлеушілерге көптеген түрлі қолдау қызметтерін орнатамыз және оларға қызмет көрсетеміз (ескі кездесулерде олардың кейбіреулері туралы әңгімелерді тыңдай аласыз: и). Біз сондай-ақ ішкі автоматтандыру құралдарын әзірлейміз, соның ішінде .
Соңғы бес жыл ішінде біздің жұмысымызда бір типті және күнделікті операциялардың көп мөлшері жинақталды, ал басқа бөлімдердегі әзірлеушілеріміз негізінен деп аталатындардан келеді. типтік тапсырмалар, оның шешімі толық немесе ішінара автоматтандырылған, орындаушыларға қиындық тудырмайды және айтарлықтай жұмыс көлемін қажет етпейді. Жетекші бағыттармен бірге біз осындай тапсырмаларды талдап, жұмыстың жекелеген санаттарын анықтай алдық, немесе өндіріс қадамдары, кезеңдері бөлінбейтін қадамдарға бөлініп, бірнеше кезең қосылды өндірістік процесс тізбегі.
Технологиялық тізбектің қарапайым мысалы - компания ішінде біздің әрбір өнімімізді құрастыру, орналастыру және сынау кезеңдері. Өз кезегінде, мысалы, құрастыру кезеңі көптеген жеке типтік қадамдардан тұрады: GitLab-тен көздерді жүктеп алу, тәуелділіктер мен үшінші тарап кітапханаларын дайындау, бірліктерді тестілеу және статикалық кодты талдау, GitLab CI жүйесінде құрастыру сценарийін орындау, репозиторийде артефактілерді жариялау. Ішкі ChangelogBuilder құралы арқылы шығарылым жазбаларын жасау және жасау.
Әдеттегі DevOps тапсырмалары туралы Habré туралы басқа мақалаларымыздан оқи аласыз: ««Ал»«.
Көптеген типтік өндірістік тізбектер қалыптасады өндірістік процесс. Процестерді сипаттаудың стандартты тәсілі функционалды IDEF0 үлгілерін пайдалану болып табылады.
Өндірістік CI процесін модельдеу мысалы
Үздіксіз интеграциялық жүйе үшін типтік жобаларды әзірлеуге ерекше назар аудардық. Бұл жобаларды біріздендіруге қол жеткізуге мүмкіндік берді акциялармен құрастыру схемасын шығарыңыз.
Бұл қалай жұмыс істейді. Барлық жобалар типтік көрінеді: олар Artifactory-дегі сурет репозиторийіне түсетін жинақтардың конфигурациясын қамтиды, содан кейін олар сынақ алаңдарында орналастырылады және сыналады, содан кейін шығарылым репозиторийіне көтеріледі. Artifactory қызметі командалар мен басқа қызметтер арасындағы барлық құрастыру артефактілері үшін бірыңғай тарату нүктесі болып табылады.
Егер біз шығару схемасын айтарлықтай жеңілдететін және жалпылайтын болсақ, онда ол келесі қадамдарды қамтиды:
- кросс-платформалық өнімді құрастыру,
- сынақ стендтеріне орналастыру,
- функционалдық және басқа сынақтарды жүргізу,
- Artifactory репозиторийлерін шығару үшін сынақтан өткен құрастырмаларды жылжыту,
- жаңарту серверлерінде шығарылым жинақтарын жариялау,
- құрастырулар мен жаңартуларды өндіріске жеткізу,
- өнімді орнатуды және жаңартуды іске қосу.
Мысалы, функционалдық IDEF0 үлгісі түріндегі осы типтік шығару схемасының (бұдан әрі жай үлгі) технологиялық үлгісін қарастырыңыз. Ол біздің CI процесінің негізгі кезеңдерін көрсетеді. IDEF0 үлгілері деп аталатындарды пайдаланады ICOM белгісі (Input-Control-Output-Mechanism) әр кезеңде қандай ресурстар пайдаланылатынын сипаттау, қандай ережелер мен талаптар негізінде жұмыс орындалады, қандай нәтиже бар және қандай механизмдер, қызметтер немесе адамдар белгілі бір кезеңді жүзеге асырады.
Суретті басу оны толық көлемде ашады.
Әдетте, функционалдық үлгілерде процестердің сипаттамасын бөлшектеу және егжей-тегжейлі беру оңайырақ. Бірақ элементтердің саны өскен сайын олардағы бір нәрсені түсіну қиындай түседі. Бірақ нақты дамуда көмекші сатылар да бар: бақылау, өнімді сертификаттау, жұмыс процестерін автоматтандыру және т.б. Масштабтау мәселесіне байланысты біз бұл сипаттамадан бас тарттық.
Үміттің туылуы
Бір кітапта біз технологиялық процестерді сипаттайтын ескі кеңестік карталарды кездестірдік (айтпақшы, олар бүгінде көптеген мемлекеттік кәсіпорындар мен университеттерде қолданылады). Күте тұрыңыз, күте тұрыңыз, өйткені бізде де жұмыс процесі бар!.. Кезеңдер, нәтижелер, көрсеткіштер, талаптар, көрсеткіштер және т.б. бар... Неліктен біздің өнім құбырларына да ағындық кестелерді қолдануға тырыспасқа? Бір сезім болды: «Міне, солай! Біз дұрыс жіпті таптық, оны жақсы тартатын кез келді!
Қарапайым кестеде біз өнімдерді бағандар бойынша, ал технологиялық кезеңдерді және өнім құбырының қадамдарын жолдар бойынша жазуды шештік. Маңызды кезең - бұл өнімді құру қадамы сияқты үлкен нәрсе. Ал қадамдар - құрастыру серверіне бастапқы кодты жүктеп алу немесе кодты құрастыру қадамы сияқты кішірек және егжей-тегжейлі нәрсе.
Картаның жолдары мен бағандарының қиылысында біз белгілі бір кезең мен өнім үшін күйлерді қоямыз. Күйлер үшін күйлер жиынтығы анықталды:
- Мәлімет жоқ - немесе орынсыз. Өнімдегі кезеңге сұранысты талдау қажет. Немесе талдау жүргізілді, бірақ кезең қазіргі уақытта қажет емес немесе экономикалық тұрғыдан негізделмеген.
- Кейінге қалдырылды - немесе қазіргі уақытта маңызды емес. Құбырдағы кезең қажет, бірақ биыл жүзеге асыруға күш жоқ.
- Жоспарланған. Кезеңді биыл жүзеге асыру жоспарлануда.
- Орындалды. Құбырдағы кезең қажетті көлемде жүзеге асырылады.
Кестені толтыру жоба бойынша жобадан басталды. Алдымен бір жобаның кезеңдері мен қадамдары жіктеліп, олардың статустары жазылды. Содан кейін олар келесі жобаны алып, ондағы статустарды бекітіп, бұрынғы жобаларда жетіспейтін кезеңдер мен қадамдарды қосты. Нәтижесінде біз бүкіл өндірістік құбырымыздың кезеңдері мен қадамдарын және олардың нақты жобадағы статустарын алдық. Бұл өнім құбырының құзыреттілік матрицасына ұқсас нәрсе болды. Мұндай матрицаны технологиялық карта деп атадық.
Технологиялық картаның көмегімен біз бригадалармен бір жылға арналған жұмыс жоспарларын және бірлесіп қол жеткізгіміз келетін мақсаттарды метрологиялық тұрғыдан негізделген түрде үйлестіреміз: биылғы жылы жобаға қандай кезеңдерді қосамыз және қайсысын кейінірек қалдырамыз. Сондай-ақ, жұмыс барысында бізде тек бір өнім үшін аяқтаған кезеңдерде жақсартулар болуы мүмкін. Содан кейін біз картамызды кеңейтіп, осы жақсартуды кезең немесе жаңа қадам ретінде енгіземіз, содан кейін біз әрбір өнімге талдау жасаймыз және жақсартуды қайталау мүмкіндігін анықтаймыз.
Олар бізге қарсы болуы мүмкін: «Мұның бәрі, әрине, жақсы, тек уақыт өте келе қадамдар мен кезеңдердің саны шектен тыс көп болады. Не істейін?»
Біз әрбір кезең мен қадамға қойылатын талаптардың стандартты және жеткілікті толық сипаттамасын енгіздік, осылайша оларды компаниядағы барлық адамдар бірдей түсінеді. Уақыт өте келе, жақсартулар енгізілген сайын, қадам басқа кезеңге немесе қадамға сіңіп кетуі мүмкін, содан кейін олар «құлайды». Сонымен қатар барлық талаптар мен технологиялық нюанстар жалпылау сатысының немесе қадамының талаптарына сәйкес келеді.
Репликациялау шешімдерінің әсерін қалай бағалауға болады? Біз өте қарапайым тәсілді қолданамыз: жаңа кезеңді жүзеге асыру үшін бастапқы күрделі шығындарды жылдық жалпы өнім шығындарына жатқызамыз, содан кейін қайталау кезінде барлығына бөлеміз.
Дамудың бөліктері картада белестер мен қадамдар ретінде көрсетілген. Біз типтік кезеңдерге автоматтандыруды енгізу арқылы өнімнің өзіндік құнын төмендетуге әсер ете аламыз. Осыдан кейін біз сапалық сипаттамалардағы, сандық көрсеткіштердегі өзгерістерді және бригадалар алған пайданы (үнемдеудің адам-сағаты немесе машина-сағаты бойынша) қарастырамыз.
Өндіріс процесінің технологиялық картасы
Егер біз барлық кезеңдеріміз бен қадамдарымызды қабылдап, оларды тегтермен кодтасақ және оларды бір тізбекке кеңейтетін болсақ, онда бұл өте ұзақ және түсініксіз болып шығады (мақаланың басында біз айтқан дәл сол «питон құйрығы») :
[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]Бұл өнімдерді құру [Құру], оларды сынақ серверлеріне орналастыру [Орналастыру], сынау [Тест], тестілеу нәтижелері бойынша репозиторийлерді шығару үшін құрастыруларды жылжыту [Жылдамдау], лицензияларды жасау және жариялау [Лицензия], жариялау [ GUS жаңарту серверінде жариялау] және FLUS жаңарту серверлеріне жеткізу, Өнім конфигурациясын басқару [Орнату] арқылы тұтынушының инфрақұрылымында өнім құрамдастарын орнату және жаңарту, сонымен қатар орнатылған өнімдерден телеметрия [Телеметрия] жинағы.
Оларға қосымша бөлек кезеңдерді бөліп көрсетуге болады: инфрақұрылым күйінің мониторингі [InfMonitoring], бастапқы код нұсқасын жасау [SourceCodeControl], құру ортасын дайындау [Дайындау], жобаны басқару [Жұмыс процесі], командаларды байланыс құралдарымен қамтамасыз ету [Байланыс], өнімді сертификаттау [ сертификаттау] және CI процестерінің өзін-өзі қамтамасыз ету [CISelfSufficiency] (мысалы, жинақтардың Интернеттен тәуелсіздігі). Біздің процестердегі ондаған қадамдар тіпті қарастырылмайды, өйткені олар өте нақты.
Пішінде ұсынылса, бүкіл өндіріс процесін түсіну және қарау әлдеқайда жеңіл болады технологиялық карта; бұл Модельдің жеке өндіріс кезеңдері мен ыдырайтын қадамдары жолдарда, ал бағандарда әрбір кезеңде немесе қадамда орындалатын әрекеттердің сипаттамасы жазылған кесте. Негізгі екпін әр кезеңді қамтамасыз ететін ресурстарға және жауапкершілік салаларын шектеуге аударылады.
Карта біз үшін классификатордың бір түрі. Ол өнім өндірудің үлкен технологиялық бөліктерін көрсетеді. Осының арқасында біздің автоматтандыру тобына әзірлеушілермен өзара әрекеттесу және автоматтандыру кезеңдерін енгізуді бірлесіп жоспарлау, сондай-ақ бұл үшін қандай еңбек шығындары мен ресурстар (адам және аппараттық құралдар) қажет болатынын түсіну оңайырақ болды.
Біздің компанияның ішінде карта jinja үлгісінен қалыпты HTML файлы ретінде автоматты түрде жасалады, содан кейін GitLab Pages серверіне жүктеледі. Толық жасалған картаның мысалы бар скриншотты көруге болады .
Суретті басу оны толық көлемде ашады.
Қысқаша айтқанда, технологиялық карта типтік функционалдығы бар анық жіктелген блоктарды көрсететін өндірістік процестің жалпыланған суреті болып табылады.
Біздің жол картамыздың құрылымы
Карта бірнеше бөліктерден тұрады:
- Титулдық аймақ – мұнда картаның жалпы сипаттамасы берілген, негізгі ұғымдар енгізілген, негізгі ресурстар мен өндірістік процестің нәтижелері анықталған.
- Бақылау тақтасы - мұнда сіз жеке өнімдерге арналған деректердің көрсетілуін басқара аласыз, барлық өнімдер үшін жалпы орындалған кезеңдердің және қадамдардың қысқаша мазмұны берілген.
- Технологиялық карта – технологиялық процестің кестелік сипаттамасы. Картада:
- барлық кезеңдері, қадамдары және олардың кодтары берілген;
- кезеңдердің қысқаша және толық сипаттамасы беріледі;
- әрбір кезеңде қолданылатын кіріс ресурстары мен қызметтер көрсетіледі;
- әрбір кезеңнің және жеке қадамның нәтижелері көрсетіледі;
- әрбір кезең мен қадам үшін жауапкершілік аймағы көрсетіледі;
- HDD (SSD), жедел жад, vCPU сияқты техникалық ресурстар және осы кезеңде жұмысты қамтамасыз ету үшін қажетті адам-сағат, қазіргі уақытта да - факт, және болашақта - жоспар анықталды;
- әрбір өнім бойынша оның қандай технологиялық кезеңдері немесе қадамдары іске асырылғаны, іске асыру жоспарланған, қатысы жоқ немесе орындалмағаны көрсетіледі.
Технологиялық карта негізінде шешім қабылдау
Картаны зерттегеннен кейін кейбір әрекеттерді орындауға болады - қызметкердің компаниядағы рөліне байланысты (әзірлеу менеджері, өнім менеджері, әзірлеуші немесе сынақшы):
- нақты өнімде немесе жобада қандай кезеңдердің жетіспейтінін түсіну және оларды жүзеге асыру қажеттілігін бағалау;
- бірнеше бөлімшелер әртүрлі кезеңдерінде жұмыс істейтін болса, олардың арасындағы жауапкершілік салаларын шектеңіз;
- кезеңдердің кіру-шығу орындарында шарттарды келісу;
- жұмыс кезеңіңізді жалпы даму процесіне біріктіру;
- кезеңдердің әрқайсысын қамтамасыз ететін ресурстардың қажеттілігін дәлірек бағалау.
Жоғарыда айтылғандардың барлығын қорытындылау
Маршруттау әмбебап, кеңейтілетін және қызмет көрсетуге оңай. Қатаң академиялық IDEF0 үлгісіне қарағанда бұл пішінде процестердің сипаттамасын әзірлеу және қолдау әлдеқайда оңай. Сонымен қатар, кестелік сипаттама функционалдық үлгіге қарағанда қарапайым, таныс және жақсы құрылымдалған.
Қадамдарды техникалық жүзеге асыру үшін бізде CrossBuilder арнайы ішкі құралы бар - CI жүйелері, қызметтері және инфрақұрылымы арасындағы деңгей құралы. Әзірлеушіге велосипедін кесудің қажеті жоқ: біздің CI жүйемізде инфрақұрылымымыздың ерекшеліктерін ескере отырып, оны дұрыс орындайтын CrossBuilder құралының сценарийлерінің бірін (тапсырма деп аталатын) іске қосу жеткілікті. .
Нәтижелері
Мақала өте ұзақ болды, бірақ күрделі процестерді модельдеуді сипаттау кезінде бұл сөзсіз. Қорытындылай келе, мен негізгі идеяларымызды қысқаша түзеткім келеді:
- Біздің компанияда DevOps идеяларын жүзеге асырудың мақсаты - компания өнімдерін өндіру және техникалық қызмет көрсету құнын сандық мәнде (адам-сағат немесе машина сағаты, vCPU, RAM, Disk) дәйекті түрде төмендету.
- Әзірлеудің жалпы құнын төмендету жолы типтік сериялық тапсырмаларды орындау шығындарын барынша азайту болып табылады: технологиялық процестің кезеңдері мен қадамдары.
- Типтік тапсырма - шешімі толық немесе жартылай автоматтандырылған, орындаушыларға қиындық тудырмайтын және айтарлықтай еңбек шығындарын қажет етпейтін тапсырма.
- Өндіріс процесі кезеңдерден тұрады, сатылар бөлінбейтін қадамдарға бөлінеді, олар әртүрлі масштабтағы және көлемдегі типтік міндеттер.
- Әртүрлі типтік тапсырмалардан біз күрделі технологиялық тізбектерге және өндірістік процестің көп деңгейлі үлгілеріне келдік, оларды функционалды IDEF0 үлгісімен немесе қарапайым технологиялық картамен сипаттауға болады.
- Технологиялық карта өндіріс процесінің кезеңдері мен қадамдарының кестелік көрінісі болып табылады. Ең бастысы: карта бүкіл процесті толық, оларды егжей-тегжейлі көрсету мүмкіндігімен үлкен бөліктерде көруге мүмкіндік береді.
- Технологиялық картаның негізінде белгілі бір өнімде кезеңдерді енгізу қажеттілігін бағалауға, жауапкершілік салаларын бөлуге, кезеңдердің кірісі мен шығысындағы келісім-шарттарды келісуге және ресурстарға деген қажеттілікті дәлірек бағалауға болады.
Келесі мақалаларда біз картамызда белгілі бір технологиялық кезеңдерді жүзеге асыру үшін қандай техникалық құралдар қолданылатынын толығырақ сипаттайтын боламыз.
Мақала авторлары:
- — Positive Technologies автоматтандыру бөлімінің бастығы (DevOps).
- - Орынбасар Positive Technologies автоматтандыру бөлімінің бастығы (DevOps).
Ақпарат көзі: www.habr.com