Git ගබඩාවක තනි හෝ බහු ව්‍යාපෘති අතර තෝරා ගැනීම?

දී gitඅප වඩාත් ව්යාපෘති අතරතුරේ නිරූපිකාවක් කොහෙද පරිසරය, අපි මුහුණ දෙන්නේ කියලා ගබඩාව එක් ව්යාපෘතිය හෝ ගබඩාව එක් බහු ව්යාපෘති සැලසුම් ප්රශ්නය. මොඩියුලරීකරණය කළ ව්‍යාපෘතියක් සලකා බලමු:

myProject/
   +-- gui
   +-- core
   +-- api
   +-- implA
   +-- implB

අද අපට එක් ගබඩාවකට එක් ව්‍යාපෘතියක් තිබේ. එය නිදහස ලබා දෙයි

• release තනි සංරචක
• tag තනි සංරචක

නමුත් එය ද ෆෙඩරලිස්ට් රචනා තියෙන්නේ branchබොහෝ විට අතු බෙදී සංරචක apiසමාන ශාඛා අවශ්ය core, සහ සමහර විට තවත් සංරචක.

releaseඑක් එක් සංරචක සඳහා අපට අවශ්‍ය පරිදි, නිධිය සැලසුමකට බහුවිධ ව්‍යාපෘති භාවිතා කිරීමෙන් අපට තවමත් සමාන නම්යතාවයක් ලබා ගත හැකිය .

එහි ඇති අත්දැකීම් මොනවාද සහ ඔබ මෙම ගැටළු විසඳුවේ කෙසේද / ඇයි?

one project per repositoryඔබ ඉහත විස්තර කළ ආකාරයට ප්‍රධාන අවාසි තුනක් ඇත. මේවා සැබවින්ම වෙනස් ව්‍යපෘති නම් මේවා අඩු සත්‍යයකි, නමුත් එහි ශබ්දය වෙනස් වන විට බොහෝ විට තවත් එකකට වෙනස්කම් අවශ්‍ය වේ, එමඟින් මෙම ගැටලු අතිශයෝක්තියට නැංවිය හැකිය:

1. දෝෂ හඳුන්වා දුන් විට සොයා ගැනීම දුෂ්කර ය. වැනි මෙවලම් git bisectඔබ ඔබේ නිධිය උප නිධි බවට කඩාගත්තේ විට වඩාත් අපහසු භාවිතය බවට පත් වේ. එය කළ හැකි ය, එය එතරම් පහසු නැත, එයින් අදහස් කරන්නේ අර්බුදකාරී කාලවලදී දෝෂ දඩයම් කිරීම එතරම් අපහසු නොවන බවයි.
2. අංගයක සමස්ත ඉතිහාසයම සොයා ගැනීම වඩා දුෂ්කර ය. git logබිඳුණු නිධි ව්‍යුහයන් සමඟ අර්ථවත් ලෙස ඉතිහාසය ප්‍රතිදානය නොකරන්න වැනි ඉතිහාසය හරහා ගමන් කරන විධානයන් . ඔබට උප මොඩියුල හෝ උප කුලක හෝ වෙනත් ස්ක්‍රිප්ටබල් ක්‍රම මගින් ප්‍රයෝජනවත් ප්‍රතිදානයක් ලබා ගත හැකිය , නමුත් එය ඔබ සැලකිලිමත් වන සියලු කැපවීම් ටයිප් කිරීම tig --grep=<caseID>හෝ git log --grep=<caseID>පරිලෝකනය කිරීම හා සමාන නොවේ . ඔබගේ ඉතිහාසය තේරුම් ගැනීමට අපහසු වන අතර එමඟින් ඔබට එය සැබවින්ම අවශ්‍ය වූ විට එය ප්‍රයෝජනවත් නොවේ.
3. නව සංවර්ධකයින් කේතීකරණය ආරම්භ කිරීමට පෙර අනුවාද පාලකයේ ව්‍යුහය ඉගෙන ගැනීමට වැඩි කාලයක් ගත කරයි. සෑම නව රැකියාවක් සඳහාම ක්‍රියා පටිපාටි තෝරා ගැනීම අවශ්‍ය වේ, නමුත් ව්‍යාපෘති ගබඩාවක් කැඩීම යන්නෙන් අදහස් කරන්නේ කේතයේ ගෘහ නිර්මාණ ශිල්පයට අමතරව VC ව්‍යුහය තෝරා ගැනීමයි. මගේ අත්දැකීම් අනුව, තනි ගබඩාවක් භාවිතා කරන වඩාත් සාම්ප්‍රදායික, මධ්‍යගත සාප්පු වලින් පැමිණෙන නවක සංවර්ධකයින්ට මෙය විශේෂයෙන් දුෂ්කර ය.

