Абмяркуем чаму CI-інструменты і CI - гэта зусім пра рознае.
Які боль CI заклікана вырашыць, адкуль узнікла ідэя, якія апошнія пацверджанні што яно працуе, як зразумець што ў вас ёсць менавіта практыка, а не проста ўсталяваны Jenkins.
Думка зрабіць даклад пра Continuous Integration з'явілася яшчэ год таму, калі я хадзіў па сумоўях шукаў працу. Пагутарыў з 10-15 кампаніямі, з іх толькі адна змагла зразумела адказаць што такое CI і растлумачыць як яны зразумелі, што ў іх гэтага няма. Астатнія ж неслі незразумелую лухту пра Jenkins 🙂 Ну вось у нас ёсць Jenkins, ён робіць зборкі, CI! За даклад пастараюся растлумачыць што ж такое Continuous Integration насамрэч і чаму Jenkins і падобныя прылады маюць вельмі слабое да гэтага стаўлення.
Дык што звычайна прыходзіць у галаву пры слове CI? Большасці людзей прыйдзе ў галаву Jenkins, Gitlab CI, Travis і да т.п.
Нават калі мы загуглім, то нам выдасць гэтыя інструменты.
Калі пытацца знаёмыя, то адразу пасля пераліку інструментаў, вам раскажуць што CI гэта калі ў вас у Pull Request на коміт адбываецца зборка і прагон тэстаў.
Continuous Integration гэта не пра прылады, не пра зборкі з тэстамі ў галінцы! Continuous Integration гэта практыка вельмі частай інтэграцыі новага кода і для яе прымянення зусім не абавязкова гарадзіць Jenkins-ы, GitLab-ы і да т.п.
Перш чым мы разбярэмся як выглядае паўнавартасны CI, давайце спачатку пагрузімся ў кантэкст людзей, якія гэта прыдумалі, і адчуем той боль, які яны спрабавалі вырашыць.
А вырашалі яны боль сумеснай працы ў камандзе!
Давайце паглядзім на прыкладах, з якімі складанасцямі сутыкаюцца распрацоўшчыкі пры каманднай распрацоўцы. Вось у нас ёсць праект, master-галінка ў git і два распрацоўшчыкі.
І пайшлі яны працаваць як усё даўно абвыклі. Узялі задачу ў тлушчы, завялі feature branch, пішуць код.
Адзін скончыў фічу хутчэй і смержыў у майстар.
Другому спатрэбілася больш часу, ён смержыўся пазней і атрымаў канфлікт. Цяпер, замест таго каб пісаць патрэбныя бізнэсу фічы, распрацоўшчык марнуе свой час і сілы на вырашэнне канфліктаў.
Чым складаней аб'яднаць сваю фічу з агульным майстрам, Тым больш часу мы на гэта трацім. І гэта я яшчэ дастаткова просты прыклад паказаў. Гэта прыклад, дзе распрацоўшчыкаў усяго 2. А ўявіце, калі 10 ці 15, ці 100 чалавек у кампаніі пішуць у адзін рэпазітар. Вы звар'яцееце ўсе гэтыя канфлікты вырашаць.
Ёсць крыху іншы выпадак. У нас ёсць майстар і некалькі распрацоўшчыкаў, якія нешта робяць.
Яны стварылі па галінцы.
Адзін смержыўся, усё добра, здаў задачу.
Другі распрацоўшчык тым часам здаў сваю задачу. Дапусцім, ён аддаў яе на раўчу. У многіх кампаніях ёсць практыка - рэўю. З аднаго боку, гэта практыка - добрая і карысная, з другога боку, гэта нас шмат у чым недзе тармозіць. Не будзем у гэта апускацца, але вось выдатны прыклад, да чаго можа прывесці крывая гісторыя з рэўю. Вы аддалі pull request на раўью. Распрацоўніку больш няма чаго рабіць. Што ён пачынае рабіць? Ён пачынае браць іншыя задачы.
За гэты час другі распрацоўшчык яшчэ нешта парабіў.
Першы выканаў трэцюю задачу.
І праз нейкі працяглы час, яго рэўю апрабавалі, і ён спрабуе смержиться. І што адбываецца? Ён ловіць вялікую колькасць канфліктаў. Чаму? Таму што пакуль яго pull request вісеў на раўчу, у кодзе ўжо шмат чаго памянялася.
Апроч гісторыі з канфліктамі, ёсць гісторыя з камунікацыямі. Пакуль у вас галінка вісіць на раўчу, пакуль яна чагосьці чакае, пакуль вы доўга пілуеце фічу, вы перастаеце адсочваць, што яшчэ ў кодавай базе вашага сэрвісу змяняецца. Магчыма, тое, што зараз вы спрабуеце вырашыць, гэта ўжо вырашылі ўчора і можна ўзяць і нейкі метад перавыкарыстоўваць. Але вы гэтага не ўбачыце, таму што вы працуеце заўсёды са састарэлай галінкай. І гэтая састарэлая галінка заўсёды прыводзіць да таго, што вам давядзецца дазваляць мерж-канфлікт.
Атрымліваецца, што калі мы працуем камандай, т. е. не адзін чалавек у рэпазітары калупаецца, а чалавек 5-10, то чым даўжэй мы не дадаем свой код у майстар, тым больш мы пакутуем таму, што на ў канчатковым выніку трэба што- то смержыць. І чым больш у нас канфліктаў, і чым з больш старой версіяй мы працуем, тым больш у нас праблем.
Сумесна нешта рабіць - гэта балюча! Мы адзін аднаму заўсёды мяшаем.
На гэтую праблему звярнулі ўвагу 20 гадоў таму. Першае згадванне аб практыцы Continuous Integration я знайшоў у экстрэмальным праграмаванні.
Экстрэмальнае праграмаванне - гэта першы agile framework. Старонка з'явілася ў 96-ым годзе. І была ідэя выкарыстоўваць нейкія практыкі праграмавання, планавання і іншага, каб распрацоўка была як мага больш гнуткай, каб мы маглі хутчэй рэагаваць на нейкія змены, патрабаванні ад нашых кліентаў. І яны 24 гады таму пачалі з гэтым сутыкацца, што калі ты робіш нешта вельмі доўга і збоку, то ты марнуеш на гэта больш часу, бо ў цябе канфлікты.
Цяпер мы разбяром словазлучэнне "Continuous Integration" па асобных словах. Калі пераводзіць у лоб, то атрымліваецца бесперапынная інтэграцыя. Але наколькі яна бесперапынная не вельмі зразумела, яна вельмі нават канечная. Але колькі яе integration таксама не вельмі відавочна.
І таму я прыводжу вам зараз цытаты з экстрэмальнага праграмавання. І мы абодва словы разбяром паасобку.
Integration - Як я ўжо сказаў, мы імкнемся да таго, каб кожны інжынер працаваў з самай актуальнай версіяй кода, каб ён свой код імкнуўся дадаваць як мага часцей у агульную галінку, каб гэта былі маленькія галінкі. Таму што калі яны вялікія, то можам у лёгкую на тыдзень затрымацца з мерж-канфліктамі. Асаблівае, калі ў нас доўгі цыкл распрацоўкі тыпу waterfall, дзе распрацоўшчык сышоў на месяц пілаваць нейкую велізарную фічу. І ён на этапе інтэграцыі затрымаецца вельмі надоўга.
Integration – гэта калі мы бярэм сваю галінку і інтэгруемся яе з майстрам, мы яе мяржым. Ёсць ультыматыўны варыянт, калі мы transbase developer, дзе мы імкнемся да таго, што мы адразу ў майстар пішам без усялякіх лішніх галінак.
Увогуле, integration - гэта ўзяць свой код і дацягнуць яго ў майстар.
Што тут маецца на ўвазе пад словам "continuous", што называецца бесперапыннасцю? Практыка мае на ўвазе, што распрацоўшчык імкнецца інтэграваць свой код як мага хутчэй. Гэта яго мэта пры выкананні любой задачы - зрабіць так, каб яго код з'явіўся ў майстру, як мага хутчэй. У ідэальным свеце распрацоўшчыкі будуць гэта рабіць кожныя некалькі гадзін. Т. е. ты бярэш маленькую задачку, мержыш яе ў майстар. Усё выдатна. Ты да гэтага імкнешся. І рабіць гэта трэба бесперапынна. Як толькі ты нешта зрабіў, ты адразу ж гэта ўганяеш у майстар.
І распрацоўшчык, які нешта робіць, з'яўляецца адказным за тое, што ён зрабіў, каб гэта працавала і нічога не зламала. Вось тут звычайна і вылазіць гісторыя з тэстамі. Мы хочам прагнаць нейкія тэсты на наш коміт, на наш мерж, каб упэўніцца, што гэта працуе. І тут вам могуць акурат дапамагчы Jenkins.
Але з гісторыямі: а давайце змены будуць невялікімі, а давайце задачы будуць невялікімі, а давайце мы задачу зробім і адразу ж паспрабуем неяк ўмяржыць яе ў майстар – вось тут ніякія Jenkins не дапамогуць. Бо Jenkins вам дапамогуць выключна запусціць тэсты.
Вы можаце абысціся і без іх. Гэта вам ніколькі не перашкодзіць. Таму што мэта практыкі - гэта мерзецца як мага часцей, каб не марнаваць вялікую колькасць часу на нейкія канфлікты ў будучыні.
Уявім, што ў нас 2020 год чамусьці без інтэрнэту. І мы лакальна працуем. У нас няма Jenkins. Гэта нармальна. Вы ўсё яшчэ можаце ўзяць і зрабіць лакальную галінку. Вы ў ёй напісалі нейкі код. Вырабілі задачу за 3-4 гадзіны. Пераключыліся на майстар, зрабілі git pull, умяржылі туды сваю галінку. Гатова. Калі вы гэта робіце часта - віншую, у вас ёсць Continuous Integration!
Якія ў сучасным свеце ёсць пруфы на тэму таго, што на гэта варта марнаваць сілы? Бо ў цэлым гэта складана. Калі вы паспрабуеце так папрацаваць, то вы зразумееце, што ў вас зараз закране нейкае планаванне, вам давядзецца больш часу надаваць дэкампазіраванню задач. Таму што калі вы будзеце рабіць man…, тыя вы смержiться не зможаце хутка і, адпаведна, патрапіце ў прасак. Практыкі ў вас ужо ня будзе.
І гэта будзе дорага. Працаваць адразу з заўтрашняга дня па Continuous Integration не атрымаецца. Вы ўсё будзеце вельмі доўга абвыкаць, вельмі доўга будзеце прывучацца дэкампазіраваць задачы, вельмі доўга будзеце прывучацца перарабляць практыку рэўю, калі яна ў вас ёсць. Таму што наша мэта, каб яно смержылася сёння. А калі вы рэўю робіце на працягу трох дзён, то ў вас праблемы і Continuous Integration у вас не атрымліваецца.
Але нейкія ў нас ёсць актуальныя пруфы зараз, якія нам кажуць, што інвеставаць у гэтую практыку мае сэнс?
Першае, што мне прыйшло ў галаву - гэта State of DevOps. Гэтае даследаванне, якое хлопцы праводзяць ужо 7 гадоў. зараз яны гэта робяць як незалежная арганізацыя, але пад Google.
І іх даследаванне ў 2018-ым годзе паказала карэляцыю паміж кампаніямі, якія імкнуцца выкарыстоўваць караткажывучыя галінкі, якія інтэгруюцца хутка, інтэгруюцца часта, у іх больш прыгожыя паказчыкі прадукцыйнасці IT.
Што гэта за паказчыкі? Гэта 4 метрыкі, якія яны здымаюць з усіх кампаніях у сваіх апытальніках: deployment frequency, lead time for changes, time to restore service, change failure rate.
І, па-першае, ёсць вось гэтая карэляцыя, мы ведаем, што кампаніі, якія мрояцца часта, у іх гэтыя метрыкі моцна лепшыя. І ў іх ёсць разбіццё кампаній на некалькі катэгорый: гэта павольныя кампаніі, якія вырабляюць нешта павольна, medium performer, high performer і эліта. Эліта - гэта Netflix, Amazon, якія супершустрые, усё робяць хутка, прыгожа і якасна.
Другая гісторыя, якая адбылася літаральна месяц таму. У Technology Radar з'явілася выдатная нататка аб Gitflow. Gitflow адрозніваецца ад усіх астатніх тым, што яго галінкі жывуць доўга. Ёсць рэлізныя галінкі, якія доўга жывуць, фічы branches, якія таксама доўга жывуць. Гэтая практыка ў Technology Radar перамясцілася ў HOLD. Чаму? Бо людзі сутыкаюцца з болем інтэграцыі.
Калі ў цябе галіна жыве вельмі доўга, яна ўстравае, пратухае, мы пачынаем марнаваць больш часу на тое, каб унесці ў яе нейкую змену.
І нядаўна аўтар Gitflow сказаў, што калі вы імкнецеся да Continuous Integration, калі вы імкнецеся да таго, што вы жадаеце каціцца як мага гушчару, то Gitflow – гэта дрэнная ідэя. Ён асобна ў артыкул дапісаў, што калі ў вас бэкенд, дзе вы можаце да гэтага імкнецца, то Gitflow для вас лішні, таму што Gitflow вас запаволіць, Gitflow вам створыць праблемы з інтэграцыяй.
Гэта не азначае, што Gitflow дрэнны і ім не трэба карыстацца. Ён для іншых выпадкаў. Напрыклад, калі вам трэба падтрымліваць некалькі версій сэрвісу, прыкладанні, т. е. дзе вам трэба сапсаваць на працягу нейкага працяглага перыяду часу.
Але калі вы пагутарыце з людзьмі, якія такія сэрвісы падтрымліваюць, тыя вы пачуеце шмат болю аб тым, што гэтая версія была 3.2, якая была 4 месяцы назад, а ў яе не патрапіў гэты фікс і зараз, каб яго занесці, трэба ўнесці кучу змен . І вось яны зноў затрымаліся, і вось яны тыдзень калупаюцца з тым, каб узяць і смержыць нейкую новую фічу.
Як Аляксандр Кавалёў правільна заўважыў у чаце, карэляцыя - гэта не роўна прычынна-следчай сувязі. Гэта так. Т. е. нейкі прамой сувязі, што калі ў вас Continuous Integration, то ўсе метрыкі будуць шыкоўнымі, не. Але ёсць станоўчая карэляцыя, што калі адно, то, хутчэй за ўсё, іншае таксама. Не факт, але хутчэй за ўсё. Гэта ўсяго толькі карэляцыя.
Накшталт бы мы ўжо нешта які робіцца, накшталт бы мы ўжо мроімся, але як зразумець, што Continuous Integration у нас усёткі ёсць, што мярымся досыць часта?
Jez Humble - гэта аўтар Handbook, Accelerate, сайта Continuous Delivery і кніжкі "Continuous Delivery". Ён прапануе вось такі тэст:
- Код інжынера пападае ў майстар штодня.
- На кожны коміт вы запускаеце unit-тэсты.
- Білд у майстры ўпаў, яго паправілі прыкладна за 10 хвілін.
Ён прапануе выкарыстоўваць такі тэст, каб упэўніцца, што практыка ў вас сапраўды ёсць.
Апошняе я знаходжу крыху спрэчным. Т. е. калі вы можаце паправіць за 10 хвілін, значыць, у вас ёсць Continuous Integration, гучыць трошкі дзіўна, на мой погляд, але ў гэтым ёсць сэнс. Чаму? Таму што, калі вы мяркуеце часта, гэта значыць, што змены ў вас маленькія. Калі маленькая змена да таго, што ў вас зламалася зборка майстра, тыя вы зможаце знайсці прыклад хутка, таму што змена маленькая. Вось у вас быў маленькі мерж, у ім змяніліся 20-30 радкоў. І, адпаведна, вы можаце хутка зразумець, у чым была прычына, таму што змены маленечкія, у вас вельмі маленькая вобласць пошуку праблемы.
І нават калі ў нас пасля рэлізу развальваецца prod, то калі ў нас есць практыка Continuous Integration, нам моцна прасцей дзейнічаць, таму што змены маленечкія. Так, гэта закране планаванне. Гэта будзе балюча. І, мусіць, самае складанае ў гэтай практыцы - гэта абвыкнуць разбіваць задачкі, т. е. як зрабіць так, каб узяць нешта і зрабіць гэта за некалькі гадзін і пры гэтым мінуць рэўю, калі яно ў вас ёсць. Рэўю - гэта асобны боль.
Unit-тэсты - гэта проста памочнік, які вам дапамагае зразумець - ці сапраўды ваша інтэграцыя прайшла паспяхова, ці сапраўды нічога не зламалася. На мой погляд, гэта таксама не зусім абавязковы пункт, бо сэнс практыкі не ў гэтым.
Гэта каротка пра Continuous Integration. Гэта ўсё, што ёсць у гэтай практыцы. Я гатовы да пытанняў.
Коратка толькі яшчэ раз падвяду вынікі:
- Continuous Integration - гэта не Jenkins, гэта не Gitlab.
- Гэта не інструмент, гэта практыка аб тым, што мы як мага часцей мяржым наш код у майстар.
- Робім мы гэта для таго, каб пазбегнуць велізарнай болі, якая ўзнікае з мержами ў будучыні, т. е. мы адчуваем маленькую боль цяпер, каб не адчуваць вялікую ў будучыні. У гэтым увесь сэнс.
- З боку праходзіць камунікацыя праз код, але я гэтага вельмі рэдка бачу, але для гэтага яна таксама думала.
пытанні
Што рабіць з недэкампазавання задачамі?
Дэкампазіраваць. У чым праблема? Можаце прывесці прыклад, што ёсць задача і яна не дэкампазіруецца?
Ёсць такія задачы, якія немагчыма дэкампазіраваць ад слова "зусім", напрыклад, тыя, якія патрабуюць вельмі глыбокай экспертызы і якія рэальна могуць вырашацца на працягу месяца да нейкага зручнага выніку.
Калі я правільна цябе зразумеў, то ёсць нейкая вялікая і складаная задача, вынік якой будзе бачны толькі праз месяц?
Так, усё дакладна. Так, ацаніць вынік можна будзе не раней як праз месяц.
Добра. У цэлым гэта не праблема. Чаму? Таму што ў дадзеным выпадку, калі мы гаворым пра галінкі, мы не гаворым пра галінку з фічай. Фічы бываюць вялікімі і складанымі. Яны могуць закранаць вялікую колькасць кампанентаў. І, магчыма, мы іх не можам зрабіць у адной галінцы поўнасцю. Гэта нармальна. Нам трэба толькі разбіць гэтую гісторыю. Калі фіча не гатовая да канца, тое гэта не азначае, што нейкія кавалкі яе кода нельга мержить. Ты дадаў, дапусцім, міграцыю і ўнутры фічы ёсць нейкія этапы. У цябе, дапусцім, ёсць этап - зрабіць міграцыю, дадаць новы метад. І ты гэтыя рэчы ўжо можаш мержыць штодзень.
Добра. Які тады ў гэтым сэнс?
Які сэнс мержыць маленькія штукі штодзень?
Да.
Калі яны ў цябе нешта зламалі, ты гэта бачыш адразу. У цябе маленькі кавалачак, які нешта зламаў, табе прасцей гэта выправіць. Сэнс у тым, што смержыць маленькі кавалачак зараз нашмат прасцей, чым смержыць нешта вялікае праз некалькі тыдняў. І трэці сэнс у тым, што ў цябе іншыя інжынеры будуць працаваць з ужо актуальнай версіяй кода. Яны будуць бачыць, што тут нейкія міграцыі дадаліся, а тут з'явіўся нейкі метад, які яны таксама, магчыма, захочуць скарыстаць. У цябе ўсе будуць бачыць, што ў цябе ў кодзе адбываецца. Менавіта дзеля гэтых трох рэчаў практыка робіцца.
Дзякуй, пытанне зачынена!
(Алег Сарока) Можна я дадам? Ты ўсё правільна сказаў, хачу толькі адну фразу дадаць.
Так.
Пры Continuous Integration код мерзецца ў агульную галінку не тады, калі фіча цалкам гатовая, а тады, калі перастаў ламацца білд. І вы смела камітэце ў майстар колькі хочаце раз у дзень. Другі аспект - калі вы не можаце па нейкай прычыне разбіць месячную задачу на задачы хаця б па тры дні, я маўчу пра тры гадзіны, значыць, у вас ёсць велізарная праблема. І той факт, што ў вас няма Continuous Integration - гэта меншае з гэтых праблем. Гэта значыць, што ў вас праблемы з архітэктурай і інжынерныя практыкі на нулі. Бо нават калі гэта research, то ў любым выпадку яго трэба афармляць у выглядзе гіпотэз ці цыклу.
Мы казалі пра 4 метрыкі, якія адрозніваюць паспяховыя кампаніі ад адсталых. Да гэтых 4 метрык яшчэ дажыць трэба. Калі ў вас сярэдняя задача робіцца месяц, то я б сканцэнтраваўся спачатку на гэтай мэтрыцы. Апусціў бы яе спачатку да 3-х дзён. І пасля гэтага пачаў думаць аб Continuous.
Я правільна зразумеў цябе, што ты думаеш, што ў цэлым укладвацца ў інжынерныя практыкі, калі ў цябе любая задача робіцца месяц, сэнсу яшчэ няма?
У цябе ёсць Continuous Integration. І там ёсць такая тэма, што ты за 10 хвілін ці фіксіш выпраўленне ці адкочваеш. Уяві, ты яго выкаціў. Прычым у цябе нават continuous deployment ты яго выкаціў на prod і толькі потым заўважыў, што нешта пайшло не так. І табе яго трэба адкаціць, а ў цябе ўжо міграцыя базы звестак адбылася. У цябе ўжо схема базы дадзеных версіі наступнай, больш за тое, яшчэ і нейкі бэкап прайшоў, яшчэ туды і дадзеныя запісаліся.
І якая ў цябе ёсць альтэрнатыва? Калі ты адкочваеш назад код, то ён ужо не можа працаваць з гэтай базай дадзеных абноўленай.
База рухаецца толькі наперад, так.
У людзей, у якіх дрэнная інжынерная практыка, хутчэй за ўсё, яны тоўстую кнігу пра… таксама не чыталі. З бэкапам што рабіць? Калі ты аднаўляешся з бэкапу, то значыць, ты губляеш дадзеныя, якія за гэты момант напрацаваліся. Напрыклад, працавалі тры гадзіны з новай версіяй базай дадзеных, туды карыстачы зарэгістраваліся. Ты адмаўляешся на стары бэкап, таму што з новай версіяй схема не працуе, адпаведна, гэтых карыстальнікаў ты страціў. А яны незадаволеныя, яны лаюцца.
Для таго каб авалодаць усім спектрам практык, якія падтрымліваюць Continuous Integration і Continuous Delivery, не дастаткова навучыцца пісаць проста …. Па-першае, іх можа стаць вельмі шмат, гэта будзе непрактычна. Плюс тамака ёсць кучу іншых практык тыпу Scientific. Ёсць такая практыка, GitHub яе папулярызаваў у адзін час. Гэта калі ў цябе адначасова выконваецца і стары код, і новы код. Гэта калі ты робіш недаробленую фічу, але яна можа вяртаць нейкае значэнне: альбо як функцыю, альбо як Rest API. Ты і новы код выконваеш, і стары код выконваеш, і параўноўваеш розніцу паміж імі. І калі розніца ёсць, то гэтую падзею лагіруеш. Такім чынам ты ведаеш, што ў цябе новая фіча гатовая выкочвацца па-над старой, калі ў цябе на працягу вызначанага часу не было разыходжанні паміж гэтымі двума.
Такіх практык сотні. Я б прапанаваў пачаць з transbase development. Яна не 100% на Continuous Integration, але практыкі адны і тыя ж, адно без другога дрэнна жыве.
Ты transbase development прывёў як прыклад, дзе можна паглядзець практыкі ці ты прапануеш людзям пачаць выкарыстоўваць transbase debelopment?
Паглядзець, т. к. выкарыстоўваць яны не змогуць. Для таго каб іх выкарыстоўваць, трэба шмат чаго пачытаць. І калі пытанне ў чалавека: "Што рабіць з фічай, якая займае месяц, то гэта азначае, што ён не чытаў пра transbase develoopment". Я і б і не раіў пакуль што. Я б параіў сканцэнтравацца выключна на тэме, як правільна архітэктурна разбіваць буйныя задачы на драбнейшыя. У гэтым і сутнасць дэкампазіцыі.
Дэкампазіцыя - гэта адзін з інструментаў архітэктара. Мы спачатку робім аналіз, потым дэкампазіцыю, потым сінтэз, потым інтэграцыю. І ў нас такім чынам усё складаецца. І да Continuous Integration трэба яшчэ дарасці праз дэкампазіцыю. Пытанні на першым этапе ўзнікаюць, а мы ўжо пра чацвёрты этап гаворым, г. зн. чым часцей рабіць інтэграцыю, тым лепш. Яе яшчэ ранавата рабіць, нядрэнна б спачатку папілаваць свой маналіт.
Трэба колькі стрэлачак і квадрацікаў намаляваць на нейкай схеме. Ты не можаш сказаць, што зараз я пакажу архітэктурную схему новага прыкладання і паказаць адзін квадрацік, усярэдзіне якога зялёная кнопка на дадатак. У любым выпадку больш будзе квадрацікаў і стрэлачак. На любой схеме, якую я бачыў, іх было больш за адзін. І дэкампазіцыя нават на ўзроўні графічнага прадстаўлення ўжо праводзіцца. Таму квадрацікі можна рабіць незалежныя. Калі не, то ў мяне вялікія пытанні да архітэктара.
Ёсць пытанне з чата: "Калі рэўю абавязкова і ідзе доўга, дзесьці дзень і больш?".
У вас праблемы з практыкай. Не павінна ісці рэўю дзень і больш. Гэта тая ж гісторыя да папярэдняга пытання, толькі крыху мякчэй. Калі рэўю ідзе дзень, значыць, хутчэй за ўсё, гэта рэўю ідзе нейкай вельмі вялікай змены. Значыць, яго трэба рабіць менш. У transbase development, які Алег парэкамендаваў, ёсць такая гісторыя, якая называецца continuous review. Яе ідэя ў тым, што мы робім настолькі маленькі pull request наўмысна, таму што мы імкнемся знікае ўвесь час і па ледзь-ледзь. І таму pull request мяняе адну абстракцыю або 10 радкоў. Дзякуючы гэтаму рэўю ў нас займае пару хвілін.
Калі рэўю займае дзень і больш, значыць, нешта не так. Па-першае, магчыма, у вас нейкія праблемы з архітэктурай. Альбо гэта вялікі кавалак кода, на 1 радкоў, напрыклад. Або ў вас настолькі складаная архітэктура, што чалавек не можа яе зразумець. Гэта праблема крыху з боку, але яе таксама давядзецца вырашаць. Магчыма, наогул не трэба рэўю. Над гэтым таксама трэба падумаць. Рэўю - гэта тая штука, якая вас тармозіць. Яна дае свае плюсы ў цэлым, але трэба зразумець, навошта вы гэта робіце. Гэта для вас спосаб хутка перадаць інфу, гэта для вас спосаб усталяваць усярэдзіне нейкіх стандартаў ці што? Навошта вам гэта? Таму што рэўю трэба рабіць альбо вельмі хуткім, альбо ўвогуле адмяніць. Гэта як transbase deveploment - гісторыя вельмі прыгожая, але толькі для спелых рабят.
Наконт 4 метрык, я б рэкамендаваў усё ж іх зняць, каб зразумець, да чаго гэта прыводзіць. Паглядзець у цыферках, паглядзець карцінку, наколькі ўсё дрэнна.
(Дзмітрый) Я гатовы ўступіць у дыскусію з гэтай нагоды з табой. Цыферкі і метрыкі - гэта ўсё класна, практыкі - гэта класна. Але трэба зразумець - ці трэба гэта бізнэсу. Ёсць бізнэсы, якім не патрэбная такая хуткасць змены. Я ведаю кампаніі, у якіх нельга праводзіць змены разоў у 15 хвілін. І не таму, што яны такія кепскія. Гэта такі жыццёвы цыкл. І каб рабіць фічу branches, фічу toggle, патрэбны глыбокія веды.
Гэта складана. Калі вы захочаце пачытаць гісторыю пра фічу toggle падрабязней, то вельмі рэкамендую . І ёсць выдатны артыкул у Марціна Фаулера пра фічы toggle: пра тое, якія бываюць тыпы, жыццёвыя цыклы і т. д. Фіча toggle - гэта складана.
І ты ўсё ж не адказаў на пытанне: "Jenkins патрэбен ці не патрэбен?"
Jenkins не патрэбен ні ў якім разе насамрэч. Калі сур'ёзна, то прылады: Jenkins, Gitlab прынясуць вам зручнасць. Вы будзеце бачыць, што зборка сабралася ці не сабралася. Яны вам могуць дапамагчы, але практыку яны вам не паставяць. Яны вам могуць толькі даць кружочак - Ок, не Ок. І тое, калі вы яшчэ тэсты пішыце, бо калі няма тэстаў, то гэта амаль бессэнсоўна. Таму патрэбен, таму што - гэта зручней, але ў цэлым можна і без яго жыць, не шмат страціце.
Т. е. калі ў вас ёсць практыкі, то значыць, што ён вам не патрабуецца?
Усё дакладна. Я раю тэст Jez Humble. Там у мяне ёсць дваякае стаўленне да апошняга пункта. Але ў цэлым, калі ў вас ёсць тры рэчы, вы мяркуеце ўвесь час, вы запускаеце тэсты на коміты ў майстры, хутка чыніце білд у майстры, то, магчыма, вам больш нічога і не трэба.
Пакуль мы чакаем пытанні ад удзельнікаў, у мяне ёсць пытанне. Мы зараз казалі пра прадуктовы код. А ці выкарыстоўваў ты для інфраструктурнага кода. Гэта такі ж код, у яго такія ж прынцыпы і такі ж жыццёвы цыкл, ці там іншыя жыццёвыя цыклы і прынцыпы? Звычайна, калі ўсе гавораць пра Continuous Integration і Development, то ўсе забываюць, што ёсць яшчэ інфраструктурны код. І апошнім часам яго ўсё больш і больш. І ці варта туды прыносіць усе гэтыя правілы?
Нават не тое, каб трэба, гэта будзе выдатна, таму што гэта сапраўды гэтак жа спросціць жыццё. Як толькі мы працуем з кодам, не са скрыптамі на bash, а ў нас есць нармальны код.
Стоп-стоп, скрыпт на bash - гэта таксама код. Не трэба чапаць маё старое каханне.
Добра, я не буду таптаць твае ўспаміны. У мяне да bash асабістая непрыязнасць. Ён ламаецца непрыгожа і страшна ўвесь час. І ламаецца часта непрадказальна, таму я яго недалюбліваю. Але добра, дапусцім, у вас ёсць код на bash. Можа быць, я сапраўды не разбіраюся і там ёсць нармальныя фрэймворкі для тэсціравання. Я проста не ў тэме. І мы атрымліваем тыя ж самыя плюсы.
Як толькі мы працуем з інфраструктурай як з кодам, мы атрымліваем усё тыя ж самыя праблемы як распрацоўшчыкі. Некалькі месяцаў таму я сутыкнуўся з сытуацыяй, што калега мне даслаў pull request на 1 000 радкоў на bash. І ты завісаеш на раўчу на 4 гадзіны. Праблемы ўзнікаюць тыя ж самыя. Гэта ўсё яшчэ код. І ўсё яшчэ сумесная праца. Мы захрасваем з pull request і застраваем з тым, што мы разрульваем тыя ж мерж-канфлікты таго ж bash, напрыклад.
Я зараз вельмі актыўна ўсю гэтую штуку гляджу на максімальна прыгожым праграмаванні інфры. Я зараз уцягнуў у інфраструктуру Pulumi. Гэта праграмаванне ў чыстым выглядзе. Там гэта яшчэ больш сімпатычна, таму што ў мяне ёсць усе магчымасці мовы праграмавання, т. е. я тымі ж самімі іфамі на роўным месцы зрабіў прыгожыя toggle і ўсё добра. Т. е. мая змена ёсць ужо ў майстру. Яго ўжо ўсё бачаць. Іншыя інжынеры аб ім у курсе. Яно ўжо на нешта паўплывала. Але пры гэтым яно ўключылася не для ўсіх інфраструктур. Яно ўключылася для маіх тэставых стэндаў, напрыклад. Таму адказваючы на тваё пытанне яшчэ раз, трэба. Яно нам, як інжынерам, якія працуюць з кодам, сапраўды гэтак жа спрашчае жыццё.
Калі ў каго яшчэ пытанні?
У мяне ёсць пытанне. Я хачу працягнуць дыскусію з Алегам. У цэлым я думаю, што ты маеш рацыю, што калі задача ў цябе робіцца месяц, то ў цябе праблема з архітэктурай, у цябе праблема з аналізам, дэкампазіцыяй, планаваннем і т. д. Але ў мяне ёсць такое адчуванне, што калі ты пачнеш спрабаваць жыць па Continuous Integration, то ты пачнеш выпраўляць болі з планаваннем, таму што ты нікуды больш ад гэтага не падзенешся.
(Алег) Так, усё так. Па працаёмкасці гэтая практыка параўнальная з любой іншай сур'ёзнай практыкай, якая змяняе культуру. Самае цяжкае ў пераадоленні - гэта звычкі, асабліва, дрэнныя звычкі. І калі для таго, каб укараніць гэтую практыку патрабуецца сур'ёзная змена звычак навакольных: developers, кіраўніцтвы, production-мэнэджара, то вас чакаюць неспадзеўкі.
Якія могуць быць неспадзеўкі? Дапусцім, вы вырашылі, што будзеце часцей рабіць інтэграцыю. І на інтэграцыі ў вас завязаны нейкія яшчэ рэчы, дапусцім, артэфакты. А ў вашай кампаніі, напрыклад, ёсць палітыка, што кожны артэфакт павінен быць нейкім чынам улічаны ў нейкай сістэме складзіравання артэфактаў. І гэта займае нейкую колькасць часу. Чалавеку трэба паставіць галачку, што ён, як рэліз-мэнэджар апрабаваў гэты артэфакт на гатоўнасць для выкладкі ў production. Калі гэта займае 5-10-15 хвілін, але пры гэтым вы робіце выкладку раз у тыдзень, то раз у тыдзень выдаткаваць паўгадзіны - гэта невялікі падатак.
Калі вы Continuous Integration робіце 10 разоў у дзень, то 10 разоў трэба памножыць на 30 хвілін. І гэта перавышае колькасць працоўнага часу гэтага рэліз-мэнэджара. Ён проста стамляецца гэта рабіць. Ёсць пастаянныя выдаткі на нейкія практыкі. І ўсё.
І вам трэба ці адмяняць гэтае правіла, каб вы больш не займаецеся такой бздурой, т. е. вы не прысвойваеце ўручную ступень на адпаведнасць чагосьці чамусьці. Вы цалкам і цалкам належыце на нейкі аўтаматызаваны набор тэстаў гатоўнасці.
І калі вам трэба ад кагосьці пруф, каб галоўны падпісаў, і вы не лезеце ў production без таго, што Вася не сказаў, што ён дазваляе і г. д. – усё гэтае глупства ўстае на шляху практык. Бо калі ёсць звязаныя ў выглядзе падатку нейкія актыўнасці, то ўсё ў 100 разоў павялічваецца. Таму зрух будзе часта ўспрыняты не ўсімі радасна. Бо звычкі людзей цяжка выпраўляць.
Калі чалавек робіць звыклую працу, ён робіць яе, практычна не задумваючыся. У яе кагнітыўная нагрузка роўная нулю. Ён проста фігачыць па гатовым, у яго ў галаве ўжо ёсць чэк-ліст, ён тысячу разоў гэта рабіў. І як толькі ты прыходзіш і кажаш яму: "Давай адменім гэтую практыку і з панядзелка ўкарэнім новую" для яго гэта становіцца магутнай кагнітыўнай нагрузкай. Прычым яна для ўсіх адразу надыходзіць.
Таму самае простае, праўда, гэтую раскошу не ўсе могуць дазволіць, але я раблю заўсёды менавіта так, гэта наступнае. Калі стартуе новы праект, то звычайна адразу ў гэты праект запіхваюцца ўсе неапрабаваныя практыкі. Пакуль праект малады, мы асабліва нічым не рызыкуем. Prod яшчэ няма, разваліць няма чаго. Таму ў якасці трэніроўкі можна выкарыстоўваць. Такі падыход працуе. Але не ўсе кампаніі маюць магчымасць стартаваць такія праекты часта. Хоць гэта таксама крыху дзіўна, таму што цяпер суцэльны digital transformation, усе павінны эксперыменты запускаць, каб угнацца за канкурэнтамі.
Тут ты ўпіраешся ў тое, што ў цябе павінна быць спачатку разуменне таго, што табе трэба рабіць. Свет не ідэальны, prod таксама не ідэальны.
Так, гэтыя рэчы ўзаемазвязаны.
У бізнэсу таксама не заўсёды ёсць разуменне, што ім трэба ісці вось туды.
Ёсць сітуацыя, пры якой увогуле ніякія змены немагчымыя. Гэта сітуацыя, калі на каманду ідзе большы ціск. Каманда даволі падвыгарэлая ўжо. Яна не мае ніякага запаснога часу на ніякія эксперыменты. Яны з раніцы да вечара пілуюць фічы. А кіраўніцтву фіч усё мала і мала. Патрабуецца ўсё больш і больш. У такой сітуацыі ўвогуле ніякія змены немагчымыя. Камандзе могуць толькі сказаць, што заўтра будзем рабіць гэтак жа, як і ўчора, проста трэба зрабіць фіч крыху больш. Ніякія пераходы ні на якія практыкі ў гэтым сэнсе немагчымыя. Гэта класічная сітуацыя, калі некалі сякеру востраць, трэба дрэвы секчы, таму сякуць тупым сякерай. Тут простых парад няма.
(Дзмітрый) Я зачытаю ўдакладненне з чата: «Але трэба вялікае пакрыццё тэстамі на розных узроўнях. Колькі часу на тэсты надаецца? Неяк задорага, шмат часу адымае».
(Алег) Гэта класічная памылка. Тэстаў павінна быць дастаткова для таго, каб у вас саміх была ўпэўненасць. Continuous Integration - гэта не такая штука, дзе спачатку 100% тэстаў ідзе і толькі потым пачынаеце гэтую практыку ўжываць. Continuous Integration зніжае на вас кагнітыўнай нагрузкі за кошт таго, што кожнае з змен, якое вы бачыце вачыма, яно настолькі відавочна, што вы разумееце - зламае яно нешта ці не, нават і без тэстаў. Вы ў галаве можаце гэта хутка пратэставаць, таму што маленькія змены. Нават калі ў вас толькі ручныя тэсціроўшчыкі, ім таксама прасцей. Вы выкацілі і сказалі: "Паглядзі, нічога не зламалася?". Яны праверылі і сказалі: "Не, нічога не зламалася". Таму што тэсціроўшчык ведае куды глядзець. У вас адзін коміт звязаны з адным фрагментам кода. І гэта эксплоіруецца канкрэтнымі паводзінамі.
Тут ты, вядома, падфарбаваў.
(Дзмітрый) Тут я не пагаджуся. Ёсць практыка - распрацоўка праз тэсціраванне, якая якраз ад гэтага выратуе.
(Алег) Вось, я да гэтага яшчэ не дайшоў. Першая ілюзія - гэта тое, што трэба пісаць менавіта 100% тэстаў ці не трэба наогул займацца Continuous Integration. Гэта не праўда. Гэта дзве паралельныя практыкі. І яны наўпрост не залежаць. Ваша пакрыццё тэстамі павінна быць аптымальным. Аптымальным - гэта значыць, што вы самі ўпэўненыя ў тым, што тая якасць майстра, у якім застаўся пасля комміта ваш майстар, дазваляе вам з упэўненасцю націснуць кнопку «Deploy» увечар у пятніцу ў п'яным выглядзе. Як вы гэтага дабіваецеся? Праз рэўю, праз пакрыццё, праз добры маніторынг.
Добры маніторынг - неадрозны ад тэстаў. Калі вы тэсты запускаеце адзін раз на pre prod, то яны адзін раз правяраюць усе вашыя прыстасаваныя сцэнары і ўсё. А калі вы іх у бясконцым цыкле запускаеце, то гэта ваша разгорнутая сістэма маніторынгу, якая бясконца ўсё тэстуе - упала ці не ўпала. У гэтым выпадку розніца толькі ў аднаразовасці ці шматразовасці. Вельмі добры набор тэстаў …, якія запускаюцца бясконца, гэта маніторынг. І правільны маніторынг і мусіць быць такім.
І таму як менавіта вы дасягнеце гэты стан, калі вы ў пятніцу ўвечар задэплоіцеся і сыходзьце дадому, гэта іншае пытанне. Можа быць, вы проста смелы адмарозак.
Давай таму крыху вернемся да Continuous Integration. Мы крыху ў іншую складаную практыку ўцяклі.
І другая ілюзія, што MVP, кажуць, трэба хутка рабіць, таму там тэсты ўвогуле не патрэбныя. Не зусім так. Справа ў тым, што калі вы ў MVP пішыце user story, то распрацоўваць яе можна альбо на шары, т. е. пачуў, што ёсць нейкая user story і адразу кадаваць яе пабег, альбо працаваць па TDD. І па TDD, як паказвае практыка, атрымліваецца не даўжэй, т. е. тэсты - гэта пабочны эфект. Практыка TDD заключаецца не ў тым, каб тэсціраваць. Нягледзячы на тое, што завецца Test Driven Development, тамака гаворка наогул не аб тэстах. Гэта таксама хутчэй архітэктурны падыход. Гэта падыход, як пісаць менавіта тое, што трэба, і не пісаць тое, што ня трэба. Гэтая практыка па факусоўцы увагі на наступную ітэрацыю вашага развіцця думкі ў плане стварэння архітэктуры прыкладання.
Таму гэтых ілюзіяў не так проста пазбавіцца. MVP і тэсты не супярэчаць адно аднаму. Нават, хутчэй, наадварот, калі вы MVP робіце па практыцы TDD, тыя вы гэта зробіце лепш і хутчэй, чым, калі наогул без практыкі, а на шары.
Гэта вельмі невідавочная і складаная думка. Калі ты чуеш, што зараз я буду пісаць яшчэ тэсты і пры гэтым я нешта зраблю хутчэй, яно гучыць абсалютна неадэкватна.
(Дзмітрый) Тут многія, калі называюць MVP, гэта народу лянота пісаць нешта нармальнае. І гэта ўсё ж розныя рэчы. Не трэба MVP ператвараць у нейкую дрэнную штуку, якая не працуе.
Так-так, ты маеш рацыю.
А потым раптам MVP у prod.
Назаўжды.
А TDD гучыць вельмі нязвыкла, калі слухаеш, што ты пішаш тэсты і быццам здзяйсняеш больш працы. Гэта гучыць вельмі дзіўна, але насамрэч гэта так атрымліваецца хутчэй і сімпотней. Калі ты пішаш тэст, то ўжо ў галаве ты шмат думаеш аб тым, які код і як будзе выклікацца, а таксама якія паводзіны мы ад яго чакаем. Ты не проста кажаш, што я напісаў нейкую функцыю, і яна нешта робіць. Ты спачатку падумаў, што ў яе вось вось такія ўмовы, яна вось так будзе выклікацца. Ты гэта пакрываеш тэстамі і з гэтага ты разумееш, як у цябе будуць выглядаць інтэрфейсы ўсярэдзіне твайго кода. Гэта вельмі моцна ўплывае на архітэктуру. У цябе код аўтаматычна становіцца больш модульным, таму што ты спачатку спрабуеш зразумець, як ты яго будзеш тэсціраваць, а толькі потым яго пішаш.
У мяне з TDD атрымалася так, што я ў нейкі момант наймаў ментара па Ruby, калі я яшчэ быў праграмістам на Ruby. І ён кажа: "Давай ты будзеш рабіць па TDD". Я і думаю: «Блін, зараз нешта яшчэ пісаць дадаткова». І мы з ім дамовіліся, што я буду цягам двух тыдняў увесь код працоўны на Python пісаць па TDD. Праз два тыдні я зразумеў, што назад я ўжо не хачу. За два тыдні спрабуючы ўсюды гэта прымяняць, ты разумееш, наколькі табе стала прасцей нават проста думаць. Але гэта невідавочна, таму я ўсім рэкамендую, што, калі ў вас ёсць адчуванне, што TDD - гэта складана, доўга і лішняе, паспрабуйце прытрымлівацца гэтаму ўсяго два тыдні. Мне двух хапіла для гэтага.
(Дзмітрый) Мы можам гэтую думку разгарнуць з пункту гледжання эксплуатацыі інфраструктуры. Перш чым мы нешта новае запускаем, мы робім маніторынг, а потым запускаем. У гэтым выпадку ў нас маніторынг становіцца нармальным тэсціраваннем. І ёсць распрацоўка праз маніторынг. Але амаль усе кажуць, што гэта доўга, мне лянота, я зрабіў чарнавік часовы. Калі мы зрабілі нармальна маніторынг, мы разуменнем стан CI сістэмы. А ў CI сістэме шмат маніторынгу. Мы разумеем стан сістэмы, мы разумеем, што ў яе ўнутры. І падчас распрацоўкі мы якраз робім сістэму, каб яна прыйшла да патрэбнага стану.
Гэтыя практыкі вядомыя даўно. Мы гады 4 таму гэта абмяркоўвалі. Але за 4 гады амаль нічога не змянілася.
Але гэтай ноце афіцыйную дыскусію прапаную заканчваць.
Відэа (устаўлены як медыяэлемент, але чамусьці не працуе):
Крыніца: habr.com