د کورس زده کونکو لپاره چمتو شوي مقالې ژباړه د OTUS تعلیمي پروژه کې.
تاسو باید یو monorepository غوره کړئ ځکه چې هغه چلند چې دا ستاسو په ټیمونو کې وده کوي روڼتیا او شریک مسؤلیت دی، په ځانګړې توګه کله چې ټیمونه وده کوي. په هرصورت، تاسو باید په وسیلو کې پانګه اچونه وکړئ، مګر دا تل غوره وي که ډیفالټ چلند هغه چلند وي چې تاسو یې په خپلو امرونو کې غواړئ.
ولې موږ د دې په اړه خبرې کوو؟
میټ کلین مقاله لیکلې (د ژباړونکي یادونه: په هابري کې ژباړه ). زه میټ خوښوم ، زه فکر کوم هغه خورا هوښیار دی او تاسو باید د هغه نظر ولولئ. هغه په اصل کې په ټویټر کې نظرپوښتنه خپره کړه:
ژباړه:
دا د نوي کال په ورځ، زه د دې په اړه بحث کوم چې څومره مسخره منورپوزیټرۍ دي. 2019 په خاموشۍ سره پیل شو. د دې په روح کې، زه تاسو ته یوه سروې وړاندیز کوم. لوی متعصبین څوک دي؟ ملاتړي:
- Monorepo
- سوله
- ناسمه ټولپوښتنه / دواړه
زما ځواب دا و، "زه په حقیقت کې دا دواړه خلک یم." د دې پرځای چې د دې په اړه وغږیږئ چې زنګ څنګه مخدره توکي دي ، راځئ چې وګورو چې ولې زه فکر کوم هغه د مونورپوزیټریو په اړه غلط دی. د خپل ځان په اړه لږ څه. زه د شیف سافټویر CTO یم. موږ شاوخوا 100 انجنیران لرو، د کوډ بیس شاوخوا 11-12 کاله مخکې ځي، او 4 اصلي محصولات. د دې کوډ څخه ځینې یې په پولی ریپوزیټري کې دي (زما د پیل موقعیت) ، ځینې یې په مونورپوزیټري کې دي (زما اوسنی موقعیت).
مخکې لدې چې زه پیل کړم: هر دلیل چې زه یې دلته کوم د دواړو ډولونو ذخیره کولو باندې پلي کیږي. زما په اند، هیڅ تخنیکي دلیل شتون نلري چې تاسو باید د بل په پرتله یو ډول ذخیره غوره کړئ. تاسو کولی شئ په هره طریقه کار وکړئ. زه په دې اړه خبرې کولو ته خوشحاله یم، مګر زه د مصنوعي تخنیکي دلایلو سره علاقه نه لرم چې ولې یو له بل څخه غوره دی.
زه د میټ د ټکي له لومړۍ برخې سره موافق یم:
ځکه چې په پیمانه ، یو مونورپوزیټري به ټولې ورته ستونزې حل کړي چې یو پولی ریپوزیټري حل کوي ، مګر په ورته وخت کې تاسو دې ته اړ باسي چې خپل کوډ په کلکه جوړه کړئ او ستاسو د نسخې کنټرول سیسټم توزیع کولو لپاره د نه منلو وړ هڅو ته اړتیا لري.
تاسو باید ورته ستونزې حل کړئ پرته لدې چې تاسو یو مونورپوزیټري غوره کړئ یا پولی ریپوزیټري. تاسو څنګه ریلیزونه خپروئ؟ د تازه معلوماتو لپاره ستاسو تګلاره څه ده؟ شاته مطابقت؟ د پروژې انحصارونه؟ کوم معماري سټایلونه د منلو وړ دي؟ تاسو څنګه خپل جوړښت او ازموینې زیربنا اداره کوئ؟ لیست نه ختمیدونکی دی. او تاسو به دا ټول حل کړئ لکه څنګه چې تاسو وده کوئ. هیڅ وړیا پنیر نشته.
زه فکر کوم چې د Matt دلیل د ډیری انجنیرانو (او مدیرانو) لخوا شریک شوي نظرونو ته ورته دی چې زه یې درناوی کوم. دا د انجینر له لید څخه پیښیږي چې په اجزا کې کار کوي یا ټیم چې په اجزا کې کار کوي. تاسو داسې شیان اورئ لکه:
- کوډبیس خورا لوی دی - زه دې ټولو جنک ته اړتیا نلرم.
- دا ازموینه کول سخت دي ځکه چې زه باید دا ټول فضول معاینه کړم چې زه ورته اړتیا نلرم.
- د بهرني انحصار سره کار کول خورا ستونزمن دي.
- زه خپل مجازی نسخه کنټرول سیسټمونو ته اړتیا لرم.
البته، دا ټول ټکي د توجیه وړ دي. دا په دواړو قضیو کې پیښیږي - په پولی ریپوزیټوري کې زه خپل کثافات لرم ، سربیره پردې چې د جوړولو لپاره اړین دي ... زه ممکن نورو کثافاتو ته هم اړتیا ولرم. نو زه "ساده" وسیلې رامینځته کوم چې ټوله پروژه چیک کړي. یا زه د فرعي ماډلونو سره جعلي مونورپوزیټوري جوړوم. موږ کولی شو ټوله ورځ د دې شاوخوا ګرځي. مګر زه فکر کوم چې د میټ استدلال اصلي دلیل له لاسه ورکوي ، کوم چې ما د مونورپوزیټري په ګټه خورا ډیر فلیپ کړی:
دا ارتباط هڅوي او ستونزې ښیې
کله چې موږ ذخیره جلا کوو، موږ د همغږۍ او روڼتیا اصلي ستونزه رامنځته کوو. دا د هغه طریقې سره مطابقت لري چې موږ د ټیمونو په اړه فکر کوو (په ځانګړې توګه هغه طریقه چې انفرادي غړي د دوی په اړه فکر کوي): موږ د یوې ځانګړې برخې مسولیت لرو. موږ په نسبي انزوا کې کار کوو. حدود زما په ټیم او هغه برخو (جزو) باندې ټاکل شوي چې موږ یې کار کوو.
لکه څنګه چې جوړښت ډیر پیچلی کیږي، یو ټیم نور نشي کولی دا یوازې اداره کړي. ډیر لږ انجینران ټول سیسټم په خپل سر کې لري. راځئ چې ووایو چې تاسو د یوې ګډې برخې A اداره کوئ چې د ټیمونو B، C، او D لخوا کارول کیږي. ټیم A بیا کار کوي، د API ښه کول، او همدارنګه د داخلي تطبیق بدلول. د پایلې په توګه، بدلونونه د شا سره مطابقت نلري. تاسو څه مشوره لرئ؟
- ټول هغه ځایونه ومومئ چیرې چې زاړه API کارول کیږي.
- ایا داسې ځایونه شتون لري چیرې چې نوی API نشي کارول کیدی؟
- ایا تاسو کولی شئ نورې برخې حل او ازموینه وکړئ ترڅو ډاډ ترلاسه کړئ چې دوی مات نه کوي؟
- ایا دا ټیم کولی شي همدا اوس ستاسو بدلونونه ازموي؟
مهرباني وکړئ په یاد ولرئ چې دا پوښتنې د ذخیره کولو ډول څخه خپلواک دي. تاسو به د B، C او D ټیمونو موندلو ته اړتیا لرئ. تاسو به د دوی سره خبرې وکړئ، وخت ومومئ، د دوی لومړیتوبونه درک کړئ. لږترلږه موږ هیله لرو چې تاسو به یې وکړئ.
هیڅوک واقعیا نه غواړي دا وکړي. دا یوازې د زیان API فکس کولو په پرتله خورا لږ ساتیري ده. دا ټول انسانان او خندا دي. په پولی ریپوزیټری کې، تاسو کولی شئ په ساده ډول بدلونونه رامینځته کړئ، هغه خلکو ته ورکړئ چې په هغه برخه کې کار کوي (شاید B، C یا D نه وي) د بیاکتنې لپاره، او حرکت وکړئ. ټیمونه B، C او D کولی شي یوازې د اوس لپاره د دوی اوسني نسخې سره پاتې شي. دوی به نوي شي کله چې دوی ستاسو وړتیا درک کړي!
په منورپوزیټري کې، مسؤلیت د ډیفالټ لخوا لیږدول کیږي. A ټیم خپله برخه بدلوي او که احتیاط ونه کړي، سمدلاسه B، C او D ماتوي. دا د B، C او D د A دروازې ته د ښودلو لامل کیږي، حیرانتیا چې ولې A ټیم مجلس مات کړ. دا A ته درس ورکوي چې دوی نشي کولی زما پورته لیست پریږدي. دوی باید د هغه څه په اړه خبرې وکړي چې دوی یې کوي. ایا B، C او D حرکت کولی شي؟ څه که B او C کولی شي، مګر D د زاړه الګوریتم چلند د یوې خوا اغیزې سره نږدې تړاو درلود؟
بیا موږ باید په دې اړه وغږیږو چې موږ به څنګه له دې حالت څخه راووځو:
- د ډیری داخلي APIs لپاره ملاتړ کوي، او زاړه الګوریتم به د تخریب شوي په توګه په نښه کړي تر هغه چې D یې کارول ودروي.
- د ډیری ریلیز نسخو لپاره ملاتړ ، یو د زاړه انٹرفیس سره ، یو له نوي سره.
- د A بدلونونو خوشې کول تر هغه وخته پورې ځنډول چې B، C، او D کولی شي په ورته وخت کې دا ومني.
راځئ چې ووایو موږ 1، څو APIs غوره کړي دي. پدې حالت کې موږ د کوډ دوه ټوټې لرو. زاړه او نوي. په ځینو حالتونو کې خورا اسانه. موږ زوړ کوډ بیرته دننه ګورو، د ضایع شوي په توګه یې په نښه کوو، او د D ټیم سره د لیرې کولو مهال ویش سره موافق یو. د پولی او مونو ذخیره کولو لپاره اساسا یو شان.
د ډیری نسخو خوشې کولو لپاره، موږ څانګې ته اړتیا لرو. اوس موږ دوه برخې لرو - A1 او A2. ټیم B او C A2 کاروي او D A1 کاروي. موږ هرې برخې ته اړتیا لرو چې د خوشې کیدو لپاره چمتو وي ځکه چې د امنیت تازه کولو او نورو بګ فکسونو ته اړتیا لیدل کیدی شي مخکې لدې چې D پرمخ لاړ شي. په پولی ریپوزیټری کې، موږ کولی شو دا په اوږد مهاله څانګه کې پټ کړو چې ښه احساس کوي. په monorepository کې، موږ کوډ مجبور کوو چې په نوي ماډل کې جوړ شي. ټیم D به لاهم د "زاړه" برخې کې بدلونونه رامینځته کړي. هرڅوک کولی شي هغه لګښت وګوري چې موږ یې دلته تادیه کوو - موږ اوس دوه چنده کوډ لرو، او کوم بګ فکسونه چې په A1 او A2 کې پلي کیږي باید په دواړو کې پلي شي. په پولی ریپوزیټری کې د شاخ کولو طریقې سره، دا د چیری پک شاته پټ دی. موږ لګښت ټیټ ګڼو ځکه چې هیڅ نقل شتون نلري. له عملي نظره، لګښت یو شان دی: تاسو به دوه په پراخه کچه ورته کوډبیسونه جوړ کړئ، خوشې کړئ او وساتئ تر هغه چې تاسو نشئ کولی یو له دوی څخه حذف کړئ. توپیر دا دی چې د monorepository سره دا درد مستقیم او څرګند دی. دا نور هم بد دی، او دا ښه دی.
په نهایت کې ، موږ دریم ټکي ته ورسیدو. د خوشې کولو ځنډ. دا ممکنه ده چې د A لخوا رامینځته شوي بدلونونه به د A ټیم ژوند ښه کړي. مهم، مګر بیړني ندي. ایا موږ یوازې ځنډولی شو؟ په پولی ریپوزیټری کې، موږ دا د هنري اثارو د پنولو لپاره فشار راوړو. البته موږ دا ټیم D ته وایو. یوازې په زاړه نسخه کې پاتې شئ تر هغه چې تاسو ترلاسه کوئ! دا تاسو د ډارونکي لوبې کولو لپاره تنظیموي. ټیم A د دوی برخې باندې کار کولو ته دوام ورکوي ، دا حقیقت له پامه غورځوي چې ټیم D په زیاتیدونکي ډول پخوانی نسخه کاروي (دا د ټیم D ستونزه ده ، دوی احمق دي). په ورته وخت کې، ټیم D د کوډ ثبات په اړه د ټیم A بې پروایی چلند په اړه خرابې خبرې کوي، که دوی په دې اړه خبرې وکړي. میاشتې تیریږي. په پای کې، ټیم D پریکړه کوي چې د تازه کولو امکانات وګوري، مګر A یوازې نور بدلونونه لري. A ټیم په سختۍ سره په یاد دي چې کله یا څنګه دوی D مات کړل. اپ گریڈ ډیر دردناک دی او ډیر وخت نیسي. کوم چې دا د لومړیتوب سټیک ته نور هم لیږي. تر هغې ورځې پورې چې موږ په A کې امنیتي مسله لرو چې موږ یې د څانګې جوړولو ته اړ باسو. ټیم A باید په وخت سره بیرته لاړ شي، یو ټکی ومومئ کله چې D مستحکم و، ستونزه هلته حل کړئ، او د خوشې کولو لپاره یې چمتو کړئ. دا د حقیقت انتخاب دی چې خلک یې کوي، او دا تر ټولو بد دی. دا د ټیم A او ټیم D دواړو لپاره ښه ښکاري تر هغه چې موږ یو بل له پامه غورځوو.
په monorepository کې، دریم واقعیا یو اختیار ندی. تاسو مجبور یاست چې له دوو لارو څخه په یوه کې د وضعیت سره معامله وکړئ. تاسو اړتیا لرئ د دوه خوشې کولو څانګو لګښتونه وګورئ. زده کړئ چې خپل ځان د تازه معلوماتو څخه خوندي کړئ چې شاته مطابقت ماتوي. مګر تر ټولو مهم: تاسو نشئ کولی د ستونزمن خبرو اترو څخه مخنیوی وکړئ.
زما په تجربه کې، کله چې ټیمونه لوی شي، دا نور امکان نلري چې ټول سیسټم په ذهن کې وساتئ، او دا خورا مهمه برخه ده. تاسو باید په سیسټم کې د اختلاف لید ته وده ورکړئ. تاسو باید په فعاله توګه کار وکړئ ترڅو ټیمونه ترلاسه کړئ ترڅو د دوی برخو څخه لیرې وي او د نورو ټیمونو او مصرف کونکو کار وګورئ.
هو، تاسو کولی شئ هغه وسیلې رامینځته کړئ چې د پولی ریپوزیټري ستونزې حل کولو هڅه کوي. مګر زما تجربه چې په لویو تصدیو کې د دوامداره تحویلي او اتومات درس ورکوي ماته دا وایی: د اضافي وسیلو کارولو پرته ډیفالټ چلند هغه چلند دی چې تاسو یې تمه لرئ. د پولی ریپوزیټری ډیفالټ چلند انزوا دی ، دا ټول ټکی دی. د monorepository ډیفالټ چلند شریک مسؤلیت او روڼتیا ده، دا ټول ټکی دی. په دواړو حالتونو کې، زه به یو داسې وسیله رامینځته کړم چې ناڅاپه څنډې یې نرمې کړي. د یو مشر په توګه، زه به هر وخت یو monorepository غوره کړم ځکه چې وسیلې باید هغه کلتور تقویه کړي چې زه یې غواړم، او کلتور د کوچنیو پریکړو او د ټیم ورځني کار څخه راځي.
یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. مهرباني وکړئ
تر ټولو لوی متعصب څوک دي؟ ملاتړي:
-
Monorepo
-
سوله
-
ناسمه ټولپوښتنه / دواړه
33 کاروونکو رایه ورکړه. 13 کاروونکي منع شوي.
سرچینه: www.habr.com