Monorepo ವರ್ಸಸ್ multirepo
ವಿಷಯಗಳು:
ಸಾರಾಂಶ
ಸಮಸ್ಯೆ
ನಮ್ಮ ಯೋಜನೆಯು ಮೂರು ಪ್ರಮುಖ ವರ್ಗದ ತಂತ್ರಾಂಶವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದನ್ನು ಒಳಗೊಂಡಿದೆ:
- ಫ್ರಂಟ್-ಎಂಡ್ GUI ಗಳು
- ಮಿಡಲ್ವೇರ್ ಸೇವೆಗಳು
- ಬ್ಯಾಕ್-ಎಂಡ್ ಸರ್ವರ್ಗಳು
ನಾವು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ, ನಮ್ಮ ಮೂಲ ಕೋಡ್ ನಿರ್ವಹಣೆ (SCM) ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆ (VCS) git ಆಗಿದೆ.
ನಮ್ಮ ಕೋಡ್ ಅನ್ನು ಸಂಘಟಿಸಲು ನಾವು git ಅನ್ನು ಹೇಗೆ ಬಳಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಾವು ಆರಿಸಬೇಕು.
ಉನ್ನತ ಮಟ್ಟದ ಆಯ್ಕೆ "monorepo" ಅಥವಾ "polyrepo" ಅಥವಾ "ಹೈಬ್ರಿಡ್" ಆಗಿ ಸಂಘಟಿಸುವುದು:
- Monorepo ಎಂದರೆ ನಾವು ಎಲ್ಲಾ ತುಣುಕುಗಳನ್ನು ಒಂದು ದೊಡ್ಡ ರೆಪೊದಲ್ಲಿ ಇಡುತ್ತೇವೆ
- Polyrepo ಎಂದರೆ ನಾವು ಪ್ರತಿ ತುಣುಕನ್ನು ತನ್ನದೇ ರೆಪೊದಲ್ಲಿ ಇಡುತ್ತೇವೆ
- ಹೈಬ್ರಿಡ್ ಎಂದರೆ monorepo ಮತ್ತು polyrepo ದ ಕೆಲವು ಮಿಶ್ರಣ
ಹೆಚ್ಚಿನದಕ್ಕಾಗಿ ದಯವಿಟ್ಟು https://github.com/joelparkerhenderson/monorepo-vs-polyrepo ನೋಡಿ
ನಿರ್ಧಾರ
ಸಂಸ್ಥೆ/ತಂಡ/ಯೋಜನೆ ತುಲನಾತ್ಮಕವಾಗಿ ಚಿಕ್ಕದಾಗಿದ್ದಾಗ ಮತ್ತು ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡುವುದಕ್ಕಿಂತ ತ್ವರಿತ ಪುನರಾವರ್ತನೆ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯಾಗಿದ್ದಾಗ monorepo.
ಸಂಸ್ಥೆ/ತಂಡ/ಯೋಜನೆ ತುಲನಾತ್ಮಕವಾಗಿ ದೊಡ್ಡದಾಗಿದ್ದಾಗ ಮತ್ತು ತ್ವರಿತ ಪುನರಾವರ್ತನೆಗಿಂತ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡುವುದು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯಾಗಿದ್ದಾಗ polyrepo.
ಸ್ಥಿತಿ
ನಿರ್ಧರಿಸಲಾಗಿದೆ. monorepo ಗಳು ಮತ್ತು/ಅಥವಾ polyrepo ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಹೊಸ ಸಾಧನಗಳು ಲಭ್ಯವಾದರೆ/ಲಭ್ಯವಾದಾಗ ಪುನರ್ಪರಿಶೀಲಿಸಲು ಮುಕ್ತವಾಗಿದ್ದೇವೆ.
ವಿವರಗಳು
ಊಹೆಗಳು
ನಾವು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವ ಎಲ್ಲಾ ಕೋಡ್ ಒಂದು ಸಂಸ್ಥೆಯ ಕೊಡುಗೆಗಳಿಗಾಗಿ ಇದೆ, ಸಾರ್ವಜನಿಕರಿಗಾಗಿ ಅಲ್ಲ. ಅಂದರೆ ಬ್ರೋಕರ್-ಡೀಲರ್ ಸಾರ್ವಜನಿಕ ಸ್ವಯಂಸೇವಕ ಡೆವಲಪರ್ಗಳಂತಹ ಯಾವುದನ್ನೂ ಹೊಂದುವ ಗುರಿ ಹೊಂದಿಲ್ಲ.
ನಿರ್ಬಂಧಗಳು
ನಿರ್ಬಂಧಗಳನ್ನು https://github.com/joelparkerhenderson/monorepo-vs-polyrepo ನಲ್ಲಿ ಚೆನ್ನಾಗಿ ದಾಖಲಿಸಲಾಗಿದೆ
ನಿಲುವುಗಳು
Google, Facebook ಇತ್ಯಾದಿಗಳ ಶೈಲಿಯಲ್ಲಿ monorepo ಗಳನ್ನು ನಾವು ಪರಿಗಣಿಸಿದೆವು. monorepo ವಿಸ್ತರಣೆ ಸಮಸ್ಯೆಗಳು ಬಹಳ ದೂರದ ಭವಿಷ್ಯದಲ್ಲಿವೆ, ಅವುಗಳ ಅಗತ್ಯ ಬಂದಾಗ ನಾವು Google ಮತ್ತು Facebook ನ ಅದೇ ಅಭ್ಯಾಸಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.
Google Android, Facebook React ಇತ್ಯಾದಿಗಳಂತಹ ವಿಶಿಷ್ಟ Git ಮುಕ್ತ ಮೂಲ ಯೋಜನೆಗಳ ಶೈಲಿಯಲ್ಲಿ polyrepo ಗಳನ್ನು ನಾವು ಪರಿಗಣಿಸಿದೆವು. ಸಾರ್ವಜನಿಕರ ಭಾಗವಹಿಸುವಿಕೆಗೆ (ಉದಾ. ಜಗತ್ತಿನ ಯಾರಾದರೂ ಕೋಡ್ ಮೇಲೆ ಕೆಲಸ ಮಾಡಬಹುದು) ಮತ್ತು ವೈಯಕ್ತಿಕ ಲಭ್ಯತೆಗೆ (ಉದಾ. ಯೋಜನೆಯನ್ನು ಬೇರೆ ಯಾವುದೇ ತುಣುಕುಗಳಿಲ್ಲದೆ ಸ್ವತಂತ್ರವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ) ಇವು ಅತ್ಯುತ್ತಮ ಆಯ್ಕೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.
ವಾದ
ಸಂಸ್ಥೆ/ತಂಡ/ಯೋಜನೆ ತುಲನಾತ್ಮಕವಾಗಿ ಚಿಕ್ಕದಾಗಿದ್ದಾಗ, ನಾವು monorepo ಆರಿಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡುವುದಕ್ಕಿಂತ ತ್ವರಿತ ಪುನರಾವರ್ತನೆ ಆದ್ಯತೆಯಲ್ಲಿ ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚು
ಸಂಸ್ಥೆ/ತಂಡ/ಯೋಜನೆ ತುಲನಾತ್ಮಕವಾಗಿ ದೊಡ್ಡದಾಗಿದ್ದಾಗ, ನಾವು polyrepo ಆರಿಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ತ್ವರಿತ ಪುನರಾವರ್ತನೆಗಿಂತ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡುವುದು ಆದ್ಯತೆಯಲ್ಲಿ ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚು.
ಪರಿಣಾಮಗಳು
CI+CD ಗೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪೈಪ್ಲೈನ್ ಇದ್ದರೆ, ಒಂದು ರೆಪೊದೊಳಗೆ ಬಹು ಯೋಜನೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ನಾವು ಅದನ್ನು ಹೊಂದಿಸಬೇಕಾಗಬಹುದು.
CI+CD monorepo ದಲ್ಲಿನ ಎಲ್ಲಾ ಯೋಜನೆಗಳನ್ನು ಬಿಲ್ಡ್ ಮಾಡಬಹುದಾದ್ದರಿಂದ, monorepo ಗಾಗಿ ಪೂರ್ಣ ಬಿಲ್ಡ್ಗೆ ಹೆಚ್ಚಿನ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು.
ಸಂಸ್ಥೆ/ತಂಡ/ಯೋಜನೆ ಬೆಳೆದರೆ, monorepo ವಿಸ್ತರಣೆ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ.
monorepo ವಿಸ್ತರಣೆ ಸಮಸ್ಯೆಗಳು polyrepo ಗೆ ಪರಿವರ್ತನೆಯನ್ನು ಹೆಚ್ಚೆಚ್ಚು ಮೌಲ್ಯಯುತವಾಗಿಸಬಹುದು.
monorepo ದಿಂದ polyrepo ಗೆ ಪರಿವರ್ತನೆ ಒಂದು ಗಣನೀಯ devops ಕಾರ್ಯ, ಮತ್ತು ಅದನ್ನು ಯೋಜಿಸಬೇಕು, ನಿರ್ವಹಿಸಬೇಕು ಮತ್ತು ಪ್ರೋಗ್ರಾಮ್ ಮಾಡಬೇಕು.
ಸಂಬಂಧಿತ
ಸಂಬಂಧಿತ ನಿರ್ಧಾರಗಳು
monorepo ಗಳನ್ನು (ಉದಾ. Google Bazel) ಮತ್ತು polyrepo ಗಳನ್ನು (ಉದಾ. Lyft Refactorator) ನಿರ್ವಹಿಸಲು ಸಂಬಂಧಿತ ಸಾಧನಗಳಿಗೆ ನಾವು ನಿರ್ಧಾರಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ.
ಸಂಬಂಧಿತ ಅವಶ್ಯಕತೆಗಳು
git ನೊಂದಿಗೆ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುವಂತೆ ನಾವು CI+CD ಪೈಪ್ಲೈನ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕು.
ಸಂಬಂಧಿತ ಆರ್ಟಿಫ್ಯಾಕ್ಟುಗಳು
ಪೂರೈಕೆ, ಸಂರಚನಾ ನಿರ್ವಹಣೆ, ಪರೀಕ್ಷೆ ಮತ್ತು ಅಂತಹುದೇ devops ಕ್ಷೇತ್ರಗಳಿಗೆ ರೆಪೊ ಸಂಘಟನೆಯು ಸಂಬಂಧಿತ ಆರ್ಟಿಫ್ಯಾಕ್ಟುಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ ಎಂದು ನಾವು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ.
ಸಂಬಂಧಿತ ತತ್ವಗಳು
ಸುಲಭವಾಗಿ ಹಿಂದಿರುಗಿಸಬಹುದಾದ. monorepo ಪ್ರಾಯೋಗಿಕವಾಗಿ ಕೆಲಸ ಮಾಡದಿದ್ದರೆ, ಅಥವಾ ನಾಯಕತ್ವಕ್ಕೆ ಬೇಡವಾದರೆ, polyrepo ಗೆ ಬದಲಾಯಿಸುವುದು ಸರಳ.
ಗ್ರಾಹಕ ಗೀಳು. ಯೋಜನೆಯನ್ನು ಗ್ರಾಹಕರ ಕೈಗೆ ತಲುಪಿಸುವುದನ್ನು ನಾವು ಮೌಲ್ಯೀಕರಿಸುತ್ತೇವೆ, ಮತ್ತು monoreop ನಮ್ಮನ್ನು polyrepo ಗಿಂತ ವೇಗವಾಗಿ ಅಲ್ಲಿಗೆ ತಲುಪಿಸಬಲ್ಲದು ಮತ್ತು ವೇಗವಾಗಿ ಪುನರಾವರ್ತಿಸಲೂ ಸಹಾಯ ಮಾಡಬಲ್ಲದು ಎಂದು ನಾವು ನಂಬುತ್ತೇವೆ.
ದೊಡ್ಡದಾಗಿ ಯೋಚಿಸಿ. ಎಲ್ಲಾ ಮೂಲ ಕೊಡುಗೆಗಳನ್ನು ಒಟ್ಟಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದು/ಪರೀಕ್ಷಿಸಬಹುದು/ನಿಯೋಜಿಸಬಹುದಾದ್ದರಿಂದ, Google ಮತ್ತು Facebook polyrepo ಗಳಿಗಿಂತ monorepo ಗಳ ಬಲವಾದ ಪ್ರತಿಪಾದಕರು.
ಟಿಪ್ಪಣಿಗಳು
ಯಾವುದೇ ಟಿಪ್ಪಣಿಗಳನ್ನು ಇಲ್ಲಿ ಸೇರಿಸಿ.