Нека обсъдим защо CI инструментите и CI са напълно различни неща.
Каква болка е предназначена да разреши CI, откъде идва идеята, какви са последните потвърждения, че работи, как да разберете, че имате практика, а не просто сте инсталирали Jenkins.
Идеята да направя репортаж за непрекъсната интеграция се появи преди година, когато ходех на интервюта и търсех работа. Говорих с 10-15 компании, само една от тях успя ясно да отговори какво е CI и да обясни как са разбрали, че го нямат. Останалите говореха неразбираеми глупости за Дженкинс :) Е, имаме Дженкинс, прави компилации, CI! По време на доклада ще се опитам да обясня какво всъщност представлява непрекъснатата интеграция и защо Jenkins и подобни инструменти имат много слаба връзка с това.
И така, какво обикновено идва на ум, когато чуете думата CI? Повечето хора ще си помислят за Jenkins, Gitlab CI, Travis и т.н.
Дори да го потърсим в Google, ще ни даде тези инструменти.
Ако сте запознати с питането, тогава веднага след изброяване на инструментите, те ще ви кажат, че CI е, когато създавате и изпълнявате тестове в Pull Request за ангажиране.
Непрекъснатата интеграция не е свързана с инструменти, не е сглобки с тестове в клон! Непрекъснатата интеграция е практиката на много често интегриране на нов код и за да я използвате изобщо не е необходимо да ограждате Jenkins, GitLab и т.н.
Преди да разберем как изглежда пълноценният CI, нека първо се потопим в контекста на хората, които са го измислили и да усетим болката, която те се опитват да разрешат.
И те решиха болката от работата заедно като екип!
Нека да разгледаме примери за трудностите, пред които са изправени разработчиците, когато работят в екипи. Тук имаме проект, главен клон в git и двама разработчици.
И се заловиха за работа, както всички отдавна бяха свикнали. Взехме задача в голямата схема на нещата, създадохме клон на функции и написахме кода.
Единият завърши функцията по-бързо и я обедини в главния.
На второто му трябваше повече време, по-късно се сля и завърши с конфликт. Сега, вместо да пише функциите, от които се нуждае бизнесът, разработчикът прекарва времето и енергията си в разрешаване на конфликти.
Колкото по-трудно е да комбинирате вашата функция с общ майстор, толкова повече време отделяме за това. И показах това с доста прост пример. Това е пример, при който има само 2 разработчици.Представете си, че 10 или 15 или 100 души в една компания пишат в едно хранилище. Ще полудеете да разрешите всички тези конфликти.
Има малко по-различен случай. Имаме майстор и някои разработчици, които правят нещо.
Създадоха клонка.
Единият умря, всичко беше наред, премина задачата.
Вторият разработчик междувременно предаде задачата си. Да кажем, че го е изпратил за преглед. Много компании имат практика, наречена преглед. От една страна, тази практика е добра и полезна, от друга ни забавя в много отношения. Няма да навлизаме в това, но ето един чудесен пример за това до какво може да доведе една лоша история с рецензии. Изпратихте заявка за изтегляне за преглед. Разработчикът няма какво повече да направи. Какво започва да прави? Той започва да поема други задачи.
През това време вторият разработчик направи нещо друго.
Първият изпълни третата задача.
И след известно време прегледът му беше тестван и той се опитва да се примири. Е, какво става? Той улавя огромен брой конфликти. Защо? Защото докато заявката му за изтегляне висеше в прегледа, много неща вече бяха променени в кода.
В допълнение към историята с конфликти, има история с комуникации. Докато нишката ви виси на преглед, докато чака нещо, докато работите върху функция дълго време, спирате да следите какво друго се променя в кодовата база на вашата услуга. Може би това, което се опитвате да разрешите сега, вече е било решено вчера и можете да вземете някакъв метод и да го използвате повторно. Но няма да видите това, защото винаги работите с остарял клон. И този остарял клон винаги води до това, че трябва да разрешите конфликт на сливане.
Оказва се, че ако работим като екип, т.е. не един човек рови в хранилището, а 5-10 души, тогава колкото по-дълго не добавяме нашия код към главния, толкова повече страдаме, защото в крайна сметка имаме нужда нещо, след което го обединете. И колкото повече конфликти имаме и с колкото по-стара версия работим, толкова повече проблеми имаме.
Да правим нещо заедно е болезнено! Винаги си пречим.
Този проблем беше забелязан преди повече от 20 години. Намерих първото споменаване на практиката на непрекъсната интеграция в екстремното програмиране.
Extreme Programming е първата гъвкава рамка. Страницата се появява през 96 г. И идеята беше да използваме някакви практики за програмиране, планиране и други неща, така че разработката да бъде възможно най-гъвкава, за да можем бързо да реагираме на всякакви промени или изисквания на нашите клиенти. И те започнаха да се сблъскват с това преди 24 години, че ако правите нещо много дълго време и отстрани, тогава отделяте повече време за това, защото имате конфликти.
Сега ще анализираме фразата „Непрекъсната интеграция“ поотделно. Ако го преведем директно, получаваме непрекъсната интеграция. Но доколко непрекъснато е не е много ясно; много е прекъснато. Но колко много интеграция има също не е много очевидно.
И затова сега ви давам цитати от Extreme Programming. И ние ще анализираме двете думи поотделно.
Интеграция - Както вече казах, ние се стремим да гарантираме, че всеки инженер работи с най-актуалната версия на кода, така че той да се стреми да добавя своя код възможно най-често към общ клон, така че това да са малки клонове. Защото, ако са големи, тогава лесно можем да заседнем с конфликти на сливане за една седмица. Това е особено вярно, ако имаме дълъг цикъл на разработка, като водопад, при който разработчикът си отиде за месец, за да изреже някаква огромна функция. И той ще остане на етапа на интеграция много дълго време.
Интеграцията е, когато вземем нашия клон и го интегрираме с главния, ние го сливаме. Има крайна опция, когато сме трансбазов разработчик, където се стремим да гарантираме, че незабавно пишем на главния без допълнителни разклонения.
Като цяло интегрирането означава да вземете вашия код и да го плъзнете в главния.
Какво се разбира тук под думата „непрекъснат“, какво се нарича непрекъснатост? Практиката предполага, че разработчикът се стреми да интегрира своя код възможно най-бързо. Това е неговата цел, когато изпълнява всяка задача - да вкара кода си в master възможно най-бързо. В един идеален свят разработчиците биха правили това на всеки няколко часа. Тоест взимаш малък проблем и го сливаш в главния. Всичко е страхотно. Това е, към което се стремите. И това трябва да се прави непрекъснато. Щом направиш нещо, веднага го вкарваш в мастера.
И разработчикът, който прави нещо, е отговорен за това, което е направил, за да работи и да не счупи нищо. Това е мястото, където обикновено излиза историята на теста. Искаме да проведем някои тестове на нашия комит, на нашето сливане, за да сме сигурни, че работи. И тук Дженкинс може да ви помогне.
Но с истории: нека направим промените малки, нека оставим задачите да бъдат малки, нека направим проблем и веднага се опитаме да го вградим по някакъв начин в главния - тук Дженкинс няма да помогне. Защото Дженкинс ще ви помогне само да изпълнявате тестове.
Можете и без тях. Това изобщо няма да ви нарани. Защото целта на практиката е да се измерва възможно най-често, за да не се губи много време за евентуални конфликти в бъдеще.
Нека си представим, че по някаква причина сме през 2020 г. без интернет. И ние работим на местно ниво. Ние нямаме Дженкинс. Това е добре. Все още можете да продължите и да направите локален клон. Написахте някакъв код в него. Изпълнихме задачата за 3-4 часа. Превключихме на master, направихме git pull и сляхме нашия клон там. Готов. Ако правите това често, поздравления, имате непрекъсната интеграция!
Какви доказателства в съвременния свят има, че си струва да изразходвате енергия? Защото като цяло е трудно. Ако се опитате да работите по този начин, ще разберете, че част от планирането сега ще бъде засегнато, ще трябва да отделите повече време за разлагане на задачи. Защото ако направиш човек..., тогава няма да можеш да се примириш бързо и съответно ще си навлечеш неприятности. Вече няма да имате практика.
И ще бъде скъпо. Няма да е възможно да работите веднага от утре с помощта на непрекъсната интеграция. Ще ви отнеме много време, за да свикнете с това, ще ви отнеме много време, за да свикнете с декомпозирането на задачи, ще ви отнеме много време, за да свикнете да повторите практиката за преглед, ако имате такава . Защото нашата цел е днес да се стопи. И ако направите преглед в рамките на три дни, тогава имате проблеми и непрекъснатата интеграция не работи за вас.
Но имаме ли уместни доказателства в момента, които ни казват, че инвестирането в тази практика има смисъл?
Първото нещо, което ми хрумна беше State of DevOps. Това е проучване, което момчетата провеждат в продължение на 7 години. Сега го правят като независима организация, но под ръководството на Google.
И тяхното проучване от 2018 г. показа връзка между компании, които се опитват да използват краткотрайни клонове, които се интегрират бързо, интегрират се често и имат по-добри показатели за ИТ ефективност.
Какви са тези показатели? Това са 4 показателя, които те вземат от всички компании в своите въпросници: честота на внедряване, време за изпълнение на промените, време за възстановяване на услугата, процент на неуспешни промени.
И първо, има тази връзка, знаем, че компаниите, които измерват често, имат много по-добри показатели. И те имат разделение на компаниите в няколко категории: това са бавни компании, които произвеждат нещо бавно, средно производителни, високо производителни и елитни. Елитът са Netflix, Amazon, които са супер бързи, правят всичко бързо, красиво и ефективно.
Втората история, която се случи само преди месец. Technology Radar има страхотна статия за Gitflow. Gitflow е различен от всички останали по това, че неговите клонове са дълготрайни. Има клонове за освобождаване, които живеят дълго време, и клонове с функции, които също живеят дълго време. Тази практика в Technology Radar се премести на HOLD. Защо? Защото хората се сблъскват с болката от интеграцията.
Ако вашият клон живее много дълго време, той засяда, загнива и ние започваме да прекарваме повече време, опитвайки се да направим някаква промяна в него.
И наскоро авторът на Gitflow каза, че ако целта ви е непрекъсната интеграция, ако целта ви е да искате да се въртите възможно най-често, тогава Gitflow е лоша идея. Той отделно добави към статията, че ако имате бекенд, където можете да се стремите към това, тогава Gitflow е излишен за вас, защото Gitflow ще ви забави, Gitflow ще ви създаде проблеми с интеграцията.
Това не означава, че Gitflow е лош и не трябва да се използва. За други поводи е. Например, когато трябва да поддържате няколко версии на услуга или приложение, т.е. когато имате нужда от поддръжка за дълъг период от време.
Но ако говорите с хора, които поддържат такива услуги, ще чуете много болка за факта, че тази версия беше 3.2, която беше преди 4 месеца, но тази корекция не беше включена в нея и сега, за да я направим, трябва да направите куп промени. И сега те отново са блокирани и сега се занимават цяла седмица, опитвайки се да внедрят някаква нова функция.
Както Александър Ковалев правилно отбеляза в чата, корелацията не е същата като причинно-следствената връзка. Това е вярно. Тоест няма директна връзка, че ако имате непрекъсната интеграция, тогава всички показатели ще бъдат страхотни. Но има положителна корелация, че ако единият е един, най-вероятно и другият е такъв. Не е факт, но най-вероятно. Това е просто корелация.
Изглежда, че вече правим нещо, изглежда, че вече се сливаме, но как да разберем, че все още имаме непрекъсната интеграция, че се сливаме доста често?
Jez Humble е автор на Handbook, Accelerate, уебсайта Continuous Delivery и книгата Continuous Delivery. Той предлага този тест:
- Кодът на инженера стига до капитана всеки ден.
- За всеки комит изпълнявате модулни тестове.
- Изграждането в мастера падна, оправиха го за около 10 минути.
Той предлага да използвате тест като този, за да сте сигурни, че имате достатъчно практика.
Намирам последното за малко противоречиво. Тоест, ако можете да го оправите за 10 минути, значи имате Continuous Integration, звучи малко странно според мен, но има смисъл. Защо? Защото ако замръзвате често, това означава, че промените ви са малки. Ако малка промяна означава, че основната ви компилация е повредена, можете бързо да намерите пример, защото промяната е малка. Тук имаше малко сливане, 20-30 реда в него се промениха. И съответно можете бързо да разберете каква е причината, защото промените са малки, имате много малка област за търсене на проблема.
И дори ако нашата продукция се разпадне след издаването, тогава ако имаме практиката на непрекъсната интеграция, за нас е много по-лесно да действаме, защото промените са малки. Да, това ще повлияе на планирането. Това ще боли. И вероятно най-трудното нещо в тази практика е да свикнеш да разбиваш задачите, тоест как да го направиш, така че да вземеш нещо и да го направиш за няколко часа и в същото време да преминеш преглед, ако имаш един. Прегледът е отделна болка.
Единичните тестове са само помощник, който ви помага да разберете дали вашата интеграция е била успешна и дали нищо не е счупено. Според мен това също не е съвсем задължително, защото това не е смисълът на практиката.
Това е кратко въведение в непрекъснатата интеграция. Това е всичко за тази практика. Готов съм за въпроси.
Ще обобщя отново накратко:
- Непрекъснатата интеграция не е Jenkins, не е Gitlab.
- Това не е инструмент, практика е да сливаме нашия код в главния възможно най-често.
- Правим това, за да избегнем огромната болка, която възниква при сливания в бъдеще, тоест изпитваме малка болка сега, за да не изпитваме повече в бъдеще. Това е целият смисъл.
- Отстрани има комуникация чрез код, но много рядко го виждам, но това е и предназначението му.
Въпроси
Какво да правим с неразложените задачи?
Разлагам. Какъв е проблемът? Можеш ли да дадеш пример, че има задача и не е декомпозирана?
Има задачи, които не могат да бъдат разложени от думата „напълно“, например такива, които изискват много задълбочена експертиза и които всъщност могат да бъдат решени в рамките на един месец, за да се постигне някакъв смилаем резултат.
Ако ви разбирам правилно, значи има някаква голяма и сложна задача, резултатът от която ще се види едва след месец?
Да, така е. Да, ще бъде възможно да се оцени резултатът не по-рано от месец.
Глоба. Като цяло това не е проблем. Защо? Защото в случая, когато говорим за клонки, не говорим за клонка с особеност. Функциите могат да бъдат големи и сложни. Те могат да засегнат голям брой компоненти. И може би не можем да ги направим напълно в един клон. Това е добре. Просто трябва да разбием тази история. Ако дадена функция не е напълно готова, това не означава, че някои части от нейния код не могат да бъдат обединени. Добавихте, да речем, миграция и във функцията има някои етапи. Да приемем, че имате етап - направете миграция, добавете нов метод. И вече можете да измервате тези неща всеки ден.
Глоба. Какъв е смисълът тогава?
Какъв е смисълът да убиваш малки неща всеки ден?
Да.
Счупят ли нещо, веднага го виждаш. Имате малко парче, което е счупило нещо, по-лесно е да го поправите. Въпросът е, че обединяването на малко парче сега е много по-лесно, отколкото обединяването на нещо голямо след няколко седмици. И третата точка е, че други инженери ще работят с текущата версия на кода. Те ще видят, че тук са добавени някои миграции и след това се е появил някакъв метод, който те също може да искат да използват. Всеки ще види какво се случва във вашия код. Именно за тези три неща се практикува.
Благодаря, темата е приключена!
(Олег Сорока) Мога ли да добавя? Казахте всичко правилно, искам само да добавя една фраза.
So.
С непрекъснатата интеграция кодът се обединява в общ клон не когато функцията е напълно готова, а когато компилацията спре да се поврежда. И можете спокойно да се ангажирате да овладявате толкова пъти на ден, колкото искате. Вторият аспект е, че ако по някаква причина не можете да разделите месечната задача на задачи поне три дни, мълча около три часа, тогава имате огромен проблем. И фактът, че нямате непрекъсната интеграция, е най-малкият от тези проблеми. Това означава, че имате проблеми с архитектурата и нулеви инженерни практики. Защото дори това да е изследване, то във всеки случай трябва да бъде формулирано под формата на хипотези или цикъл.
Говорихме за 4 показателя, които отличават успешните компании от изоставащите. Все още трябва да живеем, за да видим тези 4 показателя. Ако изпълнението на вашата средна задача отнема един месец, тогава бих се съсредоточил първо върху този показател. Първо бих го намалил на 3 дни. И след това започнах да мисля за Continuous.
Правилно ли ви разбрах, че смятате, че по принцип няма смисъл да инвестирате в инженерни практики, ако изпълнението на всяка задача отнема месец?
Имате непрекъсната интеграция. И има такава тема, че за 10 минути можете или да коригирате корекция, или да я върнете обратно. Представете си, че сте го пуснали. Нещо повече, дори имате непрекъснато внедряване, пуснали сте го в прод и едва тогава сте забелязали, че нещо се е объркало. И трябва да го върнете обратно, но вече сте мигрирали вашата база данни. Вече имате схемата на базата данни на следващата версия, освен това сте имали и някакъв вид резервно копие и данните също са записани там.
И каква алтернатива имате? Ако върнете кода назад, той вече не може да работи с тази актуализирана база данни.
Базата се движи само напред, да.
Хората, които имат лоши инженерни практики, най-вероятно също не са чели дебелата книга за... Какво да правя с резервното копие? Ако възстановите от резервно копие, това означава, че губите данните, които сте натрупали през този момент. Например, работихме три часа с новата версия на базата данни, потребители се регистрираха там. Отказвате стария архив, защото схемата не работи с новата версия, така че сте загубили тези потребители. И са недоволни, ругаят се.
За да овладеете пълния набор от практики, които поддържат непрекъсната интеграция и непрекъсната доставка, не е достатъчно просто да се научите как да пишете.... Първо, може да има много от тях, ще бъде непрактично. Освен това има куп други практики като Scientific. Има такава практика, GitHub я популяризира едно време. Това е, когато имате стар и нов код, работещи едновременно. Това е, когато правите незавършена функция, но тя може да върне някаква стойност: или като функция, или като Rest API. Изпълнявате както новия, така и стария код и сравнявате разликата между тях. И ако има разлика, тогава регистрирате това събитие. По този начин знаете, че имате нова функция, готова за внедряване върху старата, ако не сте имали несъответствие между двете за определено време.
Има стотици такива практики. Бих предложил да започнете с трансбазова разработка. Тя не е 100% на непрекъснатата интеграция, но практиките са едни и същи, едното не може да живее добре без другото.
Дадохте ли transbase development като пример, където можете да видите практики, или предлагате на хората да започнат да използват transbase debelopment?
Погледнете, защото няма да могат да го използват. За да ги използвате, трябва да четете много. И когато човек попита: „Какво да прави с функция, която отнема месец, това означава, че той не е чел за разработката на трансбаза.“ Все още не бих го препоръчал. Бих посъветвал да се съсредоточите единствено върху темата за това как правилно архитектурно да разделите големите задачи на по-малки. Това е същността на разлагането.
Декомпозицията е един от инструментите на архитекта. Първо правим анализ, след това декомпозиция, след това синтез, след това интеграция. И така ни се получава всичко. И ние все още трябва да израснем до непрекъсната интеграция чрез разлагане. На първия етап възникват въпроси и вече говорим за четвъртия етап, т.е. колкото по-често правим интеграция, толкова по-добре. Все още е твърде рано да направите това; би било хубаво първо да отрежете монолита си.
Трябва да начертаете няколко стрелки и квадратчета върху някаква диаграма. Не можете да кажете, че сега ще покажа архитектурната схема на ново приложение и ще покажа един квадрат, вътре в който има зелен бутон за приложението. Във всеки случай ще има повече квадратчета и стрелки. Всяка диаграма, която видях, имаше повече от една. И декомпозицията, дори на ниво графично представяне, вече се извършва. Следователно квадратите могат да бъдат направени независими. Ако не, тогава имам големи въпроси към архитекта.
Има въпрос от чата: „Ако прегледът е задължителен и отнема много време, може би ден или повече?“
Имате проблеми с практиката. Прегледът не трябва да продължава ден или повече. Това е същата история като предишния въпрос, само малко по-мека. Ако прегледът продължи един ден, тогава най-вероятно този преглед ще претърпи много голяма промяна. Това означава, че трябва да се намали. В трансбазното развитие, което Олег препоръча, има история, наречена непрекъснат преглед. Нейната идея е, че правим такава малка заявка за изтегляне нарочно, защото се стремим да се сливаме постоянно и малко по малко. И така заявката за изтегляне променя една абстракция или 10 реда. Благодарение на този преглед ни отнема няколко минути.
Ако прегледът отнеме ден или повече, нещо не е наред. Първо, може да имате някои проблеми с архитектурата. Или това е голяма част от кода, например 1 реда. Или вашата архитектура е толкова сложна, че човек не може да я разбере. Това е малко страничен проблем, но и той ще трябва да се реши. Може би изобщо няма нужда от преглед. Трябва да помислим и за това. Прегледът е нещото, което ви забавя. Като цяло има своите предимства, но трябва да разберете защо го правите. Това начин ли е да предавате бързо информация, това начин ли сте да задавате някакви стандарти вътрешно или какво? защо ти трябва това Защото прегледът трябва да се направи или много бързо, или да се отмени изобщо. Това е като трансбазно развитие - историята е много красива, но само за зрели момчета.
Що се отнася до 4-те показателя, все пак бих препоръчал да ги премахнете, за да разберете до какво води това. Вижте числата, вижте снимката, колко зле е всичко.
(Дмитрий) Готов съм да вляза в дискусия за това с вас. Числата и показателите са страхотни, практиките са страхотни. Но трябва да разберете дали бизнесът има нужда от това. Има фирми, които не се нуждаят от такава скорост на промяна. Познавам компании, в които промени не могат да се правят на всеки 15 минути. И не защото са толкова лоши. Това е такъв жизнен цикъл. И за да направите функцията за разклонения, функцията за превключване, имате нужда от дълбоки познания.
Сложно е. Ако искате да прочетете историята за функцията за превключване по-подробно, силно я препоръчвам . И има чудесна статия от Мартин Фаулър за функциите за превключване: какви типове има, жизнени цикли и т.н. Функцията за превключване е сложна.
И все още не сте отговорили на въпроса: „Необходим ли е Дженкинс или не?“
Дженкинс не е необходим в никакъв случай наистина. Сериозно обаче, инструментите: Jenkins, Gitlab ще ви донесат удобство. Ще видите, че модулът е сглобен или не. Те могат да ви помогнат, но няма да ви дадат практика. Те могат да ви дадат само кръг - Добре, не Добре. И тогава, ако пишеш и тестове, защото ако няма тестове, тогава е почти безсмислено. Следователно е необходимо, защото е по-удобно, но като цяло можете да живеете без него, няма да загубите много.
Тоест, ако имате практики, това означава ли, че не ви трябват?
Това е вярно. Препоръчвам теста Jez Humble. Имам амбивалентно отношение към последната точка. Но като цяло, ако имате три неща, сливате постоянно, изпълнявате тестове на ангажименти в главния, бързо коригирате компилацията в главния, тогава може би нямате нужда от нищо друго.
Докато чакаме въпроси от участници, аз имам въпрос. Просто говорихме за кода на продукта. Използвали ли сте го за инфраструктурен код? Дали това е същият код, има ли същите принципи и същия жизнен цикъл, или има различни жизнени цикли и принципи? Обикновено, когато всички говорят за непрекъсната интеграция и развитие, всички забравят, че има и инфраструктурен код. А напоследък има все повече и повече. И всички тези правила трябва ли да бъдат пренесени там?
Дори не че трябва да бъде, би било страхотно, защото би улеснило живота по същия начин. Щом работим с код, а не с bash скриптове, но имаме нормален код.
Спрете, спрете, bash скриптът също е код. Не докосвай старата ми любов.
Добре, няма да потъпча спомените ти. Аз лично не харесвам баш. Чупи грозно и страшно през цялото време. И често се чупи непредсказуемо, затова не го харесвам. Но добре, да кажем, че имате bash код. Може би наистина не разбирам и има нормални рамки за тестване. Просто не съм наясно. И получаваме същите ползи.
Веднага щом работим с инфраструктура като код, получаваме всички същите проблеми като разработчиците. Преди няколко месеца се натъкнах на ситуация, в която колега ми изпрати заявка за изтегляне за 1 реда в bash. И висиш на ревюто 000 часа. Възникват същите проблеми. Все още е код. И все още е сътрудничество. Засядаме със заявката за изтегляне и се забиваме с факта, че разрешаваме едни и същи конфликти на сливане в един и същ bash, например.
Сега много активно разглеждам цялото това нещо в най-красивото инфра програмиране. Сега внесох Пулуми в инфраструктурата. Това е програмиране в най-чист вид. Там е още по-хубаво, защото имам всички възможности на език за програмиране, т.е. Тоест промяната ми е вече в мастера. Вече всички могат да го видят. Други инженери знаят за това. Там вече е повлияло нещо. Той обаче не беше активиран за всички инфраструктури. Включи се на тестовите ми стендове например. Следователно, за да отговоря отново на въпроса ви, е необходимо. Това прави живота по-лесен за нас, като инженери, работещи с код, по същия начин.
Ако някой друг има въпроси?
Имам въпрос. Искам да продължа дискусията с Олег. Като цяло смятам, че сте прав, че ако една задача отнема месец за изпълнение, тогава имате проблем с архитектурата, имате проблем с анализа, декомпозицията, планирането и т.н. Но имам чувството, че ако започнете опитвайки се да живеете според непрекъснатата интеграция, тогава ще започнете да коригирате болката с планиране, защото няма да избягате от нея никъде другаде.
(Олег) Да, точно така. Тази практика е сравнима по усилия с всяка друга сериозна практика, променяща културата. Най-трудно се преодоляват навиците, особено лошите. И ако за прилагането на тази практика е необходима сериозна промяна в навиците на околните: разработчици, мениджмънт, производствен мениджър, тогава ви очакват изненади.
Какви изненади може да има? Да речем, че решите, че ще се интегрирате по-често. И имате някои други неща, свързани с интеграцията, например артефакти. И във вашата компания, например, има политика, че всеки артефакт трябва да бъде отчетен по някакъв начин в някаква система за съхранение на артефакти. И отнема известно време. Човек трябва да постави отметка в квадратчето, че той, като мениджър по пускане, е тествал този артефакт, за да се увери, че е готов за пускане в производство. Ако отнема 5-10-15 минути, но правите оформлението веднъж седмично, тогава прекарването на половин час веднъж седмично е малък данък.
Ако правите непрекъсната интеграция 10 пъти на ден, тогава 10 пъти трябва да се умножат по 30 минути. И това надвишава количеството работно време на този мениджър за освобождаване. Просто се изморява да го прави. Има фиксирани разходи за някои практики. Това е всичко.
И трябва или да отмените това правило, така че вече да не правите такива боклуци, т.е. да не присвоявате ръчно степен, която да съответства на нещо. Вие разчитате изцяло на някакъв автоматизиран набор от тестове за готовност.
И ако имате нужда от доказателство от някого, така че шефът да го подпише и да не влезете в производство, без Вася да каже, че го позволява и т.н. - всички тези глупости пречат на практикуващия. Защото, ако има някакви дейности, свързани с данък, тогава всичко се увеличава 100 пъти. Следователно смяната често няма да бъде посрещната с радост от всички. Защото навиците на хората трудно се променят.
Когато човек върши обичайната си работа, той го прави почти без да мисли. Когнитивното й натоварване е нулево. Той просто си играе с това, вече има контролен списък в главата си, правил го е хиляди пъти. И щом дойдете и му кажете: „Да отменим тази практика и да въведем нова от понеделник“, за него това се превръща в мощно когнитивно натоварване. И идва на всички наведнъж.
Ето защо, най-простото нещо, въпреки че не всеки може да си позволи този лукс, но това е, което винаги правя, това е следното. Ако започне нов проект, тогава обикновено всички непроверени практики веднага се натъпкват в този проект. Въпреки че проектът е млад, ние не рискуваме нищо. Все още няма Prod, няма какво да се унищожи. Следователно може да се използва като обучение. Този подход работи. Но не всички компании имат възможност често да стартират такива проекти. Въпреки че това също е малко странно, защото сега има пълна дигитална трансформация, всеки трябва да започне експерименти, за да бъде в крак с конкурентите.
Тук стигате до извода, че първо трябва да разберете какво трябва да направите. Светът не е идеален и prod също не е идеален.
Да, тези неща са взаимосвързани.
Бизнесът също не винаги разбира, че трябва да върви по този път.
Има ситуация, в която изобщо не са възможни промени. Това е ситуация, в която има по-голямо напрежение върху отбора. Отборът вече е доста изгорял. Тя няма свободно време за експерименти. Те работят върху функции от сутрин до вечер. И управлението има все по-малко функции. Необходими са все повече и повече. В такава ситуация не са възможни никакви промени. На екипа може само да се каже, че утре ще направим същото като вчера, просто трябва да направим малко повече функции. В този смисъл не са възможни преходи към никакви практики. Това е класическа ситуация, когато няма време за наточване на брадвата, дърветата трябва да бъдат отсечени, така че те го режат с тъпа брадва. Тук няма прости съвети.
(Дмитрий) Ще прочета разяснение от чата: „Но имаме нужда от много тестово покритие на различни нива. Колко време е отделено за тестове? Малко е скъпо и отнема много време.“
(Олег) Това е класическо погрешно схващане. Трябва да има достатъчно тестове, за да сте уверени. Непрекъснатата интеграция не е нещо, при което първо се правят 100% от тестовете и едва след това започвате да прилагате тази практика. Непрекъснатата интеграция намалява вашето когнитивно натоварване поради факта, че всяка от промените, които виждате с очите си, е толкова очевидна, че разбирате дали ще счупи нещо или не, дори и без тестове. Можете бързо да тествате това в главата си, защото промените са малки. Дори ако имате само ръчни тестери, за тях също е по-лесно. Изтърколихте се и казахте: „Вижте, нещо счупено ли е?“ Те провериха и казаха: "Не, нищо не е счупено." Защото тестерът знае къде да търси. Имате един ангажимент, свързан с една част от кода. И това се експлоатира със специфично поведение.
Тук вие, разбира се, украсихте.
(Дмитрий) Тук не съм съгласен. Има практика - разработка чрез тестове, която ще ви спести от това.
(Олег) Е, още не съм стигнал дотам. Първата илюзия е, че трябва да напишете 100% от тестовете или изобщо не е нужно да правите непрекъсната интеграция. Не е вярно. Това са две паралелни практики. И не са пряко зависими. Вашето тестово покритие трябва да е оптимално. Оптимално - това означава, че вие сами сте уверени, че качеството на капитана, в който вашият капитан е останал след ангажимента, ви позволява уверено да натиснете бутона „Разгръщане“ в пияна петъчна вечер. Как постигате това? Чрез преглед, чрез покритие, чрез добър мониторинг.
Добрият мониторинг е неразличим от тестовете. Ако стартирате тестове веднъж на pre prod, тогава те проверяват всичките ви потребителски скриптове веднъж и това е. И ако ги стартирате в безкраен цикъл, тогава това е вашата внедрена система за наблюдение, която безкрайно тества всичко - независимо дали се е сринало или не. В този случай единствената разлика е дали се прави веднъж или два пъти. Много добър набор от тестове... работи безкрайно, това е наблюдение. И правилното наблюдение трябва да бъде такова.
И затова как точно ще постигнете това състояние, когато се приготвите в петък вечерта и се приберете е друг въпрос. Може би си просто един смел мръсник.
Да се върнем малко назад към непрекъснатата интеграция. Избягахме в малко по-различна сложна практика.
И втората илюзия е, че MVP, казват, трябва да се направи бързо, така че там изобщо не са необходими тестове. Не със сигурност по този начин. Факт е, че когато пишете потребителска история в MVP, можете или да я развиете направо, тоест сте чули, че има някаква потребителска история и веднага сте изтичали да я кодирате, или можете да работите с помощта на TDD. И според TDD, както показва практиката, това не отнема повече време, т.е. тестовете са страничен ефект. Практиката на TDD не е за тестване. Въпреки това, което се нарича разработка, управлявана от тестове, изобщо не става дума за тестове. Това също е по-скоро архитектурен подход. Това е подход да се пише точно това, което е необходимо, а не да се пише това, което не е необходимо. Това е практика на фокусиране върху следващата итерация на вашето мислене по отношение на създаването на архитектура на приложение.
Следователно не е толкова лесно да се отървете от тези илюзии. MVP и тестовете не си противоречат. Дори, по-скоро, напротив, ако правите MVP с помощта на TDD практика, тогава ще го направите по-добре и по-бързо, отколкото ако го правите изобщо без практика, но на топка.
Това е много неочевидна и сложна идея. Когато чуете, че сега ще пиша повече тестове и в същото време ще правя нещо по-бързо, звучи абсолютно неадекватно.
(Дмитрий) Много хора тук, когато се обадят на MVP, хората са твърде мързеливи, за да напишат нещо нормално. И това все пак са различни неща. Няма нужда да превръщате MVP в нещо лошо, което не работи.
Да, да, прав си.
И тогава изведнъж MVP в прод.
Завинаги.
И TDD звучи много необичайно, когато чуете, че пишете тестове и изглежда, че вършите повече работа. Звучи много странно, но всъщност така става по-бързо и по-красиво. Когато пишете тест, вие вече мислите много в главата си какъв код ще бъде извикан и как, както и какво поведение очакваме от него. Не казвате просто, че съм написал някаква функция и тя прави нещо. Първо си помислихте, че тя има такива и такива условия, ще бъде призована по такъв и такъв начин. Покривате това с тестове и от това разбирате как ще изглеждат вашите интерфейси във вашия код. Това оказва огромно влияние върху архитектурата. Вашият код автоматично става по-модулен, защото първо се опитвате да разберете как ще го тествате и едва след това го пишете.
Това, което ми се случи с TDD беше, че в един момент наех ментор на Ruby, когато все още бях програмист на Ruby. И той казва: „Нека го направим според TDD.“ Помислих си: „По дяволите, сега трябва да напиша нещо допълнително.“ И се съгласихме, че в рамките на две седмици ще напиша целия работен код на Python, използвайки TDD. След две седмици разбрах, че не искам да се връщам. След две седмици опити да прилагате това навсякъде, разбирате колко по-лесно е станало за вас дори само да мислите. Но това не е очевидно, така че препоръчвам на всички, ако имате чувството, че TDD е трудно, отнема време и е ненужно, опитайте да се придържате към него само две седмици. Две ми бяха достатъчни.
(Дмитрий) Можем да разширим тази идея от гледна точка на експлоатацията на инфраструктурата. Преди да стартираме нещо ново, ние извършваме мониторинг и след това стартираме. В този случай наблюдението става нормално тестване за нас. И има развитие чрез мониторинг. Но почти всички казват, че е дълго, мързелив съм, направих временна чернова. Ако сме направили нормален мониторинг, разбираме състоянието на CI системата. И CI системата има много мониторинг. Разбираме състоянието на системата, разбираме какво има вътре в нея. И по време на разработката ние просто правим системата така, че да достигне желаното състояние.
Тези практики са известни отдавна. Обсъждахме това преди около 4 години. Но за 4 години практически нищо не се е променило.
Но на тази бележка предлагам да приключим официалната дискусия.
Видео (вмъкнато като медиен елемент, но по някаква причина не работи):
Източник: www.habr.com