Курстун студенттери үчүн даярдалган макаланын котормосу "DevOps практикалары жана куралдары" OTUS билим берүү долбоорунда.

Сиз монорепозиторийди тандап алышыңыз керек, анткени ал сиздин командаларыңыздагы жүрүм-турум ачыктык жана жалпы жоопкерчилик болуп саналат, айрыкча командалар өскөн сайын. Кандай болбосун, сиз инструментке акча салышыңыз керек, бирок демейки жүрүм-турум сиздин буйруктарыңызда каалагандай болсо, ар дайым жакшы.

Эмне үчүн биз бул жөнүндө айтып жатабыз?

Макаланы Мэтт Клейн жазган "Монорепос: Сураныч, кылба!"  (котормочунун эскертүүсү: Habré боюнча котормо "Монорепозиторийлер: сураныч, кылбаңыз"). Мага Мэтт жагат, менимче, ал абдан акылдуу жана анын көз карашын окуш керек. Ал сурамжылоону алгач Твиттерде жарыялаган:

котормо:
Ушул Жаңы жылдын күнү мен монорепозиторийлердин канчалык күлкүлүү экендиги жөнүндө талашып-тартышып жатам. 2019-жыл тынч башталды. Ушунун духунда мен сиздерге сурамжылоону сунуштайм. Чоң фанаттар кимдер? Колдоочулар:
- Monorepo
- дат
- Туура эмес сурамжылоо / экөө тең

Менин жообум: "Мен экөөбүз тең ошол адамдардын биримин". Rust кандай дары экени жөнүндө сөз кылуунун ордуна, келгиле, эмне үчүн ал монорепозиторийлер жөнүндө туура эмес деп ойлоймун карап көрөлү. Өзүң жөнүндө бир аз. Мен ашпозчу программалык камсыздоонун башкы директорумун. Бизде 100гө жакын инженерлер, 11-12 жыл мурунку код базасы жана 4 негизги продукциясы бар. Бул коддун айрымдары полирепозиторийде (менин баштапкы абалым), кээ бирлери монорепозиторийде (менин учурдагы абалым).

Мен баштаардан мурун: бул жерде келтирген ар бир аргумент репозиторийлердин эки түрүнө тең колдонулат. Менин оюмча, репозиторийдин бир түрүн башкасына тандоого эч кандай техникалык себеп жок. Сиз каалаган ыкманы ишке ашыра аласыз. Мен бул тууралуу айтууга кубанычтамын, бирок бири экинчисинен жогору турган жасалма техникалык себептер мени кызыктырбайт.

Мен Мэтттин сөзүнүн биринчи бөлүгүнө кошулам:

Анткени масштабда монорепозиторий полирепозиторий чечкен бардык көйгөйлөрдү чечет, бирок ошол эле учурда сизди кодуңузду бекем бириктирүүгө мажбурлайт жана версияңызды башкаруу тутумуңуздун масштабдуулугун жогорулатуу үчүн укмуштай күч-аракетти талап кылат.

Сиз монорепозиторийди же полирепозиторийди тандасаңыз да, ошол эле маселелерди чечүүгө туура келет. Релиздерди кантип чыгарасыз? Жаңыртууларга кандай мамиле жасайсыз? Артка шайкештик? Долбоорлордун кайчылаш көз карандылыгы? Кандай архитектуралык стилдер алгылыктуу? Куруу жана сыноо инфраструктураңызды кантип башкарасыз? Тизме чексиз. А сиз алардын баарын өскөн сайын чечесиз. бекер сыр жок.

Мен Мэттинин аргументи мен сыйлаган көптөгөн инженерлердин (жана менеджерлердин) пикирлерине окшош деп ойлойм. Бул компонентте иштеген инженердин же компонентте иштеген команданын көз карашынан келип чыгат. Сиз төмөнкүдөй нерселерди угасыз:

• Код базасы көлөмдүү - мага бул керексиз нерселердин баары кереги жок.
• Сыноо кыйыныраак, анткени мага кереги жок таштандылардын баарын сынап көрүшүм керек.
• Тышкы көз карандылык менен иштөө кыйыныраак.
• Мага виртуалдык версияны башкаруу системалары керек.

Албетте, бул пункттардын бардыгы негиздуу. Бул эки учурда тең болот – полирепозиторийде курууга керектүү нерседен тышкары менин өзүмдүн таштандыларым бар... Мага башка таштандылар да керек болушу мүмкүн. Ошентип, мен "жөн эле" бүт долбоорду текшере турган куралдарды түзөм. Же мен субмодулдар менен жасалма монорепозиторий түзөм. Биз бул жерде күнү бою жүрсөк болот. Бирок менин оюмча, Мэттинин аргументи мен монорепозиторийдин пайдасына катуу бурулган негизги себепти сагындым:

