Դասընթացի ուսանողների համար պատրաստված հոդվածի թարգմանությունը OTUS կրթական նախագծում։
Դուք պետք է ընտրեք միապահեստ, քանի որ այն վարքագիծը, որը այն խթանում է ձեր թիմերում, թափանցիկություն է և համատեղ պատասխանատվություն, հատկապես երբ թիմերը մեծանում են: Ամեն դեպքում, դուք պետք է ներդրումներ կատարեք գործիքավորման մեջ, բայց միշտ ավելի լավ է, եթե լռելյայն վարքագիծը լինի այն վարքագիծը, որը ցանկանում եք ձեր հրամաններում:
Ինչո՞ւ ենք մենք խոսում այս մասին:
Մեթ Քլայնը գրել է հոդվածը (թարգմանչի նշում. թարգմանություն Habré ) Ինձ դուր է գալիս Մեթը, կարծում եմ, որ նա շատ խելացի է, և դուք պետք է կարդաք նրա տեսակետը: Նա ի սկզբանե հրապարակել է հարցումը Twitter-ում.
Թարգմանություն
Այս Ամանորին ես պատրաստվում եմ վիճել, թե որքան ծիծաղելի են մոնոպոզիտորիաները: 2019 թվականը սկսվեց հանգիստ. Այս ոգով առաջարկում եմ ձեզ հարցում: Ովքե՞ր են մեծ ֆանատիկոսները: Աջակիցներ.
- Մոնորեպո
- Ժանգոտվել
- Սխալ հարցում / երկուսն էլ
Իմ պատասխանն էր. «Ես բառացիորեն այդ երկուսն էլ եմ»: Փոխանակ խոսենք այն մասին, թե ինչպես է Rust-ը թմրանյութ է, եկեք նայենք, թե ինչու է ես կարծում, որ նա սխալ է monorepositories-ի հարցում: Մի փոքր ձեր մասին: Ես Chef Software-ի CTO-ն եմ: Մենք ունենք մոտ 100 ինժեներ, կոդերի բազա՝ մոտ 11-12 տարի առաջ և 4 հիմնական արտադրանք: Այս ծածկագրի մի մասը գտնվում է պոլիպահեստարանում (իմ մեկնարկային դիրքը), որոշները գտնվում են մոնոպոզիտորիայում (իմ ներկայիս դիրքը):
Նախքան սկսելը. այստեղ իմ բերած յուրաքանչյուր փաստարկ կկիրառվի երկու տեսակի պահեստների համար: Իմ կարծիքով, չկա տեխնիկական պատճառ, թե ինչու պետք է ընտրեք պահեստի մի տեսակ մյուսի փոխարեն: Կարող եք ցանկացած մոտեցում գործի դնել։ Ես ուրախ եմ խոսել այդ մասին, բայց ինձ չեն հետաքրքրում արհեստական տեխնիկական պատճառները, թե ինչու է մեկը մյուսին գերազանցում:
Ես համաձայն եմ Մեթի տեսակետի առաջին մասի հետ.
Որովհետև մասշտաբով, monorepository-ն կլուծի բոլոր այն խնդիրները, որոնք լուծում է պոլիպահեստարանը, բայց միևնույն ժամանակ կստիպի ձեզ սերտորեն զուգակցել ձեր ծածկագիրը և անհավանական ջանքեր կպահանջի ձեր տարբերակի կառավարման համակարգի մասշտաբայնությունը մեծացնելու համար:
Դուք ստիպված կլինեք լուծել նույն խնդիրները՝ անկախ նրանից՝ կընտրեք մոնոպոզիտորիա, թե պոլիպահեստ։ Ինչպե՞ս եք թողարկում թողարկումները: Ինչպիսի՞ն է ձեր մոտեցումը թարմացումներին: Հետընթաց համատեղելիությո՞ւն: Նախագծի խաչաձև կախվածություն: Ճարտարապետական ո՞ր ոճերն են ընդունելի: Ինչպե՞ս եք կառավարում ձեր կառուցման և փորձարկման ենթակառուցվածքը: Ցուցակն անվերջ է։ Եվ դուք կլուծեք դրանք բոլորը, երբ աճեք: Անվճար պանիր չկա։
Կարծում եմ, որ Մեթի փաստարկը նման է այն տեսակետներին, որոնք կիսում են շատ ինժեներներ (և ղեկավարներ), որոնց ես հարգում եմ: Սա տեղի է ունենում բաղադրիչի վրա աշխատող ինժեների կամ բաղադրիչի վրա աշխատող թիմի տեսանկյունից: Դուք լսում եք այնպիսի բաներ, ինչպիսիք են.
- Կոդերի բազան մեծ է. Ինձ այս ամբողջ անպետքության կարիքը չունի:
- Փորձարկելն ավելի դժվար է, քանի որ ես պետք է փորձեմ այս ամբողջ անպետքությունը, որն ինձ պետք չէ:
- Ավելի դժվար է աշխատել արտաքին կախվածությունների հետ։
- Ինձ պետք են իմ սեփական վիրտուալ տարբերակների կառավարման համակարգերը:
Այս բոլոր կետերը, իհարկե, արդարացված են։ Դա տեղի է ունենում երկու դեպքում էլ. պոլիպահեստում ես ունեմ իմ սեփական անպետք նյութերը, բացի կառուցման համար անհրաժեշտից... Ինձ կարող է անհրաժեշտ լինել նաև այլ անպետք նյութեր: Այսպիսով, ես «ուղղակի» ստեղծում եմ գործիքներ, որոնք ստուգում են ամբողջ նախագիծը: Կամ ես ենթամոդուլներով կեղծ մոնոպոզիտորիա եմ ստեղծում: Մենք կարող էինք շրջել այս ամբողջ օրը: Բայց ես կարծում եմ, որ Մեթի փաստարկը բաց է թողնում հիմնական պատճառը, որը ես բավականին ծանրաբեռնեցի հօգուտ monorepository-ի.
Այն հրահրում է շփումը և ցույց տալիս խնդիրներ
Երբ մենք առանձնացնում ենք պահեստները, մենք դե ֆակտո համակարգման և թափանցիկության խնդիր ենք ստեղծում։ Սա համապատասխանում է թիմերի մասին մեր մտածելակերպին (հատկապես այն, թե ինչպես են առանձին անդամները մտածում նրանց մասին). մենք պատասխանատու ենք որոշակի բաղադրիչի համար: Մենք աշխատում ենք հարաբերական մեկուսացման մեջ։ Սահմանները ամրագրված են իմ թիմի և այն բաղադրիչ(ներ)ի վրա, որոնց վրա մենք աշխատում ենք:
Քանի որ ճարտարապետությունը դառնում է ավելի բարդ, մեկ թիմ այլևս չի կարող միայնակ կառավարել այն: Շատ քիչ ինժեներներ ունեն ամբողջ համակարգը իրենց գլխում: Ենթադրենք, դուք կառավարում եք ընդհանուր A բաղադրիչը, որն օգտագործվում է B, C և D թիմերի կողմից: A թիմը վերամշակում է, բարելավում API-ն և նաև փոխում ներքին իրականացումը: Արդյունքում, փոփոխությունները հետադարձ համատեղելի չեն: Ի՞նչ խորհուրդ ունեք։
- Գտեք բոլոր այն վայրերը, որտեղ օգտագործվում է հին API-ն:
- Կա՞ն վայրեր, որտեղ նոր API-ն հնարավոր չէ օգտագործել:
- Կարո՞ղ եք ուղղել և փորձարկել այլ բաղադրիչներ, որպեսզի համոզվեք, որ դրանք չեն կոտրվում:
- Կարո՞ղ են այս թիմերը ստուգել ձեր փոփոխությունները հենց հիմա:
Խնդրում ենք նկատի ունենալ, որ այս հարցերը անկախ են պահեստի տեսակից: Դուք պետք է գտնեք B, C և D թիմերը: Դուք պետք է խոսեք նրանց հետ, պարզեք ժամանակը, հասկանաք նրանց առաջնահերթությունները: Համենայնդեպս, մենք հույս ունենք, որ դուք դա կանեք:
Ոչ ոք իսկապես չի ցանկանում դա անել: Սա շատ ավելի քիչ զվարճալի է, քան պարզապես անիծյալ API-ն շտկելը: Այդ ամենը մարդկային է և խառնաշփոթ: Polyrepository-ում դուք կարող եք պարզապես փոփոխություններ կատարել, տալ այն մարդկանց, ովքեր աշխատում են այդ բաղադրիչի վրա (հավանաբար ոչ B, C կամ D) վերանայման համար և շարունակել առաջ գնալ: B, C և D թիմերն առայժմ կարող են մնալ իրենց ընթացիկ տարբերակով: Նրանք կթարմացվեն, երբ գիտակցեն քո հանճարը:
Միապահեստում պատասխանատվությունը լռելյայնորեն տեղափոխվում է: A թիմը փոխում է իր բաղադրիչը և, եթե ուշադիր չէ, անմիջապես կոտրում է B, C և D: Սա հանգեցնում է նրան, որ B, C և D-ն հայտնվում են A-ի դռան մոտ՝ մտածելով, թե ինչու A թիմը խախտեց հավաքը: Սա սովորեցնում է Ա-ին, որ նրանք չեն կարող բաց թողնել իմ վերը նշված ցուցակը: Նրանք պետք է խոսեն այն մասին, թե ինչ են պատրաստվում անել։ Կարո՞ղ են B, C և D շարժվել: Իսկ եթե B-ն և C-ն կարող են, բայց D-ն սերտորեն կապված է հին ալգորիթմի վարքագծի կողմնակի ազդեցության հետ:
Այնուհետև մենք պետք է խոսենք այն մասին, թե ինչպես ենք դուրս գալու այս իրավիճակից.
- Աջակցում է բազմաթիվ ներքին API-ներին և կնշի հին ալգորիթմը որպես հնացած, մինչև D-ն դադարեցնի այն օգտագործել:
- Աջակցություն մի քանի թողարկման տարբերակներին, մեկը՝ հին ինտերֆեյսով, մեկը՝ նորով:
- Հետաձգեք A-ի փոփոխությունների թողարկումը, մինչև B, C և D-ն միաժամանակ ընդունեն այն:
Ենթադրենք, մենք ընտրել ենք 1, մի քանի API: Այս դեպքում մենք ունենք երկու կոդ: Հին ու նոր. Որոշ իրավիճակներում բավականին հարմար է: Մենք նորից ստուգում ենք հին կոդը, նշում ենք այն որպես հնացած և D թիմի հետ համաձայնեցնում ենք հեռացման ժամանակացույցը: Հիմնականում նույնական է պոլի և մոնո պահեստների համար:
Բազմաթիվ տարբերակներ թողարկելու համար մեզ անհրաժեշտ է մասնաճյուղ: Այժմ մենք ունենք երկու բաղադրիչ՝ A1 և A2: B և C թիմերը օգտագործում են A2-ը, իսկ D-ն օգտագործում է A1-ը: Մեզ պետք է, որ յուրաքանչյուր բաղադրիչ պատրաստ լինի թողարկմանը, քանի որ կարող են պահանջվել անվտանգության թարմացումներ և այլ վրիպակների շտկումներ, նախքան D-ն առաջ շարժվել: Պոլիպահեստում մենք կարող ենք դա թաքցնել երկարակյաց ճյուղում, որը լավ է զգում: Մոնոպահեստում մենք ստիպում ենք կոդը ստեղծել նոր մոդուլում: D թիմը դեռ պետք է փոփոխություններ կատարի «հին» բաղադրիչում: Յուրաքանչյուր ոք կարող է տեսնել այն ծախսերը, որոնք մենք վճարում ենք այստեղ. մենք այժմ ունենք երկու անգամ ավելի շատ կոդ, և ցանկացած սխալի շտկում, որը վերաբերում է A1-ին և A2-ին, պետք է կիրառվի երկուսի համար էլ: Պոլիպահեստում ճյուղավորվող մոտեցման դեպքում սա թաքնված է բալի ընտրության հետևում: Արժեքն ավելի ցածր ենք համարում, քանի որ կրկնություն չկա։ Գործնական տեսանկյունից արժեքը նույնն է. դուք կստեղծեք, կթողարկեք և կպահպանեք երկու հիմնականում նույնական կոդերի բազա, մինչև որ կարողանաք ջնջել դրանցից մեկը: Տարբերությունն այն է, որ մոնոպոզիտորիայի դեպքում այս ցավն ուղղակի է և տեսանելի: Սա նույնիսկ ավելի վատ է, և դա լավ է:
Վերջապես հասանք երրորդ կետին. Թողարկման ուշացում: Հնարավոր է, որ A-ի կողմից կատարված փոփոխությունները կբարելավեն A թիմի կյանքը: Կարևոր է, բայց ոչ հրատապ: Կարո՞ղ ենք պարզապես հետաձգել: Polyrepository-ում մենք սեղմում ենք սա՝ արտեֆակտը ամրացնելու համար: Իհարկե, մենք սա ասում ենք D թիմին: Պարզապես մնացեք հին տարբերակի վրա, մինչև հասնեք: Սա ձեզ ստիպում է վախկոտ խաղալ: Ա թիմը շարունակում է աշխատել իր բաղադրիչի վրա՝ անտեսելով այն փաստը, որ D թիմը օգտագործում է ավելի ու ավելի հնացած տարբերակ (դա D թիմի խնդիրն է, նրանք հիմար են): Մինչդեռ D թիմը վատ է խոսում կոդի կայունության նկատմամբ թիմի A անփույթ վերաբերմունքի մասին, եթե նրանք ընդհանրապես խոսում են դրա մասին: Անցնում են ամիսներ։ Ի վերջո, D թիմը որոշում է դիտարկել թարմացման հնարավորությունը, բայց A-ն միայն ավելի շատ փոփոխություններ ունի: Ա թիմը հազիվ է հիշում, թե երբ և ինչպես են կոտրել D-ն: Թարմացումը ավելի ցավոտ է և ավելի երկար տևելու է: Ինչն այն ուղարկում է ավելի ներքև առաջնահերթության կույտում: Մինչև այն օրը, երբ Ա-ում անվտանգության խնդիր կունենանք, որը ստիպում է մեզ ճյուղ անել։ Ա թիմը պետք է հետ գնա ժամանակի մեջ, գտնի մի կետ, երբ D-ն կայուն էր, լուծի խնդիրը և պատրաստի այն թողարկման: Սա մարդկանց դե ֆակտո ընտրությունն է, և դա ամենավատն է: Թվում է, թե դա լավ է և՛ A, և՛ D թիմի համար, քանի դեռ մենք կարող ենք անտեսել միմյանց:
Մոնոպահեստում երրորդն իսկապես տարբերակ չէ: Դուք ստիպված եք իրավիճակի հետ վարվել երկու եղանակներից մեկով: Դուք պետք է տեսնեք երկու թողարկման մասնաճյուղ ունենալու ծախսերը: Սովորեք պաշտպանվել ձեզ հետադարձ համատեղելիությունը խախտող թարմացումներից: Բայց ամենակարևորը. դուք չեք կարող խուսափել բարդ զրույցից:
Իմ փորձով, երբ թիմերը մեծանում են, այլևս հնարավոր չէ նկատի ունենալ ամբողջ համակարգը, և դա ամենակարևոր մասն է: Դուք պետք է բարելավեք համակարգում առկա տարաձայնությունների տեսանելիությունը: Դուք պետք է ակտիվորեն աշխատեք, որպեսզի թիմերը հայացքը շեղեն իրենց բաղադրիչներից և նայեն այլ թիմերի և սպառողների աշխատանքին:
Այո, դուք կարող եք ստեղծել գործիքներ, որոնք փորձում են լուծել polyrepository-ի խնդիրը: Բայց խոշոր ձեռնարկություններում շարունակական առաքում և ավտոմատացում դասավանդելու իմ փորձն ինձ ասում է սա. լռելյայն վարքագիծն առանց լրացուցիչ գործիքների օգտագործման այն վարքն է, որը դուք ակնկալում եք տեսնել: Polyrepository-ի լռելյայն վարքագիծը մեկուսացումն է, սա է ամբողջ խնդիրը: Monarepository-ի լռելյայն վարքագիծը համատեղ պատասխանատվությունն ու թափանցիկությունն է, սա է ամբողջ խնդիրը: Երկու դեպքում էլ ես պատրաստվում եմ ստեղծել գործիք, որը կհարթեցնի կոպիտ եզրերը: Որպես առաջնորդ՝ ես ամեն անգամ կընտրեմ մոնոպոզիտորիա, քանի որ գործիքները պետք է ամրապնդեն իմ ուզած մշակույթը, իսկ մշակույթը բխում է փոքրիկ որոշումներից և թիմի ամենօրյա աշխատանքից:
Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ , խնդրում եմ:
Ովքե՞ր են ամենամեծ ֆանատիկոսները: Աջակիցներ.
-
Մոնորեպո
-
Ժանգոտվել
-
Սխալ հարցում / երկուսն էլ
Քվեարկել է 33 օգտատեր։ 13 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com