Превод на написот подготвен за студенти на курсеви „Практики и алатки на DevOps“ во едукативниот проект OTUS.

Треба да изберете едно складиште бидејќи однесувањето што го промовира во вашите тимови е транспарентност и споделена одговорност, особено кога тимовите растат. Во секој случај, ќе треба да инвестирате во алатки, но секогаш е подобро ако стандардното однесување е однесувањето што го сакате во вашите команди.

Зошто зборуваме за ова?

Мет Клајн ја напиша статијата „Монорепос: Те молам немој!  (забелешка на преведувачот: превод на Хабре „Монорепозиториуми: ве молиме немојте“). Ми се допаѓа Мет, мислам дека е многу паметен и треба да го прочитате неговото гледиште. Тој првично ја објави анкетата на Твитер:

Превод:
Оваа Нова Година ќе се расправам колку се смешни монорепозиториуми. 2019 започна тивко. Во духот на ова, ви нудам анкета. Кои се големите фанатици? Поддржувачи:
- Монорепо
- Руст
- Неточна анкета / и двете

Мојот одговор беше: „Јас сум буквално и двајцата од тие луѓе“. Наместо да зборуваме за тоа како Руст е дрога, ајде да погледнеме зошто мислам дека греши за монорепозиториите. Малку за себе. Јас сум CTO на Шеф Софтвер. Имаме околу 100 инженери, база на кодови од 11-12 години и 4 главни производи. Дел од овој код е во полирепозиториум (мојата почетна позиција), дел е во едно складиште (мојата моментална позиција).

Пред да започнам: секој аргумент што ќе го дадам овде ќе важи за двата вида складишта. Според мое мислење, не постои техничка причина зошто треба да изберете еден тип на складиште пред друг. Можете да направите кој било пристап да функционира. Со задоволство зборувам за тоа, но не ме интересираат вештачки технички причини зошто еден е супериорен во однос на друг.

Се согласувам со првиот дел од поентата на Мет:

Затоа што во обем, едно складиште ќе ги реши сите исти проблеми што ги решава полирепозиториумот, но во исто време ќе ве принуди цврсто да го споите вашиот код и ќе бара неверојатни напори за зголемување на приспособливоста на вашиот систем за контрола на верзии.

Ќе треба да ги решите истите проблеми без разлика дали ќе изберете едно складиште или полирепозиториум. Како ги издавате изданијата? Каков е вашиот пристап кон ажурирањата? Назад компатибилност? Вкрстени зависности од проекти? Кои архитектонски стилови се прифатливи? Како управувате со вашата инфраструктура за изградба и тестирање? Списокот е бесконечен. И сите ќе ги решите додека растете. Нема бесплатно сирење.

Мислам дека аргументот на Мет е сличен на ставовите што ги споделуваат многу инженери (и менаџери) што ги почитувам. Ова се случува од перспектива на инженерот кој работи на компонентата или тимот што работи на компонентата. Слушате работи како:

• Базата на кодови е гломазна - не ми треба сето ова ѓубре.
• Потешко е да се тестира бидејќи морам да го тестирам сето ова ѓубре што не ми треба.
• Потешко е да се работи со надворешни зависности.
• Ми требаат мои сопствени системи за контрола на виртуелната верзија.

Се разбира, сите овие точки се оправдани. Ова се случува и во двата случаи - во полирепозиториумот имам свој ѓубре, покрај оној што е потребен за изградбата... Можеби ќе ми требаат и други ѓубре. Така, јас „едноставно“ создавам алатки кои го проверуваат целиот проект. Или создавам лажно моно складиште со подмодули. Можевме да шетаме околу ова цел ден. Но, мислам дека аргументот на Мет ја промашува главната причина, која доста силно ја превртев во корист на едно складиштето:

Провоцира комуникација и покажува проблеми

Кога ги одвојуваме складиштата, создаваме де факто проблем на координација и транспарентност. Ова одговара на начинот на кој размислуваме за тимовите (особено начинот на кој поединечните членови размислуваат за нив): ние сме одговорни за одредена компонента. Работиме во релативна изолација. Границите се фиксирани на мојот тим и на компонентата(ите) на кои работиме.

Како што архитектурата станува посложена, еден тим повеќе не може сам да управува со неа. Многу малку инженери го имаат целиот систем во главата. Да речеме дека управувате со споделена компонента А што ја користат тимовите Б, Ц и Д. Тимот А рефакторира, го подобрува API, а исто така ја менува внатрешната имплементација. Како резултат на тоа, промените не се компатибилни наназад. Каков совет имате?

• Најдете ги сите места каде што се користи стариот API.
• Дали има места каде што новиот API не може да се користи?
• Можете ли да ги поправите и тестирате другите компоненти за да бидете сигурни дека тие не се скршат?
• Дали овие тимови можат да ги тестираат вашите промени во моментов?

Имајте предвид дека овие прашања се независни од типот на складиштето. Ќе треба да ги најдете тимовите Б, Ц и Д. Ќе треба да разговарате со нив, да го дознаете времето, да ги разберете нивните приоритети. Барем се надеваме дека ќе го направите тоа.

Никој навистина не сака да го прави ова. Ова е многу помалку забавно отколку само да го поправите проклетиот API. Сето тоа е човечко и неуредно. Во полирепозиториум, можете едноставно да направите промени, да им го дадете на луѓето кои работат на таа компонента (веројатно не B, C или D) на преглед и да продолжите понатаму. Тимовите Б, Ц и Д засега можат само да останат со нивната тековна верзија. Ќе се обноват кога ќе ја сфатат вашата генијалност!