Бул байланышты козгойт жана көйгөйлөрдү көрсөтөт

Биз репозиторийлерди бөлгөнүбүздө иш жүзүндө координация жана айкындуулук көйгөйүн жаратабыз. Бул биздин командалар жөнүндө ой жүгүртүүбүзгө (айрыкча айрым мүчөлөрдүн алар жөнүндө ойлогонуна) дал келет: биз белгилүү бир компонент үчүн жооптуубуз. Биз салыштырмалуу изоляцияда иштейбиз. Чек аралар менин командамда жана биз иштеп жаткан компонент(тер)де белгиленген.

Архитектура татаалдашкан сайын, бир команда аны жалгыз башкара албайт. Бүт системаны башында турган инженерлер өтө аз. Сиз B, C жана D командалары колдонгон жалпы А компонентин башкарасыз дейли. А командасы рефакторингде, API'ни жакшыртып, ошондой эле ички ишке ашырууну өзгөртүүдө. Натыйжада, өзгөртүүлөр артка шайкеш келбейт. Кандай кеңешиңиз бар?

• Эски API колдонулган бардык жерлерди табыңыз.
• Жаңы API колдонулбай турган жерлер барбы?
• Башка компоненттерди оңдоп, сынап көрсөңүз, алар бузулуп кетпесин деп текшере аласызбы?
• Бул командалар өзгөртүүлөрүңүздү азыр текшере алабы?

Сураныч, бул суроолор репозиторий түрүнө көз каранды эмес экенин эске алыңыз. Сиз B, C жана D командаларын табышыңыз керек. Алар менен сүйлөшүп, убакытты билип, алардын артыкчылыктарын түшүнүшүңүз керек. Жок дегенде биз сизден үмүттөнөбүз.

Муну эч ким чындап каалабайт. Бул каргышка калган APIди оңдоого караганда анча кызыктуу эмес. Мунун баары адамдык жана баш аламандык. Полирепозиторийде сиз жөн гана өзгөртүүлөрдү киргизип, аны ошол компонентте иштеген адамдарга (балким B, C же D эмес) карап чыгуу үчүн берип, андан ары уланта аласыз. B, C жана D командалары азырынча учурдагы версиясында кала алышат. Алар сиздин генийиңизди түшүнгөндө жаңыланат!

Монорепозиторийде жоопкерчилик демейки боюнча которулат. А командасы өз компонентин өзгөртөт жана этият болбосо, дароо В, С жана D сындырат. Бул B, C жана D топторунун Анын эшигинде пайда болушуна алып келет, эмне үчүн А командасы чогулушту бузду деп таң калышат. Бул Ага менин жогорудагы тизмемди өткөрүп жибере албасын үйрөтөт. Алар эмне кыла тургандыктарын айтышы керек. B, C жана D кыймылдай алабы? Эгерде B жана C мүмкүн болсо, бирок D эски алгоритмдин жүрүм-турумунун терс таасири менен тыгыз байланышта болсочу?

Анда биз бул абалдан кантип чыгаарыбызды сүйлөшүшүбүз керек:

1. Бир нече ички API'лерди колдоо жана D аны колдонууну токтотконго чейин эски алгоритмди эскирген деп белгилейт.
2. Бир нече релиз версияларын колдоо, бири эски интерфейси менен, бири жаңысы менен.
3. B, C жана D бир эле убакта кабыл алганга чейин А өзгөртүүлөрүнүн чыгарылышын кечиктириңиз.

1, бир нече API тандадык дейли. Бул учурда бизде эки код бар. Эски жана жаңы. Кээ бир учурларда абдан ыңгайлуу. Биз эски кодду кайра текшерип, аны эскирген деп белгилейбиз жана D командасы менен поли жана моно репозиторийлер үчүн бирдей алып салуу графигин макулдашабыз.