අවසානයේ එය ආවස්ථික පිරිවැය ගණනය කිරීමකි. එක් හිටපු සේවා යෝජකයෙකුගේ දී, අපගේ ප්‍රාථමික අයදුම්පත විවිධ උප ගබඩාවන් 35 කට බෙදා ඇත. ඒවා මත අපි ඉතිහාසය සෙවීම සඳහා සංකීර්ණ ස්ක්‍රිප්ට් කට්ටලයක් භාවිතා කළෙමු, ඒවා හරහා තත්වය (එනම් නිෂ්පාදනයට එදිරිව සංවර්ධන ශාඛා) එක හා සමාන බව සහතික කර ඒවා තනි තනිව හෝ විශාල වශයෙන් යෙදවීමට.

එය ඕනෑවට වඩා වැඩිය; අවම වශයෙන් අපට ඕනෑවට වඩා වැඩියි. කළමනාකරණ පොදු කාර්යය අපගේ අංගයන් ඉතා වේගවත් කර, යෙදවීම වඩා දුෂ්කර කරවන ලදි, නව දේවානුභාවයෙන් ඉගැන්වීමට වැඩි කාලයක් ගත කළ අතර, එය අවසන් වන විට, අප විසින් ගබඩාව මුලින් කැඩී ගියේ මන්දැයි අපට යන්තම් සිහිපත් කළ හැකිය. එක් ලස්සන වසන්ත දිනයක්, මම EC2 හි පොකුරු ගණනය කිරීමේ වේලාවක් සඳහා ඩොලර් 10 ක් වියදම් කළෙමි. මම git filter-branchඇමතුම් දුසිම් කිහිපයක් සමඟ නැවත ගබඩාව විය . අපි කවදාවත් ආපසු හැරී බැලුවේ නැහැ.

එක් ව්‍යාපෘතියකට එක් නිධිය ආකෘතියක අවාසි ගණනය කිරීම සඳහා ක්‍රිස්ටෝපර් ඉතා හොඳ කාර්යයක් ඉටු කළේය. ඔබ බහු-නිධිය ප්‍රවේශයක් සලකා බැලිය හැකි හේතු කිහිපයක් සාකච්ඡා කිරීමට මම කැමතියි. මා වැඩ කළ බොහෝ පරිසරයන් තුළ, බහු-නිධිය ප්‍රවේශයක් සාධාරණ විසඳුමක් වී ඇත, නමුත් නිධි කොපමණ ප්‍රමාණයක් තිබිය යුතුද යන්න සහ කප්පාදුව සිදු කළ යුත්තේ කොතැනද යන්න තීරණය කිරීම සැමවිටම පහසු එකක් නොවේ.

