Мы ў GitLab апрацоўваем выпраўленні ПА двума спосабамі - "ручкамі" і аўтаматычна. Чытайце далей аб працы release manager па стварэнні і дастаўцы важных абнаўленняў з дапамогай аўтаматычнага разгортвання на gitlab.com, а таксама выпраўленняў для карыстальнікаў, якія працуюць са сваімі ўстаноўкамі.
Рэкамендую паставіць напамін на сваіх разумных гадзінах: кожны месяц 22 чысла карыстачы, якія працуюць з GitLab на сваіх магутнасцях, могуць убачыць абнаўленні актуальнай версіі нашага прадукта. У штомесячным выпуску можна знайсці новыя функцыі, развіццё ўжо існуючых, а таксама часта можна ўбачыць канчатковы вынік запытаў, адпраўленых супольнасцю, на інструментар або зліццё.
Але, як паказвае практыка, распрацоўка ПЗ рэдка бывае без заган. Пры выяўленні памылкі ці ўразлівасці ў сістэме бяспекі, release manager у камандзе дастаўкі стварае выпраўленне для нашых карыстачоў са сваімі ўсталёўкамі. Gitlab.com абнаўляецца падчас CD. Мы называем гэты працэс CD аўтаматычным разгортваннем, каб не было змешвання з функцыяй CD у GitLab. Гэты працэс можа ўключаць прапановы з запытаў на зліццё, адпраўленых карыстальнікамі, кліентамі і нашай унутранай камандай распрацоўкі, так што рашэнне сумнай праблемы выпуску выпраўленняў вырашаецца двума вельмі моцна якія адрозніваюцца спосабамі.
«Мы штодня забяспечваем разгортванне за ўсё, што зрабілі распрацоўшчыкі, на ўсіх акружэннях, перш чым выкаціць гэта на GitLab.com», тлумачыць , старшы тэхнічны менеджэр інфраструктурнага аддзела. «Успрымайце выпускі для сваіх установак, як здымкі для разгортвання gitlab.com, для якіх мы дадалі асобныя дзеянні па стварэнні пакета, каб нашы карыстачы маглі выкарыстаць яго для ўсталёўкі на сваіх магутнасцях..
Незалежна ад памылкі ці ўразлівасці, кліенты gitlab.com атрымаюць выпраўленні неўзабаве пасля іх публікацыі, што з'яўляецца перавагай аўтаматычнага працэсу CD. Выпраўленні для карыстачоў са сваімі ўсталёўкамі патрабуюць асобнай падрыхтоўкі, выкананай release manager.
Каманда дастаўкі ўзмоцнена працуе над аўтаматызацыяй большасці працэсаў, звязаных са стварэннем выпускаў для скарачэння (mean time to production, г.зн. часу, затрачанага на вытворчасць), прамежку часу ад апрацоўкі запыту на зліццё распрацоўшчыкам да разгортвання на gitlab.com.
«Мэта каманды дастаўкі - пераканацца, што мы можам працаваць хутчэй, як кампанія, ці, па меншай меры, паскорыць працу людзей па дастаўцы, дакладна?», кажа Marin.
Як кліенты gitlab.com, так і карыстачы сваіх усталёвак атрымліваюць выгаду ад намаганняў каманды дастаўкі па скарачэнні часу цыклу і паскарэнню разгортвання. У гэтым артыкуле мы растлумачым падабенства і адрозненне паміж гэтымі двума спосабамі. , а таксама апішам, як наша каманда дастаўкі рыхтуе выпраўленні для карыстальнікаў, якія працуюць на сваіх магутнасцях, а таксама як забяспечваецца актуальнасць gitlab.com з дапамогай аўтаматычнага разгортвання.
Што робіць release manager?
Члены каманды штомесяц нашых выпускаў для карыстальнікаў на сваіх магутнасцях, у тым ліку выпраўленні і выпускі бяспекі, якія могуць адбывацца паміж выпускамі. Таксама яны адказваюць за пераход кампаніі на аўтаматычнае, бесперапыннае разгортванне.
Выпускі для ўстаноўкі на сваіх магутнасцях, а таксама выпускі gitlab.com выкарыстоўваюць падобныя працоўныя працэсы, але працуюць у розны час, тлумачыць Marin.
У першую чаргу release manager, незалежна ад тыпу выпуску, забяспечвае даступнасць і бяспеку GitLab з моманту запуску дадатку на gitlab.com, уключаючы гарантыю таго, што аднолькавыя праблемы не трапяць у інфраструктуру кліентаў са сваімі магутнасцямі.
Як толькі ў GitLab памылка ці ўразлівасць пазначаецца выпраўленай, release manager павінен ацаніць, што яна трапіць у выпраўленні ці абнаўленні бяспекі для карыстачоў са сваімі ўсталёўкамі. Калі ён вырашыць, што памылка ці ўразлівасць заслугоўваюць абнаўленні - пачынаецца падрыхтоўчая праца.
Release manager павінен вырашыць, ці рыхтаваць выпраўленне, ці калі яго разгортваць - і гэта моцна залежыць ад кантэксту сітуацыі,а пакуль машыны не так добра кіруюцца з кантэкстам, як людзі», кажа Marin.
Усё наконт выпраўленняў
Што такое выпраўленні, і чаму яны нам патрэбныя?
Release manager прымае рашэнне аб выпуску выпраўленні ў залежнасці ад сур'ёзнасці памылкі.
Памылкі адрозніваюцца ў залежнасці ад іх сур'ёзнасці. Так памылкі S4 ці S3 могуць быць стылістычнымі, напрыклад зрушэнне пікселя ці значка. Гэта не менш важна, аднак тут няма асаблівага ўплыву на нечы працоўны працэс, а значыць верагоднасць таго, што выпраўленне будзе створана для такіх памылак S3 ці S4, малая, тлумачыць Marin.
Аднак уразлівасці S1 або S2 азначаюць, што карыстач не павінен абнаўляцца да апошняй версіі, ці ёсць значная памылка, якая ўплывае на працоўны працэс карыстача. Калі такія трапляюць у трэкер - шматлікія карыстачы сутыкнуліся з імі, таму release manager адразу ж пачынае падрыхтоўку выпраўлення.
Як толькі выпраўленне для ўразлівасцяў S1 ці S2 гатова, release manager запускае выпуск выпраўлення.
Да прыкладу выпраўленне GitLab 12.10.1 было створана пасля таго, як выявіліся некалькі блакавальных праблем, а распрацоўнікі ўхілілі асноўную праблему, якая прыводзіла да іх. Release manager правёў ацэнку правільнасці прысвоеных узроўняў сур'ёзнасці, а пасля пацверджання быў запушчаны працэс выпуску выпраўлення, які быў гатовы на працягу сутак пасля выяўлення блакавальных праблем.
Калі назапашваецца шмат S4, S3 і S2 – release manager глядзіць кантэкст для вызначэння тэрміновасці выпуску выпраўлення, а пры дасягненні некаторага іх ліку – яны ўсё аб'ядноўваюцца і выпускаюцца. Выпраўленні ці абнаўленні бяспекі пасля выпуску коратка апісваюцца ў паведамленнях блога.
Як release manager стварае выпраўленні
Мы ўжываем GitLab CI і іншыя функцыі, напрыклад наш ChatOps, для стварэння выпраўленняў. Release manager запускае выпуск выпраўлення шляхам актывацыі каманды ChatOps на нашым унутраным канале #releases у Slack.
/chatops run release prepare 12.10.1ChatOps працуе ў Slack, каб актываваць розныя падзеі, якія затым апрацоўвае і выконвае GitLab. Напрыклад, каманда дастаўкі правяла настройку ChatOps для аўтаматызацыі розных рэчаў для выпуску выпраўленняў.
Як толькі release manager запускае каманду ChatOps у Slack, астатняя праца адбываецца аўтаматычна ў GitLab з выкарыстаннем CICD. Паміж ChatOps у Slack і GitLab падчас выпуску адбываецца двухбаковы абмен дадзенымі, паколькі release manager актывуе некаторыя з асноўных этапаў працэсу.
На відэа ніжэй прадстаўлены тэхнічны працэс падрыхтоўкі выпраўлення для GitLab.
Як уладкована аўтаматычнае разгортванне gitlab.com
Сам працэс і прылады, якія выкарыстоўваюцца пры абнаўленні gitlab.com, падобныя на такія, якія выкарыстоўваюцца пры стварэнні выпраўленняў. Абнаўленне gitlab.com патрабуе менш ручной працы з пункта гледжання release manager.
Замест запуску разгортвання з выкарыстаннем ChatOps мы выкарыстоўваем функцыі CI, напрыклад , з якімі release manager можа запланаваць выкананне пэўных дзеянняў у патрабаваны час. Замест ручнога працэсу ёсць канвеер, які запускаецца перыядычна адзін раз у гадзіну, які спампоўвае занесеныя новыя змены ў праектах GitLab, пакуе іх і плануе разгортванне, а таксама аўтаматычна запускаецца тэставанне, QA і іншыя неабходныя крокі.
"Такім чынам, мы маем шмат разгортванняў, запушчаных у розных асяродках, да gitlab.com, а пасля таго, як гэтыя асяроддзі будуць у добрым стане, і тэставанне пакажа добрыя вынікі, release manager запускае дзеянні па разгортванні gitlab.com", распавядае Marin.
Тэхналогія CICD для падтрымкі абнаўленняў gitlab.com аўтаматызуе ўвесь працэс да моманту, калі release manager павінен рукамі запускаць разгортванне вытворчага асяроддзя на gitlab.com.
Marin падрабязна распавядае аб працэсе абнаўлення gitlab.com на відэа ніжэй.
Што яшчэ робіць каманда дастаўкі
Асноўнае адрозненне паміж працэсамі абнаўлення gitlab.com і выпускам выпраўленняў для кліентаў на сваіх магутнасцях складаецца ў тым, што апошні працэс патрабуе больш чакай і большай колькасці ручной працы ад release manager.
"Часам мы адкладаем выпуск выпраўленняў для кліентаў са сваімі ўстаноўкамі з-за перададзеных праблем, праблем з інструментамі, а таксама таму, што ёсць шмат нюансаў, якія трэба ўлічваць пры выпуску адзінага выпраўлення", кажа Marin.
Адна з кароткатэрміновых мэт каманды дастаўкі - паменшыць аб'ёмы ручной працы са боку release manager для паскарэння выпуску. Каманда працуе над спрашчэннем, аптымізацыяй і аўтаматызацыяй працэсу выпуску, што дапаможа хутчэй пазбавіцца ад выпраўленняў для праблем з нізкім узроўнем сур'ёзнасці (S3 і S4, заўв. перакладчыка). Арыентацыя на хуткасць - ключавы паказчык прадукцыйнасці: трэба памяншаць MTTP - час, з прыёму запыту на зліццё і да разгортвання выніку на gitlab.com - з бягучых 50 гадзін да 8 гадзін.
Каманда дастаўкі таксама працуе над пераходам gitlab.com на інфраструктуру на аснове Kubernetes.
NB рэдактара: Калі вы ўжо чулі пра тэхналогію Kubernetes (а я нават і не сумняваюся, што чулі), але яшчэ не памацалі яе рукамі, рэкамендую паўдзельнічаць у анлайн-інтэнсіўах , які пройдзе 28-30 верасня, і , які пройдзе 14-16 кастрычніка. Гэта дазволіць вам упэўнена арыентавацца ў тэхналогіі і працаваць з ёй.
Гэта два падыходу, якія маюць адну і тую ж мэту: хуткая дастаўка абнаўленняў, як для gitlab.com, так і для кліентаў на сваіх магутнасцях.
Ёсць ідэі і рэкамендацыі для нас?
Кожны можа прыняць удзел у распрацоўцы GitLab, мы вітаем водгукі ад нашых чытачоў. Калі ў вас ёсць ідэі для нашай каманды дастаўкі - не саромейцеся з паметкай team: Delivery.
Крыніца: habr.com