Бир нече версияларды чыгаруу үчүн, бизге бутак керек. Азыр бизде эки компонент бар - A1 жана A2. В жана С командалары А2ди, ал эми D A1ди колдонушат. Бизге ар бир компонент чыгарууга даяр болушу керек, анткени D алдыга жылаардан мурун коопсуздук жаңыртуулары жана башка мүчүлүштүктөрдү оңдоо талап кылынышы мүмкүн. Полирепозиторийде биз муну жакшы сезген узакка созулган бутагына жашыра алабыз. Монорепозиторийде биз кодду жаңы модулда түзүүгө мажбурлайбыз. D командасы дагы эле "эски" компонентке өзгөртүүлөрдү киргизиши керек. Бул жерден биз төлөп жаткан чыгымды ар бир адам көрө алат - азыр бизде эки эсе көп код бар жана A1 жана A2ге тиешелүү бардык мүчүлүштүктөрдү оңдоо алардын экөөнө тең колдонулушу керек. Полирепозиторийде бутактануу ыкмасы менен бул алча-пиктин артында жашырылган. Эч кандай кайталоо болбогондуктан, чыгым аз деп эсептейбиз. Практикалык көз караштан алганда, баасы бирдей: сиз алардын бирин жок кылганга чейин эки бирдей код базасын куруп, чыгарасыз жана сактайсыз. Айырмасы монорепозиторий менен бул оору түз жана көрүнүп турат. Бул андан да жаман, бул жакшы.

Акыры, биз үчүнчү пунктка жеттик. Чыгаруу кечигүү. А тарабынан киргизилген өзгөртүүлөр А командасынын жашоосун жакшыртышы мүмкүн. Маанилүү, бирок шашылыш эмес. Биз жөн эле кечиктирүүгө болобу? Полирепозиторийде биз муну артефактты кадоо үчүн түртөбүз. Албетте, биз муну D командасына айтып жатабыз. Жеткенче эски версияда калыңыз! Бул сизди коркок ойноого шарт түзөт. А командасы өз компонентинин үстүндө иштөөнү улантууда, D командасы барган сайын эскирген версияны колдонуп жатканын эске албай жатат (бул D командасынын көйгөйү, алар келесоо). Ошол эле учурда, D командасы А командасынын коддун туруктуулугуна кайдыгер мамилеси жөнүндө начар сүйлөшөт, эгерде алар бул жөнүндө айтышса. Айлар өтөт. Акыр-аягы, D командасы жаңыртууну чечет, бирок Ада гана көбүрөөк өзгөрүүлөр бар. А командасы D качан же кантип сындырышканын араң эстейт. Жаңыртуу оор жана узакка созулат. Бул аны артыкчылыктуу стекке андан ары ылдый жиберет. Бизди бутак кылууга мажбурлаган А-да коопсуздук маселеси болгон күнгө чейин. А командасы убакытты артка кайтарып, D туруктуу болгон учурду таап, ошол жерден көйгөйдү оңдоп, аны чыгарууга даярдашы керек. Бул де-факто адамдардын тандоосу жана бул эң жаманы. Бири-бирибизге көңүл бурбай койсок, бул A жана D командасы үчүн жакшы окшойт.

Монорепозиторийде үчүнчүсү чындыгында вариант эмес. Сиз кырдаалды эки жолдун бири менен чечүүгө аргасызсыз. Сиз эки релиз бутактары бар чыгымдарды көрүү керек. Артка шайкештикти бузган жаңыртуулардан өзүңүздү коргоону үйрөнүңүз. Бирок эң негизгиси: кыйын сүйлөшүүдөн качуу мүмкүн эмес.

Менин тажрыйбам боюнча, командалар чоңойгондо, бүт системаны эске алуу мүмкүн болбой калат жана бул эң маанилүү бөлүгү. Сиз тутумдагы келишпестиктин көрүнүшүн жакшыртууңуз керек. Командаларды өз компоненттеринен алыстап, башка командалардын жана керектөөчүлөрдүн иштерин кароо үчүн жигердүү иштешиңиз керек.

Ооба, сиз полирепозиторий маселесин чечүүгө аракет кылган куралдарды түзө аласыз. Бирок чоң ишканаларда үзгүлтүксүз жеткирүү жана автоматташтыруу боюнча менин тажрыйбам мага муну айтат: кошумча куралдарды колдонбостон демейки жүрүм-турум – бул сиз күткөн жүрүм-турум. Полирепозиторийдин демейки жүрүм-туруму обочолонуу болуп саналат, мунун баары ушунда. Монорепозиторийдин демейки жүрүм-туруму бул жалпы жоопкерчилик жана ачык-айкындык. Эки учурда тең орой четтерин жылмалай турган курал түзөм. Лидер катары мен ар дайым монорепозиторийди тандайм, анткени куралдар мен каалаган маданиятты бекемдеши керек, ал эми маданият кичинекей чечимдерден жана команданын күнүмдүк ишинен келип чыгат.

Сурамжылоого катталган колдонуучулар гана катыша алышат. Кирүү, өтүнөмүн.

Эң чоң фанаттар кимдер? Колдоочулар:

• Monorepo

• дат

• Туура эмес сурамжылоо / экөө тең

33 колдонуучу добуш берди. 13 колдонуучу добуш берүүдөн баш тартты.

Source: www.habr.com