මගේ වර්තමාන ස්ථාවරය තුළ, මම වසර දහයකට වැඩි ඉතිහාසයක් සහිත බෙහෙමොත් තනි ගබඩාවක් සහිත සීවීඑස් ගබඩාවක් ගිට් ගබඩාවලට සංක්‍රමණය කළෙමි. එම ආරම්භක තීරණයෙන් පසුව, නිධි ගණන වැඩි වී ඇත (අනෙක් කණ්ඩායම්වල ක්‍රියාකාරකම් තුළින්), අප සැක කරන තැනට වඩා ප්‍රශස්ත වනු ඇත. සමහර නව කුලීකරුවන් විසින් ගබඩාවන් ඒකාබද්ධ කිරීමට යෝජනා කර ඇති නමුත් මම එයට එරෙහිව තර්ක කර ඇත්තෙමි. වේලන්ඩ් ව්‍යාපෘතියට සමාන අත්දැකීමක් තිබේ. මෑතකදී මා දුටු කතාවක දී, ඔවුන් සතුව එක් අවස්ථාවක දී ගිට් ගබඩාවන් 200 කට අධික ප්‍රමාණයක් තිබී ඇති අතර, ඒ සඳහා නායකයා සමාව ඉල්ලා සිටියේය. ඔවුන්ගේ වෙබ් අඩවිය දෙස බලන විට , දැන් ඔවුන් 5 වන වියේ පසුවන බව පෙනේ. ගබඩාවලට සම්බන්ධ වීම හා බෙදීම කළමනාකරණය කළ හැකි කාර්යයක් බව නිරීක්ෂණය කිරීම වැදගත් වන අතර, අත්හදා බැලීම සුදුසුය (හේතුව අනුව).

ඉතින් ඔබට බහු ගබඩාවන් අවශ්‍ය වන්නේ කවදාද?

1. තනි ගබඩාවක් කාර්යක්ෂම වීමට තරම් විශාල වනු ඇත.
2. ඔබේ ගබඩාවන් ලිහිල්ව සම්බන්ධ වී හෝ විසන්ධි කර ඇත.
3. සංවර්ධකයෙකුට සාමාන්‍යයෙන් අවශ්‍ය වන්නේ එකක් හෝ ඔබේ ගබඩාවල කුඩා උපකොටසක් පමණි.
4. ඔබට සාමාන්‍යයෙන් අවශ්‍ය වන්නේ නිධි ස්වාධීනව සංවර්ධනය කිරීමයි, ඒවා අවශ්‍ය වන්නේ ඉඳහිට සමමුහුර්ත කිරීම පමණි.
5. ඔබට වඩාත් මොඩියුලරිටි ධෛර්යමත් කිරීමට අවශ්‍යයි.
6. විවිධ කණ්ඩායම් විවිධ ගබඩාවල වැඩ කරති.

ලක්ෂ්‍ය 2 සහ 3 වැදගත් වන්නේ ලක්ෂ්‍ය 1 දරන්නේ නම් පමණි. අපගේ ගබඩාවන් බෙදීමෙන්, අපගේ අක්වෙරළ සගයන් අත්විඳින ප්‍රමාදය, තැටි පරිභෝජනය අඩු කිරීම සහ ජාල ගමනාගමනය වැඩි දියුණු කිරීම මම සැලකිය යුතු ලෙස අඩු කළෙමි.

4 සහ 5 වඩාත් සියුම් ය. ඔබ සේවාදායකයකු සහ සේවාදායකයකුගේ ගබඩාවන් බෙදූ විට, මෙය සේවාදායකයා සහ සේවාදායක කේතය අතර වෙනස්කම් සම්බන්ධීකරණය කිරීම වඩා මිල අධික කරයි. මෙය ධනාත්මක විය හැකිය, එමඟින් දෙදෙනා අතර විසන්ධි වූ අතුරු මුහුණතක් දිරිගන්වයි.

බහු නිධිය ව්‍යාපෘතිවල අවාසි සමඟ වුවද, ගෞරවනීය කාර්යයන් රාශියක් ඒ ආකාරයෙන් සිදු කරනු ලැබේ - මාර්ග හා තල්ලුව මතකයට එයි. හොඳම භාවිතයන් පිළිබඳ සම්මුතියක් තවම විකාශනය වී ඇතැයි මම විශ්වාස නොකරමි, යම් විනිශ්චයක් අවශ්‍ය වේ. බහුවිධ ගබඩාවන් සමඟ වැඩ කිරීමේ මෙවලම් (git-subtree, git-subodule සහ වෙනත්) තවමත් සංවර්ධනය කර අත්හදා බලා ඇත. මගේ අවවාදය නම් අත්හදා බැලීම හා ප්‍රායෝගික වීමයි.

