малюнак:
Ўсім прывітанне! Мы інжынеры-аўтаматызатары з кампаніі і займаемся суправаджэннем распрацоўкі прадуктаў кампаніі: падтрымліваем увесь зборачны канвеер ад комита радкі кода распрацоўшчыкамі да публікацыі гатовых прадуктаў і ліцэнзій на серверах абнаўленняў. Нефармальна нас называюць DevOps-інжынеры. У гэтым артыкуле мы хочам расказаць пра тэхналагічныя этапы працэсу вытворчасці ПЗ, пра тое, як мы іх бачым і як класіфікуем.
З матэрыялу вы даведаецеся пра складанасць каардынацыі мультыпрадуктавай распрацоўкі, пра тое, што такое тэхналагічная карта і як яна дапамагае парадкаваць і тыражаваць рашэнні, з якіх асноўных этапаў і крокаў складаецца працэс распрацоўкі, як размежаваны зоны адказнасці паміж DevOps і камандамі ў нашай кампаніі.
Пра Хаос і DevOps
Коратка адзначым, што паняцце DevOps уключае ў сябе прылады і сэрвісы распрацоўкі, а таксама метадалогіі і лепшыя практыкі іх выкарыстання. Вылучым глабальную мэта ад укаранення ідэй DevOps у нашай кампаніі: гэта паслядоўнае зніжэнне сабекошту вытворчасці і суправаджэння прадуктаў у колькасных паказчыках (чалавека-гадзінах або машына-гадзінах, CPU, RAM, Disk etc.). Самы просты і відавочны спосаб зніжэння агульнага сабекошту распрацоўкі на ўзроўні ўсёй кампаніі - гэта мінімізацыя кошту выканання тыпавых серыйных задач на ўсіх этапах вытворчасці. Але што гэта за этапы, як іх вылучыць з агульнага працэсу, з якіх крокаў яны складаюцца?
Калі кампанія распрацоўвае адзін прадукт, усё больш-менш зразумела: звычайна ёсць агульны роадмап і схема распрацоўкі. Але што рабіць, калі прадуктовая лінейка пашыраецца і прадуктаў становіцца больш? На першы погляд, у іх падобныя працэсы і зборачныя канвееры і пачынаецца гульня "знайдзі Х адрозненняў" у логах і скрыптах. А калі ў актыўнай распрацоўцы ўжо 5+ праектаў і патрабуецца падтрымка некалькіх вэрсіяў, распрацаваных за некалькі гадоў? Ці жадаем мы перавыкарыстоўваць максімальна магчымую колькасць рашэнняў у прадуктовых канвеерах ці гатовыя марнавацца на ўнікальную распрацоўку пад кожны?
Як знайсці баланс паміж унікальнасцю і серыйнасцю рашэнняў?
Гэтыя пытанні сталі ўзнікаць перад намі ўсё часцей пачынаючы з 2015 года. Колькасць прадуктаў расла, а пашыраць наш аддзел аўтаматызацыі (DevOps), у якога на падтрымцы знаходзіліся зборачныя канвееры гэтых прадуктаў, імкнуліся па мінімуме. Пры гэтым хацелася як мага больш рашэнняў тыражаваць паміж прадуктамі. У рэшце рэшт, навошта рабіць адно і тое ж у дзесяці прадуктах рознымі спосабамі?
Дырэктар па распрацоўцы: "Хлопцы, а мы неяк можам ацаніць, што робіць DevOps для прадуктаў?"
Мы: "Не ведаем, не задаваліся такім пытаннем, а якія паказчыкі лічыць трэба?"
Дырэктар па распрацоўцы: «А хто яго ведае! Падумайце…»
Як у вядомым тым фільме: "Мне ў гасцініцу!.." - "Э-э… А дарогу пакажаш?". Падумаўшы, мы дашлі да высновы, што спачатку патрабуецца вызначыцца з канчатковымі станамі прадуктаў; гэта стала нашай першай мэтай.
Такім чынам, як жа правесці аналіз дзясятка прадуктаў з досыць буйнымі камандамі ад 10 да 200 чалавек і вызначыць вымерна метрыкі пры тыражаванні рашэнняў?
1:0 на карысць Хаосу, ці DevOps на лапатках
Пачалі са спробы прымяніць дыяграмы IDEF0 і розныя дыяграмы бізнес-працэсаў з серыі BPwin. Блытаніна пачалася пасля пятага квадраціка чарговага этапу чарговага праекта, а квадрацікаў гэтых у кожнага праекта можна намаляваць у хвост даўжэзнага пітона пад 50 + крокаў. Захруснулася і захацелася павыць на месяц - не падышло ўвогуле.
Тыпавыя вытворчыя задачы
Мадэляванне вытворчых працэсаў - гэта вельмі складаная і карпатлівая праца: трэба сабраць, апрацаваць і прааналізаваць мноства дадзеных па розных аддзелах і вытворчым ланцужках. Падрабязней пра гэта вы можаце прачытаць у артыкуле «.
Калі мы заняліся мадэляваннем нашага вытворчага працэсу, то пераследвалі пэўную мэту - данесці да кожнага супрацоўніка, які ўдзельнічае ў распрацоўцы прадуктаў нашай кампаніі, і да кіраўнікоў праектаў:
- як прадукты і іх кампаненты, пачынальна ад коммита радкі кода, даходзяць да замоўца ў выглядзе ўсталёўнікаў і абнаўленняў,
- якімі рэсурсамі забяспечаны кожны этап вытворчасці прадуктаў,
- якія сэрвісы ўдзельнічаюць на кожным этапе,
- як размежаваны зоны адказнасці для кожнага этапу,
- якія кантракты існуюць на ўваходзе і выхадзе кожнага этапа.
Па кліку карцінка адкрыецца ў поўным памеры
Наша праца ў кампаніі падзелена на некалькі функцыянальных напрамкаў. Кірунак інфраструктуры займаецца аптымізацыяй эксплуатацыі ўсіх "жалезных" рэсурсаў аддзела, а таксама аўтаматызацыяй разгортвання віртуальных машын і асяроддзі на іх. Кірунак маніторынгу забяспечвае кантроль працаздольнасці сэрвісаў 24/7; таксама мы даем маніторынг як сэрвіс для распрацоўшчыкаў. Кірунак workflow дае камандам прылады для кіравання працэсамі распрацоўкі і тэставанні, аналізу стану кода, для атрымання аналітыкі па праектах. І нарэшце, кірунак webdev забяспечвае публікацыю рэлізаў на серверах абнаўленняў GUS і FLUS, а таксама ліцэнзаванне прадуктаў пры дапамозе сэрвісу LicenseLab. Для падтрымкі вытворчага канвеера мы наладжваем і суправаджаем мноства розных дапаможных сэрвісаў для распрацоўнікаў (апавяданні пра некаторыя з іх можна паслухаць на старых мітапах: и). Таксама мы распрацоўваем інструменты ўнутранай аўтаматызацыі, у тым ліку .
За апошнія пяць гадоў у нашай працы назапасілася мноства аднатыпных і руцінных аперацый, а ад нашых распрацоўшчыкаў з іншых аддзелаў у асноўным прыходзяць так званыя. тыпавыя задачы, вырашэнне якіх аўтаматызавана поўнасцю або часткова, не выклікае цяжкасцей у выканаўцаў і не патрабуе значных аб'ёмаў работ. Сумесна з вядучымі напрамкаў мы прааналізавалі такія задачы і змаглі вылучыць асобныя катэгорыі работ, або вытворчыя этапы, этапы разбілі на непадзельныя крокі, а з некалькіх этапаў складаецца вытворчы тэхналагічны ланцужок.
Найпросты прыклад тэхналагічнага ланцужка - гэта этапы зборкі, дэплою і тэставанні кожнага нашага прадукта ўсярэдзіне кампаній. У сваю чаргу, напрыклад, этап зборкі складаецца з мноства асобных тыпавых крокаў: выпампоўванне зыходнікаў з GitLab, падрыхтоўка залежнасцяў і 3rd-party бібліятэк, юніт-тэставанне і статычны аналіз кода, выкананне білд-сцэнара на GitLab CI, публікацыя артэфактаў у сховішча на Artifactory і генерацыя рэліз-нотаў праз наш унутраны інструмент ChangelogBuilder.
Пра тыпавыя задачы DevOps вы можаце пачытаць у іншых нашых артыкулах на Хабры: «»І«.
Мноства тыпавых вытворчых ланцужкоў утвараюць. вытворчы працэс. Стандартны падыход да апісання працэсаў - выкарыстоўваць функцыянальныя IDEF0-мадэлі.
Прыклад мадэлявання вытворчага CI-працэсу
Адмысловая ўвага мы надалі распрацоўцы тыпавых праектаў для сістэмы бесперапыннай інтэграцыі. Гэта дазволіла дабіцца уніфікацыі праектаў, вылучыўшы так званую. рэлізную схему зборак з прасоўваннямі.
Вось як гэта працуе. Усе праекты выглядаюць тыпавымі: яны ўключаюць канфігурацыю зборак, якія трапляюць у snapshot-рэпазітар на 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]Гэта этапы зборкі прадуктаў [Build], іх дэплою на тэставыя серверы [Deploy], тэсціравання [Test], прасоўвання зборак у рэлізныя рэпазітары па выніках тэсціравання [Promote], генерацыі і публікацыі ліцэнзій [License], публікацыі [Publish] на серверы абнаўленняў GUS і дастаўкі да сервераў абнаўленняў FLUS, усталёўкі і абнаўленні кампанентаў прадуктаў на інфраструктуры замоўца сродкамі Product Configuration Management [Install], а таксама збор тэлеметрыі [Telemetry] з усталяваных прадуктаў.
Акрамя іх можна вылучыць асобныя этапы: маніторынгу стану інфраструктуры [InfMonitoring], кіравання версіямі зыходнага кода [SourceCodeControl], падрыхтоўкі зборачнага асяроддзя [Prepare], кіравання праектамі [Workflow], забеспячэнні каманд сродкамі камунікацыі [Communication], сертыфікацыі прадуктаў [Certification] і забеспячэнні самадастатковасці CI-працэсаў [CISelfSufficiency] (напрыклад, незалежнасці зборак ад інтэрнэту). Дзесяткі крокаў у нашых працэсах нават не будзем разглядаць, бо яны вельмі спецыфічныя.
Будзе значна лягчэй зразумець і акінуць позіркам увесь вытворчы працэс, калі ўявіць яго ў выглядзе. тэхналагічнай карты; гэта табліца, у якую па радках запісаны асобныя вытворчыя этапы і дэкампазіраваныя крокі Мадэлі, а па слупках - апісанне таго, што робіцца на кожным этапе або кроку. Асноўны акцэнт зроблены на рэсурсах, якія забяспечваюць кожны этап, і размежаванні зон адказнасці.
Карта для нас - гэта своеасаблівы класіфікатар. Яна адлюстроўвае буйныя тэхналагічныя часткі вытворчасці прадуктаў. Дзякуючы ёй нашай камандзе аўтаматызатараў стала лягчэй узаемадзейнічаць з распрацоўшчыкамі і сумесна планаваць укараненне этапаў аўтаматызацыі, а таксама разумець, якія працавыдаткі і рэсурсы (чалавечыя і "жалезныя") для гэтага спатрэбяцца.
Унутры нашай кампаніі карта аўтаматычна генеруецца з jinja-шаблона ў выглядзе звычайнага HTML-файла, а затым выкладваецца на сервер GitLab Pages. Скрыншот з прыкладам цалкам згенераванай карты можна паглядзець .
Па кліку карцінка адкрыецца ў поўным памеры
Калі сказаць коратка, то тэхналагічная карта - гэта абагульненая карціна вытворчага працэсу, дзе адлюстраваны выразна класіфікаваныя блокі з тыпавой функцыянальнасцю.
Структура нашай тэхналагічнай карты
Карта складаецца з некалькіх частак:
- Вобласць загалоўкаў - тут знаходзіцца агульнае апісанне карты, уводзяцца базавыя паняцці, вызначаюцца асноўныя рэсурсы і вынікі вытворчага працэсу.
- Інфармацыйная панэль - тут можна кіраваць адлюстраваннем дадзеных па асобных прадуктах, прыводзіцца зводка па рэалізаваным этапах і крокам у цэлым па ўсіх прадуктах.
- Тэхналагічная карта - таблічнае апісанне тэхналагічнага працэсу. На мапе:
- прыведзены ўсе этапы, крокі і іх коды;
- дадзены кароткае і поўнае апісанні этапаў;
- пазначаны ўваходныя рэсурсы і сэрвісы, якія выкарыстоўваюцца на кожным этапе;
- пазначаны вынікі кожнага этапа і асобнага кроку;
- указана зона адказнасці па кожным этапе і кроку;
- вызначаны тэхнічныя рэсурсы, напрыклад HDD (SSD), RAM, vCPU, і чалавека-гадзіны, неабходныя для падтрымкі прац на дадзеным этапе, як на бягучы момант - факт, так і ў будучыні - план;
- для кожнага прадукта паказана, якія тэхналагічныя этапы ці крокі для яго рэалізаваны, плануюцца да ўкаранення, неактуальныя ці не рэалізаваны.
Прыняцце рашэнняў на аснове тэхналагічнай карты
Вывучыўшы карту, магчыма распачаць некаторыя дзеянні – у залежнасці ад ролі супрацоўніка ў кампаніі (кіраўнік распрацоўкі, менеджэр прадукта, распрацоўшчык ці тэстыравальнік):
- зразумець, якія этапы адсутнічаюць у рэальным прадукце ці праекце, і ацаніць неабходнасць іх укаранення;
- размежаваць зоны адказнасці паміж некалькімі аддзеламі, калі яны працуюць над рознымі этапамі;
- дамовіцца аб кантрактах на ўваходах і выхадах этапаў;
- інтэграваць свой этап работ у агульны працэс распрацоўкі;
- дакладней ацаніць запатрабаванне ў рэсурсах, якія забяспечваюць кожны з этапаў.
Рэзюмуючы ўсё вышэйсказанае
Тэхналагічная карта ўніверсальная, якая пашыраецца і лёгка падтрымліваецца. Распрацоўваць і суправаджаць апісанне працэсаў у такім выглядзе значна лягчэй, чым у строгай акадэмічнай IDEF0-мадэлі. Акрамя таго, таблічнае апісанне прасцей, звыклай і лепш структуравана, чым функцыянальная мадэль.
За тэхнічную рэалізацыю крокаў у нас адказвае адмысловая ўнутраная прылада CrossBuilder — прылада-праслойка паміж CI-сістэмамі, сэрвісамі і інфраструктурай. Распрацоўніку не трэба пілаваць свой ровар: у нашай CI-сістэме досыць запусціць адзін са скрыптоў (так званы task) прылады CrossBuilder, які правільна яго выканае з улікам асаблівасцяў нашай інфраструктуры.
Вынікі
Артыкул атрымаўся даволі доўгім, але гэта непазбежна пры апісанні мадэлявання складаных працэсаў. У канцы хочацца сцісла зафіксаваць нашы асноўныя ідэі:
- Мэта ўкаранення ідэй DevOps у нашай кампаніі – паслядоўнае зніжэнне сабекошту вытворчасці і суправаджэння прадуктаў кампаніі ў колькасных паказчыках (чалавека-гадзінах або машына-гадзінах, vCPU, RAM, Disk).
- Спосаб зніжэння агульнага сабекошту распрацоўкі - мінімізацыя кошту выканання тыпавых серыйных задач: этапаў і крокаў тэхналагічнага працэсу.
- Тыпавая задача - гэта задача, рашэнне якой аўтаматызавана поўнасцю або часткова, не выклікае цяжкасцяў у выканаўцаў і не патрабуе значных працавыдаткаў.
- Вытворчы працэс складаецца з этапаў, этапы разбіты на непадзельныя крокі, якія ўяўляюць сабой тыпавыя задачы рознага маштабу і аб'ёму.
- Ад разрозненых тыпавых задач мы дашлі да складаных тэхналагічных ланцужкоў і шматузроўневым мадэлям вытворчага працэсу, якія могуць быць апісаныя функцыянальнай IDEF0-мадэллю ці прасцейшай тэхналагічнай картай.
- Тэхналагічная карта - гэта таблічнае прадстаўленне этапаў і крокаў вытворчага працэсу. Самае галоўнае: карта дазваляе ўбачыць увесь працэс цалкам, буйнымі кавалкамі з магчымасцю іх дэталізацыі.
- На аснове тэхналагічнай карты можна ацаніць неабходнасць укаранення этапаў у тым ці іншым прадукце, размежаваць зоны адказнасці, дамовіцца аб кантрактах на ўваходах і выхадах этапаў, больш дакладна ацаніць патрэбнасць у рэсурсах.
У наступных артыкулах мы больш падрабязна раскажам аб тым, якімі тэхнічнымі інструментамі рэалізуюцца тыя ці іншыя тэхналагічныя этапы на нашай карце.
Аўтары артыкула:
- - кіраўнік аддзела аўтаматызацыі (DevOps) кампаніі Positive Technologies
- - нам. кіраўніка аддзела аўтаматызацыі (DevOps) кампаніі Positive Technologies
Крыніца: habr.com