Во едно складиште, одговорноста стандардно се префрла. Тимот А ја менува својата компонента и, ако не е внимателен, веднаш ги крши Б, Ц и Д. Ова води до тоа што Б, Ц и Д се појавуваат на вратата на А, прашувајќи се зошто тимот А го скрши собранието. Ова го учи А дека не можат да ја прескокнат мојата листа погоре. Тие мора да зборуваат за тоа што ќе направат. Дали Б, Ц и Д можат да се движат? Што ако B и C можат, но D е тесно поврзан со несакан ефект од однесувањето на стариот алгоритам?

Потоа треба да разговараме за тоа како ќе излеземе од оваа ситуација:

1. Поддршка за повеќе внатрешни API и ќе го означи стариот алгоритам како застарен додека D не може да престане да го користи.
2. Поддршка за повеќе верзии на издавање, една со стариот интерфејс, една со новиот.
3. Одложете го објавувањето на промените на А додека B, C и D не можат истовремено да го прифатат.

Да речеме дека избравме 1, неколку API. Во овој случај имаме две парчиња код. Стари и нови. Прилично погодно во некои ситуации. Повторно го проверуваме стариот код, го означуваме како застарен и се согласуваме за распоред за отстранување со тимот D. Суштински е идентичен за поли и моно складишта.

За да издадеме повеќе верзии, потребна ни е гранка. Сега имаме две компоненти - А1 и А2. Тимовите Б и Ц користат А2, а Д го користат А1. Потребна ни е секоја компонента да биде подготвена за објавување бидејќи можеби ќе бидат потребни безбедносни ажурирања и други поправени грешки пред D да може да продолжи напред. Во полирепозиториум, можеме да го скриеме ова во долговечна гранка што се чувствува добро. Во едно складиште, го принудуваме кодот да се креира во нов модул. Тимот Д сепак ќе мора да направи промени на „старата“ компонента. Секој може да ги види трошоците што ги плаќаме овде - сега имаме двојно повеќе код, а сите поправени грешки што се однесуваат на А1 и А2 мора да се однесуваат на двете. Со пристапот на разгранување во полирепозиториум, ова се крие зад черешот. Сметаме дека трошокот е помал бидејќи нема дуплирање. Од практична гледна точка, цената е иста: ќе изградите, ослободите и одржувате две главно идентични бази на кодови додека не можете да избришете една од нив. Разликата е во тоа што со монорепозиториум оваа болка е директна и видлива. Ова е уште полошо, и тоа е добро.

Конечно, стигнавме до третата точка. Одложување на ослободување. Можно е промените направени од А да го подобрат животот на тимот А. Важно, но не и итно. Можеме ли само да одложиме? Во полирепозиториум, го туркаме ова за да го прикачи артефактот. Се разбира, ова му го кажуваме на тимот Д. Само останете на старата верзија додека не стигнете! Ова те поставува да играш кукавица. Тимот А продолжува да работи на својата компонента, игнорирајќи го фактот дека тимот Д користи сè позастарена верзија (тоа е проблем на тимот Д, тие се глупави). Во меѓувреме, тимот Д зборува лошо за невнимателниот однос на тимот А кон стабилноста на кодот, ако воопшто зборуваат за тоа. Поминуваат месеци. Конечно, тимот Д одлучува да ја разгледа можноста за ажурирање, но А има само повеќе промени. Тимот А едвај се сеќава кога и како го скршиле D. Надградбата е поболна и ќе трае подолго. Што го испраќа понатаму по приоритетниот оџак. До денот кога ќе имаме безбедносно прашање во А што не принудува да направиме гранка. Тимот А мора да се врати во времето, да најде точка кога D бил стабилен, да го реши проблемот таму и да го подготви за ослободување. Ова е де факто изборот што го прават луѓето, и тој е убедливо најлош. Се чини дека е добро и за тимот А и за тимот Д се додека можеме да се игнорираме еден со друг.

Во едно складиште, третото навистина не е опција. Вие сте принудени да се справите со ситуацијата на еден од двата начини. Треба да ги видите трошоците за да имате две гранки за ослободување. Научете да се заштитите од ажурирања што ја нарушуваат компатибилноста наназад. Но, најважно: не можете да избегнете тежок разговор.

Според моето искуство, кога тимовите стануваат големи, повеќе не е возможно да се има на ум целиот систем, а тоа е најважниот дел. Мора да ја подобрите видливоста на раздорот во системот. Мора активно да работите за да ги натерате тимовите да го тргнат погледот од нивните компоненти и да ја погледнат работата на другите тимови и потрошувачи.

Да, можете да креирате алатки кои се обидуваат да го решат проблемот со полирепозиториумот. Но, моето искуство со предавање континуирана испорака и автоматизација во големите претпријатија ми го кажува ова: стандардното однесување без употреба на дополнителни алатки е однесувањето што очекувате да го видите. Стандардното однесување на полирепозиториумот е изолација, тоа е целата поента. Стандардното однесување на едно складиште е споделена одговорност и транспарентност, тоа е целата поента. Во двата случаи, ќе создадам алатка која ќе ги измазне грубите рабови. Како лидер, секој пат ќе избирам едно складиште бидејќи алатките треба да ја зајакнат културата што ја сакам, а културата доаѓа од малите одлуки и секојдневната работа на тимот.

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Кои се најголемите фанатици? Поддржувачи:

• Монорепо

• Руст

• Неточна анкета / и двете

Гласале 33 корисници. 13 корисници беа воздржани.

Извор: www.habr.com