අපි GitHub භාවිතා කරන විට, ඇත්ත වශයෙන්ම අපට එක් ගබඩාවක බහුවිධ ව්‍යාපෘති ඇති නමුත් එම ව්‍යාපෘති / මොඩියුලයන් නිසි ලෙස මොඩියුලරීකරණය කර ඇති බව සහතික කරමු (අපි -api සහ -core සම්මුතීන් + Maven + ස්ථිතික හා ධාවන කාල පරීක්ෂාවන් භාවිතා කරන අතර ආරම්භ කිරීමට එක් දිනක් OSGi වෙත යන්නෙමු) .

එයින් ඉතිරි කරන්නේ කුමක්ද? අපි විවිධ ව්‍යාපෘති හරහා කුඩා දෙයක් වෙනස් කරන්නේ නම් අපට බහු අදින්න ඉල්ලීම් නිකුත් කිරීමට අවශ්‍ය නැත. ගැටළු සහ විකිය මධ්‍යගතව තබා ඇත.

අපි තවමත් එක් එක් මොඩියුලය / ව්‍යාපෘතිය නිසි ස්වාධීන ව්‍යාපෘතියක් ලෙස සලකන අතර ඒවා අපගේ සීඅයි සේවාදායකයේ වෙන වෙනම ගොඩනඟා ඒකාබද්ධ කරමු.

මට නම්, එක් ගබඩාවක් හෝ වැඩි ගණනක් භාවිතා කිරීමේ ප්‍රධාන වෙනස වන්නේ පහත සඳහන් ප්‍රශ්නවලට පිළිතුරු ය:

• එකම කණ්ඩායම විසින් වැඩි දියුණු කරන ලද කොටස්, එකම මුදා හැරීමේ චක්‍රය, එකම පාරිභෝගිකයා තිබේද? එවිට එක් ගබඩාවක් බෙදීමට අඩු හේතු තිබේ.
• බහු කොටස් එකිනෙකා මත බෙහෙවින් රඳා පවතීද? එබැවින් එකිනෙකා මත ඉහළ යැපීම නිසා බෙදීම් ආකෘතිය, පාලකය සහ යූඅයි (ඒවා විවිධ කොටස් වුවද) ඉතා සංවේදී නොවේ. නමුත් කොටස් 2 කට ඇත්තේ කුඩා පරායත්තතාවයක් නම්, එය ස්ථායී අතුරුමුහුණතක් මඟින් ක්‍රියාත්මක වන අතර එය සෑම වසර කිහිපයකට වරක් වෙනස් වේ, එබැවින් කොටස් 2 ගබඩාවලට බෙදා වෙන් කිරීම නුවණට හුරුය.

නිදසුනක් ලෙස, මට කුඩා යෙදුමක් ඇත (සේවාදායකයාට පමණි), එය උපසිරැසි ගබඩාවක “ගුණාත්මකභාවය” පරීක්ෂා කරයි. විධාන රේඛාවෙන් ආරම්භ කළ හැකි මූලික ක්‍රියාත්මක කිරීම සහ ජාවා 6 සමඟ හොඳින් ක්‍රියා කරයි. නමුත් මම ජාවා 8 හි කොටසක් ලෙස ජාවාඑෆ්එක්ස් භාවිතා කරන යූඅයි එකක් ක්‍රියාත්මක කිරීමට පටන් ගෙන ඇත්තෙමි. එබැවින් මම 2 බෙදී, දෙවන ගබඩාව (දෙවන ගොඩනැගීමේ ක්‍රියාවලියක් සමඟ), විවිධ කාලසටහන් සමඟ, ...

මම ඉහත පිළිතුරු වලට කැමතියි (ඔවුන්ට ඡන්දය දුන්නා), නමුත් මම හිතන්නේ ඒවා සම්පූර්ණ සත්‍ය කතාව නොවේ. එබැවින් ගබඩාවන් බෙදීම සඳහා තර්ක එකතු කිරීමට මට අවශ්‍ය විය. ඉතින් නියම පිළිතුර (බෙදීමට කවදාද) මැද කොතැනක හෝ විය හැකිය ...

