Monorepo ប្រៀបធៀប multirepo

មាតិកា៖

• សង្ខេប
  • បញ្ហា
  • ការសម្រេចចិត្ត
  • ស្ថានភាព
• ព័ត៌មានលម្អិត
  • ការសន្មត់
  • ឧបសគ្គ
  • ជំហរ
  • អាគុយម៉ង់
  • ផលវិបាក
• ពាក់ព័ន្ធ
  • ការសម្រេចចិត្តពាក់ព័ន្ធ
  • តម្រូវការពាក់ព័ន្ធ
  • វត្ថុពាក់ព័ន្ធ
  • គោលការណ៍ពាក់ព័ន្ធ
• កំណត់ចំណាំ

សង្ខេប

បញ្ហា

គម្រោងរបស់យើងពាក់ព័ន្ធនឹងការអភិវឌ្ឍកម្មវិធីបីប្រភេទធំៗ៖

• GUI ផ្នែកខាងមុខ
• សេវាកម្ម middleware
• ម៉ាស៊ីនមេផ្នែកខាងក្រោយ

នៅពេលយើងអភិវឌ្ឍ ប្រព័ន្ធត្រួតពិនិត្យកំណែ (VCS) នៃការគ្រប់គ្រងកូដប្រភព (SCM) របស់យើងគឺ git។

យើងត្រូវជ្រើសរើសរបៀបដែលយើងប្រើ git ដើម្បីរៀបចំកូដរបស់យើង។

ជម្រើសកម្រិតកំពូលគឺរៀបចំជា “monorepo” ឬ “polyrepo” ឬ “កូនកាត់”៖

• Monorepo មានន័យថាយើងដាក់ផ្នែកទាំងអស់ក្នុង repo ធំមួយ
• Polyrepo មានន័យថាយើងដាក់ផ្នែកនីមួយៗក្នុង repo ផ្ទាល់ខ្លួន
• កូនកាត់មានន័យថាការលាយបញ្ចូលគ្នាមួយចំនួននៃ monorepo និង polyrepo

សម្រាប់ព័ត៌មានបន្ថែម សូមមើល https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

ការសម្រេចចិត្ត

Monorepo នៅពេលអង្គការ/ក្រុម/គម្រោងមួយមានទំហំតូចប្រៀបធៀប ហើយការធ្វើវដ្តលឿនមានអាទិភាពខ្ពស់ជាងការរក្សាស្ថិរភាព។

Polyrepo នៅពេលអង្គការ/ក្រុម/គម្រោងមួយមានទំហំធំប្រៀបធៀប ហើយការរក្សាស្ថិរភាពមានអាទិភាពខ្ពស់ជាងការធ្វើវដ្តលឿន។

ស្ថានភាព

បានសម្រេច។ បើកចំហក្នុងការពិនិត្យឡើងវិញ ប្រសិនបើ/នៅពេលដែលឧបករណ៍ថ្មីអាចរកបានសម្រាប់គ្រប់គ្រង monorepo និង/ឬ polyrepo។

ព័ត៌មានលម្អិត

ការសន្មត់

កូដទាំងអស់ដែលយើងកំពុងអភិវឌ្ឍគឺសម្រាប់ការផ្តល់ជូនរបស់អង្គការមួយ មិនមែនសម្រាប់សាធារណជនទូទៅទេ។ ពោលគឺ Broker-Dealer មិនមានបំណងមានអ្វីដូចជាអ្នកអភិវឌ្ឍន៍ស្ម័គ្រចិត្តពីសាធារណជនទូទៅឡើយ។

ឧបសគ្គ

ឧបសគ្គត្រូវបានចងក្រងឯកសារយ៉ាងល្អនៅ https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

ជំហរ

យើងបានពិចារណា monorepo តាមរចនាប័ទ្មរបស់ Google, Facebook ។ល។ យើងគិតថាបញ្ហាការពង្រីកណាមួយរបស់ monorepo គឺនៅឆ្ងាយក្នុងអនាគត ដែលយើងនឹងអាចប្រើការអនុវត្តដូចគ្នានឹង Google និង Facebook នៅពេលដែលយើងត្រូវការវា។