සමහර විට git-subtree ( ඇට්ලේෂියන් බ්ලොග් , මධ්‍යම බ්ලොග් හෝ කර්නල් සබැඳිය බලන්න ) ඔබට ඇති හොඳ සුදුසුකමක් වනු ඇත. එබැවින්, ඔබගේ සෑම ඉහළ මට්ටමේ ව්‍යාපෘතියක්ම වෙනස් අනුවාද (ය) වල උප කුලක කට්ටලයක් භාවිතා කරනු ඇත.

ඔබේ උදාහරණයෙන්, ගබඩාවන් කොතරම් එකිනෙකට පරායත්තද යන්න අනුව සැකසිය යුතුය. මයික්‍රෝ සර්විසස් සහ ඩොමේන් ඩ්‍රයිවින් ඩිසයින් සැලසුම් කිරීම පිළිබඳ සියලු තර්ක මෙහි අදාළ වේ: සමහර අවස්ථාවල අනුපිටපත් කේතය පිළිගත හැකි ය, අතුරුමුහුණත් සමඟ වැඩ කරන්න, ඔබට සැබවින්ම අවශ්‍ය නම් මිස අනුකූලතාව බිඳ නොදමන්න.

දැන් මගේ මතය අනුව UI එකක් පසුපෙළෙන් ස්වාධීන විය යුතුය. එබැවින් UI ව්‍යාපෘති ගබඩාවක සාමාන්‍යයෙන් UI කේතය සහ සේවාලාභී පාලකය අඩංගු විය යුතුය. සේවාලාභී පාලක සේවා පාලකයන් සමඟ වියුක්ත ආකාරයකින් සම්බන්ධ වේ. ඔවුන් සේවා සේවාදායකයා / ඒපී සාරාංශයක් භාවිතා කරනු ඇත, එය සේවාවෙන් වෙන් වෙන් වශයෙන් සංස්කරණය කර ඇති අතර එමඟින් සේවාදායකයා (ය) බිඳ නොගෙන සේවාවක් යාවත්කාලීන කළ හැකිය (විවිධ සේවාදායකයින් කිහිප දෙනෙකු සිටිය හැකිය).

එබැවින් සේවාවක් තමන්ගේම ගබඩාවක් විය යුතුය. මගේ මතය අනුව, මෙම සේවාව යනු තනි තනි ව්‍යාපාරික තාර්කිකත්වයේ තාර්කිකත්වය පමණි. එබැවින් ව්‍යාපාර තර්කනය සාමාන්‍යයෙන් එය සත්කාරක සේවා තාක්‍ෂණයෙන් වෙන් කළ යුතුය. අනෙක් අතට, නිධිය ක්‍රියාත්මක කිරීම සාමාන්‍යයෙන් ව්‍යාපාර තර්කනයට තදින් බැඳී ඇති අතර මෙය එකම ගබඩාවක ඒකාබද්ධ කළ හැකිය. නමුත් එහි පවා ඔබේ සැතපුම් ගණන වෙනස් විය හැකිය.

ඇත්ත වශයෙන්ම, තාක්‍ෂණය අනුව බොහෝ වෙනස් වීමට හෝ බහු ස්ථර වලට සහය දැක්වීමට අපහසු සරල ව්‍යාපෘති, සියලුම UI එකම ප්‍රභවයකින් පසුපෙළ හා සත්කාරකත්වය සැපයිය හැකි අතර පසුපස සේවා සාමාන්‍යයෙන් භාවිතා කරන්නේ එකම සේවාදායකයා විසින් පමණක් වන අතර, වැඩි ප්‍රතිලාභ ලබා ගත හැකිය. තදින් ඒකාබද්ධ කරන ලද ගබඩාවන්.

එවැනි අවස්ථාවකදී ඔබ එක් ගබඩාවක සම්පූර්ණ සිරස් අතට තබා තිබීම හොඳ විය හැකි අතර ඔබේ ක්‍රියාකාරී වසම් ඔවුන්ගේ නිධිය තුළම තනිවම ඇති බව තහවුරු කර ගැනීම කෙරෙහි අවධානය යොමු කරන්න. එවිට ඔබට තවමත් කුඩා ගබඩාවල බොහෝ වාසි ඇත.