យើងបានពិចារណា polyrepo តាមរចនាប័ទ្មរបស់គម្រោងកូដចំហ Git ធម្មតា ដូចជា Google Android, Facebook React ។ល។ យើងគិតថាទាំងនេះជាជម្រើសល្អបំផុតសម្រាប់ការចូលរួមពីសាធារណជនទូទៅ (ឧ. នរណាម្នាក់ក្នុងពិភពលោកអាចធ្វើការលើកូដ) និងភាពអាចរកបានជាបុគ្គល (ឧ. គម្រោងត្រូវបានប្រើដោយឯកឯង ដោយមិនមានផ្នែកផ្សេងទៀត)។

អាគុយម៉ង់

នៅពេលអង្គការ/ក្រុម/គម្រោងមួយមានទំហំតូចប្រៀបធៀប យើងជ្រើស monorepo ព្រោះការធ្វើវដ្តលឿនមានអាទិភាពខ្ពស់ជាងយ៉ាងច្រើនជាងការរក្សាស្ថិរភាព

នៅពេលអង្គការ/ក្រុម/គម្រោងមួយមានទំហំធំប្រៀបធៀប យើងជ្រើស polyrepo ព្រោះការរក្សាស្ថិរភាពមានអាទិភាពខ្ពស់ជាងយ៉ាងច្រើនជាងការធ្វើវដ្តលឿន។

ផលវិបាក

ប្រសិនបើមានបំពង់ CI+CD ស្រាប់ នោះយើងអាចត្រូវកែសម្រួលវាសម្រាប់សាកល្បងគម្រោងច្រើនក្នុង repo មួយ។

CI+CD អាចចំណាយពេលច្រើនជាងសម្រាប់ build ពេញលេញនៃ monorepo ព្រោះ CI+CD អាច build គម្រោងទាំងអស់ក្នុង monorepo។

ប្រសិនបើអង្គការ/ក្រុម/គម្រោងលូតលាស់ នោះ monorepo នឹងមានបញ្ហាការពង្រីក។

បញ្ហាការពង្រីករបស់ monorepo អាចធ្វើឱ្យវាកាន់តែមានតម្លៃក្នុងការផ្លាស់ប្តូរទៅ polyrepo។

ការផ្លាស់ប្តូរពី monorepo ទៅ polyrepo គឺជាកិច្ចការ devops សំខាន់ ហើយត្រូវមានការគ្រោង គ្រប់គ្រង និងសរសេរកម្មវិធី។

ពាក់ព័ន្ធ

ការសម្រេចចិត្តពាក់ព័ន្ធ

យើងនឹងបង្កើតការសម្រេចចិត្តសម្រាប់ឧបករណ៍ពាក់ព័ន្ធដើម្បីគ្រប់គ្រង monorepo (ឧ. Google Bazel) និង polyrepo (ឧ. Lyft Refactorator)។

តម្រូវការពាក់ព័ន្ធ

យើងត្រូវអភិវឌ្ឍបំពង់ CI+CD ឱ្យដំណើរការបានល្អជាមួយ git។

វត្ថុពាក់ព័ន្ធ

យើងរំពឹងថាការរៀបចំ repo នឹងមានវត្ថុពាក់ព័ន្ធសម្រាប់ការផ្តល់ធនធាន ការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ ការធ្វើតេស្ត និងផ្នែក devops ស្រដៀងគ្នា។

គោលការណ៍ពាក់ព័ន្ធ

អាចត្រឡប់វិញបានយ៉ាងងាយ។ ប្រសិនបើ monorepo មិនដំណើរការក្នុងការអនុវត្ត ឬមិនត្រូវបានចង់បានដោយថ្នាក់ដឹកនាំ វាងាយស្រួលក្នុងការប្តូរទៅ polyrepo។

ការគិតដល់អតិថិជនជាចម្បង។ យើងឱ្យតម្លៃលើការដាក់គម្រោងទៅក្នុងដៃអតិថិជន ហើយយើងជឿថា monorepo អាចនាំយើងទៅដល់ទីនោះលឿនជាង polyrepo ហើយក៏ជួយយើងធ្វើវដ្តបានលឿនជាងដែរ។

គិតឱ្យធំ។ Google និង Facebook គឺជាអ្នកគាំទ្រយ៉ាងខ្លាំងចំពោះ monorepo លើ polyrepo ព្រោះការផ្តល់ជូនស្នូលទាំងអស់អាចត្រូវបានអភិវឌ្ឍ/សាកល្បង/ដាក់ពង្រាយរួមគ្នា។

កំណត់ចំណាំ

បន្ថែមកំណត់ចំណាំណាមួយនៅទីនេះ។