ಕೋರ್ಸ್ ವಿದ್ಯಾರ್ಥಿಗಳಿಗೆ ಸಿದ್ಧಪಡಿಸಿದ ಲೇಖನದ ಅನುವಾದ "DevOps ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಪರಿಕರಗಳು" OTUS ಶೈಕ್ಷಣಿಕ ಯೋಜನೆಯಲ್ಲಿ.

ನೀವು ಮೊನೊರೆಪೊಸಿಟರಿಯನ್ನು ಆರಿಸಿಕೊಳ್ಳಬೇಕು ಏಕೆಂದರೆ ಅದು ನಿಮ್ಮ ತಂಡಗಳಲ್ಲಿ ಪ್ರಚಾರ ಮಾಡುವ ನಡವಳಿಕೆಯು ಪಾರದರ್ಶಕತೆ ಮತ್ತು ಹಂಚಿಕೆಯ ಜವಾಬ್ದಾರಿಯಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ತಂಡಗಳು ಬೆಳೆದಂತೆ. ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ, ನೀವು ಟೂಲಿಂಗ್‌ನಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಆದರೆ ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆಯು ನಿಮ್ಮ ಆಜ್ಞೆಗಳಲ್ಲಿ ನೀವು ಬಯಸುವ ನಡವಳಿಕೆಯಾಗಿದ್ದರೆ ಅದು ಯಾವಾಗಲೂ ಉತ್ತಮವಾಗಿರುತ್ತದೆ.

ನಾವು ಈ ಬಗ್ಗೆ ಏಕೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ?

ಮ್ಯಾಟ್ ಕ್ಲೈನ್ ​​ಲೇಖನವನ್ನು ಬರೆದಿದ್ದಾರೆ "ಮೊನೊರೆಪೋಸ್: ದಯವಿಟ್ಟು ಮಾಡಬೇಡಿ!"  (ಅನುವಾದಕರ ಟಿಪ್ಪಣಿ: Habré ನಲ್ಲಿ ಅನುವಾದ "ಮೊನೊರೆಪೊಸಿಟರಿಗಳು: ದಯವಿಟ್ಟು ಮಾಡಬೇಡಿ") ನಾನು ಮ್ಯಾಟ್ ಅನ್ನು ಇಷ್ಟಪಡುತ್ತೇನೆ, ಅವನು ತುಂಬಾ ಸ್ಮಾರ್ಟ್ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮತ್ತು ನೀವು ಅವರ ದೃಷ್ಟಿಕೋನವನ್ನು ಓದಬೇಕು. ಅವರು ಮೂಲತಃ ಟ್ವಿಟರ್‌ನಲ್ಲಿ ಸಮೀಕ್ಷೆಯನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿದ್ದಾರೆ:

ಅನುವಾದ:
ಈ ಹೊಸ ವರ್ಷದ ದಿನದಂದು, ಮೊನೊರೆಪೊಸಿಟರಿಗಳು ಎಷ್ಟು ಹಾಸ್ಯಾಸ್ಪದವಾಗಿವೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ವಾದಿಸಲಿದ್ದೇನೆ. 2019 ಸದ್ದಿಲ್ಲದೆ ಪ್ರಾರಂಭವಾಯಿತು. ಇದರ ಉತ್ಸಾಹದಲ್ಲಿ, ನಾನು ನಿಮಗೆ ಸಮೀಕ್ಷೆಯನ್ನು ನೀಡುತ್ತೇನೆ. ದೊಡ್ಡ ಮತಾಂಧರು ಯಾರು? ಬೆಂಬಲಿಗರು:
- ಮೊನೊರೆಪೊ
- ತುಕ್ಕು
- ತಪ್ಪಾದ ಸಮೀಕ್ಷೆ / ಎರಡೂ

ನನ್ನ ಪ್ರತಿಕ್ರಿಯೆ ಹೀಗಿತ್ತು, "ನಾನು ಅಕ್ಷರಶಃ ಆ ಇಬ್ಬರು ವ್ಯಕ್ತಿಗಳು." ರಸ್ಟ್ ಹೇಗೆ ಔಷಧವಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುವ ಬದಲು, ಮೊನೊರೆಪೊಸಿಟರಿಗಳ ಬಗ್ಗೆ ಅವನು ತಪ್ಪು ಎಂದು ನಾನು ಏಕೆ ಭಾವಿಸುತ್ತೇನೆ ಎಂದು ನೋಡೋಣ. ನಿಮ್ಮ ಬಗ್ಗೆ ಸ್ವಲ್ಪ. ನಾನು ಚೆಫ್ ಸಾಫ್ಟ್‌ವೇರ್‌ನ CTO ಆಗಿದ್ದೇನೆ. ನಾವು ಸುಮಾರು 100 ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಸುಮಾರು 11-12 ವರ್ಷಗಳ ಹಿಂದಿನ ಕೋಡ್ ಬೇಸ್ ಮತ್ತು 4 ಮುಖ್ಯ ಉತ್ಪನ್ನಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಈ ಕೋಡ್‌ನ ಕೆಲವು ಪಾಲಿರೆಪೊಸಿಟರಿಯಲ್ಲಿದೆ (ನನ್ನ ಆರಂಭಿಕ ಸ್ಥಾನ), ಕೆಲವು ಮೊನೊರೆಪೊಸಿಟರಿಯಲ್ಲಿದೆ (ನನ್ನ ಪ್ರಸ್ತುತ ಸ್ಥಾನ).

ನಾನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು: ನಾನು ಇಲ್ಲಿ ಮಾಡುವ ಪ್ರತಿಯೊಂದು ವಾದವು ಎರಡೂ ರೀತಿಯ ರೆಪೊಸಿಟರಿಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ನೀವು ಒಂದು ರೀತಿಯ ರೆಪೊಸಿಟರಿಯನ್ನು ಇನ್ನೊಂದಕ್ಕಿಂತ ಏಕೆ ಆರಿಸಬೇಕು ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ತಾಂತ್ರಿಕ ಕಾರಣವಿಲ್ಲ. ನೀವು ಯಾವುದೇ ವಿಧಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡಲು ನನಗೆ ಸಂತೋಷವಾಗಿದೆ, ಆದರೆ ಕೃತಕ ತಾಂತ್ರಿಕ ಕಾರಣಗಳಲ್ಲಿ ಒಬ್ಬರು ಇನ್ನೊಬ್ಬರಿಗಿಂತ ಶ್ರೇಷ್ಠರು ಎಂಬುದಕ್ಕೆ ನನಗೆ ಆಸಕ್ತಿಯಿಲ್ಲ.

ನಾನು ಮ್ಯಾಟ್ ಪಾಯಿಂಟ್‌ನ ಮೊದಲ ಭಾಗವನ್ನು ಒಪ್ಪುತ್ತೇನೆ:

ಏಕೆಂದರೆ ಪ್ರಮಾಣದಲ್ಲಿ, ಮೊನೊರೆಪೊಸಿಟರಿಯು ಪಾಲಿರೆಪೊಸಿಟರಿಯು ಪರಿಹರಿಸುವ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಬಿಗಿಯಾಗಿ ಜೋಡಿಸಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಆವೃತ್ತಿಯ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯ ಸ್ಕೇಲೆಬಿಲಿಟಿಯನ್ನು ಹೆಚ್ಚಿಸಲು ನಂಬಲಾಗದ ಪ್ರಯತ್ನಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ.

ನೀವು ಮೊನೊರೆಪೊಸಿಟರಿ ಅಥವಾ ಪಾಲಿರೆಪೊಸಿಟರಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದರೂ ಸಹ ನೀವು ಅದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗುತ್ತದೆ. ನೀವು ಬಿಡುಗಡೆಗಳನ್ನು ಹೇಗೆ ಬಿಡುಗಡೆ ಮಾಡುತ್ತೀರಿ? ನವೀಕರಣಗಳಿಗೆ ನಿಮ್ಮ ವಿಧಾನವೇನು? ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆ? ಕ್ರಾಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಅವಲಂಬನೆಗಳು? ಯಾವ ವಾಸ್ತುಶಿಲ್ಪದ ಶೈಲಿಗಳು ಸ್ವೀಕಾರಾರ್ಹ? ನಿಮ್ಮ ನಿರ್ಮಾಣ ಮತ್ತು ಪರೀಕ್ಷಾ ಮೂಲಸೌಕರ್ಯವನ್ನು ನೀವು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೀರಿ? ಪಟ್ಟಿ ಅಂತ್ಯವಿಲ್ಲ. ಮತ್ತು ನೀವು ಬೆಳೆದಂತೆ ನೀವು ಎಲ್ಲವನ್ನೂ ಪರಿಹರಿಸುತ್ತೀರಿ. ಉಚಿತ ಚೀಸ್ ಇಲ್ಲ.

ಮ್ಯಾಟ್ ಅವರ ವಾದವು ನಾನು ಗೌರವಿಸುವ ಅನೇಕ ಇಂಜಿನಿಯರ್‌ಗಳು (ಮತ್ತು ಮ್ಯಾನೇಜರ್‌ಗಳು) ಹಂಚಿಕೊಂಡ ವೀಕ್ಷಣೆಗಳನ್ನು ಹೋಲುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಘಟಕದ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವ ಎಂಜಿನಿಯರ್ ಅಥವಾ ಘಟಕದ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವ ತಂಡದ ದೃಷ್ಟಿಕೋನದಿಂದ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ನೀವು ಈ ರೀತಿಯ ವಿಷಯಗಳನ್ನು ಕೇಳುತ್ತೀರಿ:

• ಕೋಡ್ಬೇಸ್ ದೊಡ್ಡದಾಗಿದೆ - ನನಗೆ ಈ ಎಲ್ಲಾ ಜಂಕ್ ಅಗತ್ಯವಿಲ್ಲ.
• ಪರೀಕ್ಷೆ ಮಾಡುವುದು ಕಷ್ಟ, ಏಕೆಂದರೆ ನನಗೆ ಅಗತ್ಯವಿಲ್ಲದ ಈ ಎಲ್ಲಾ ಜಂಕ್ ಅನ್ನು ನಾನು ಪರೀಕ್ಷಿಸಬೇಕಾಗಿದೆ.
• ಬಾಹ್ಯ ಅವಲಂಬನೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಹೆಚ್ಚು ಕಷ್ಟ.
• ನನಗೆ ನನ್ನ ಸ್ವಂತ ವರ್ಚುವಲ್ ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಗಳ ಅಗತ್ಯವಿದೆ.

ಸಹಜವಾಗಿ, ಈ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಸಮರ್ಥಿಸಲಾಗುತ್ತದೆ. ಇದು ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ - ಪಾಲಿರೆಪೊಸಿಟರಿಯಲ್ಲಿ ನಾನು ನನ್ನದೇ ಆದ ಜಂಕ್ ಅನ್ನು ಹೊಂದಿದ್ದೇನೆ, ನಿರ್ಮಾಣಕ್ಕೆ ಅಗತ್ಯವಿರುವ ಒಂದಕ್ಕೆ ಹೆಚ್ಚುವರಿಯಾಗಿ ... ನನಗೆ ಇತರ ಜಂಕ್ ಕೂಡ ಬೇಕಾಗಬಹುದು. ಆದ್ದರಿಂದ ನಾನು ಸಂಪೂರ್ಣ ಯೋಜನೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಸಾಧನಗಳನ್ನು "ಸರಳವಾಗಿ" ರಚಿಸುತ್ತೇನೆ. ಅಥವಾ ನಾನು ಸಬ್ ಮಾಡ್ಯೂಲ್‌ಗಳೊಂದಿಗೆ ನಕಲಿ ಮೊನೊರೆಪೊಸಿಟರಿಯನ್ನು ರಚಿಸುತ್ತೇನೆ. ನಾವು ದಿನವಿಡೀ ಇದರ ಸುತ್ತಲೂ ನಡೆಯಬಹುದು. ಆದರೆ ಮ್ಯಾಟ್ ಅವರ ವಾದವು ಮುಖ್ಯ ಕಾರಣವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ನಾನು ಮೊನೊರೆಪೊಸಿಟರಿಯ ಪರವಾಗಿ ಸಾಕಷ್ಟು ಹೆಚ್ಚು ತಿರುಗಿಸಿದೆ:

ಇದು ಸಂವಹನವನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ತೋರಿಸುತ್ತದೆ

ನಾವು ರೆಪೊಸಿಟರಿಗಳನ್ನು ಬೇರ್ಪಡಿಸಿದಾಗ, ನಾವು ಸಮನ್ವಯ ಮತ್ತು ಪಾರದರ್ಶಕತೆಯ ವಾಸ್ತವಿಕ ಸಮಸ್ಯೆಯನ್ನು ರಚಿಸುತ್ತೇವೆ. ಇದು ತಂಡಗಳ ಬಗ್ಗೆ ನಾವು ಯೋಚಿಸುವ ವಿಧಾನಕ್ಕೆ ಅನುರೂಪವಾಗಿದೆ (ವಿಶೇಷವಾಗಿ ವೈಯಕ್ತಿಕ ಸದಸ್ಯರು ಅವರ ಬಗ್ಗೆ ಯೋಚಿಸುವ ವಿಧಾನ): ಒಂದು ನಿರ್ದಿಷ್ಟ ಘಟಕಕ್ಕೆ ನಾವು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತೇವೆ. ನಾವು ಸಾಪೇಕ್ಷ ಪ್ರತ್ಯೇಕವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ. ನನ್ನ ತಂಡ ಮತ್ತು ನಾವು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಘಟಕ(ಗಳು) ಮೇಲೆ ಗಡಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ.

ವಾಸ್ತುಶಿಲ್ಪವು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತಿದ್ದಂತೆ, ಒಂದು ತಂಡವು ಇನ್ನು ಮುಂದೆ ಅದನ್ನು ಏಕಾಂಗಿಯಾಗಿ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಕೆಲವೇ ಇಂಜಿನಿಯರ್‌ಗಳು ತಮ್ಮ ತಲೆಯಲ್ಲಿ ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿದ್ದಾರೆ. ನೀವು B, C, ಮತ್ತು D ತಂಡಗಳಿಂದ ಬಳಸಲಾಗುವ ಹಂಚಿಕೆಯ ಘಟಕ A ಅನ್ನು ನೀವು ನಿರ್ವಹಿಸುತ್ತೀರಿ ಎಂದು ಹೇಳೋಣ. ತಂಡ A ಅನ್ನು ಮರುಫಲಕಗೊಳಿಸುತ್ತಿದೆ, API ಅನ್ನು ಸುಧಾರಿಸುತ್ತಿದೆ ಮತ್ತು ಆಂತರಿಕ ಅನುಷ್ಠಾನವನ್ನು ಸಹ ಬದಲಾಯಿಸುತ್ತಿದೆ. ಪರಿಣಾಮವಾಗಿ, ಬದಲಾವಣೆಗಳು ಹಿಂದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ನೀವು ಯಾವ ಸಲಹೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ?

• ಹಳೆಯ API ಅನ್ನು ಬಳಸಿದ ಎಲ್ಲಾ ಸ್ಥಳಗಳನ್ನು ಹುಡುಕಿ.
• ಹೊಸ API ಅನ್ನು ಬಳಸಲಾಗದ ಸ್ಥಳಗಳಿವೆಯೇ?
• ಇತರ ಘಟಕಗಳು ಮುರಿಯುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನೀವು ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಬಹುದೇ ಮತ್ತು ಪರೀಕ್ಷಿಸಬಹುದೇ?
• ಈ ತಂಡಗಳು ಇದೀಗ ನಿಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಬಹುದೇ?

ಈ ಪ್ರಶ್ನೆಗಳು ರೆಪೊಸಿಟರಿ ಪ್ರಕಾರದಿಂದ ಸ್ವತಂತ್ರವಾಗಿವೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. ನೀವು B, C ಮತ್ತು D ತಂಡಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು. ನೀವು ಅವರೊಂದಿಗೆ ಮಾತನಾಡಬೇಕು, ಸಮಯವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು, ಅವರ ಆದ್ಯತೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಕನಿಷ್ಠ ನೀವು ಮಾಡುತ್ತೇವೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.

ಯಾರೂ ಇದನ್ನು ಮಾಡಲು ನಿಜವಾಗಿಯೂ ಬಯಸುವುದಿಲ್ಲ. ಡ್ಯಾಮ್ API ಅನ್ನು ಸರಿಪಡಿಸುವುದಕ್ಕಿಂತ ಇದು ತುಂಬಾ ಕಡಿಮೆ ವಿನೋದವಾಗಿದೆ. ಇದು ಎಲ್ಲಾ ಮಾನವ ಮತ್ತು ಗೊಂದಲಮಯವಾಗಿದೆ. ಪಾಲಿರೆಪೊಸಿಟರಿಯಲ್ಲಿ, ನೀವು ಸರಳವಾಗಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬಹುದು, ಅದನ್ನು ಪರಿಶೀಲಿಸಲು ಆ ಘಟಕದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಜನರಿಗೆ (ಬಹುಶಃ B, C ಅಥವಾ D ಅಲ್ಲ) ನೀಡಿ ಮತ್ತು ಮುಂದುವರಿಯಿರಿ. B, C ಮತ್ತು D ತಂಡಗಳು ಇದೀಗ ತಮ್ಮ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಉಳಿಯಬಹುದು. ಅವರು ನಿಮ್ಮ ಪ್ರತಿಭೆಯನ್ನು ಅರಿತುಕೊಂಡಾಗ ಅವರು ನವೀಕರಿಸಲ್ಪಡುತ್ತಾರೆ!

ಮೊನೊರೆಪೊಸಿಟರಿಯಲ್ಲಿ, ಜವಾಬ್ದಾರಿಯನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ. A ತಂಡವು ತಮ್ಮ ಘಟಕವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಎಚ್ಚರಿಕೆಯಿಂದ ಇಲ್ಲದಿದ್ದರೆ, ತಕ್ಷಣವೇ B, C ಮತ್ತು D ಅನ್ನು ಒಡೆಯುತ್ತದೆ. ಇದು A ನ ಬಾಗಿಲಲ್ಲಿ B, C ಮತ್ತು D ಕಾಣಿಸಿಕೊಳ್ಳಲು ಕಾರಣವಾಗುತ್ತದೆ, ತಂಡ A ಅಸೆಂಬ್ಲಿಯನ್ನು ಏಕೆ ಮುರಿದಿದೆ ಎಂದು ಆಶ್ಚರ್ಯ ಪಡುತ್ತದೆ. ಅವರು ಮೇಲಿನ ನನ್ನ ಪಟ್ಟಿಯನ್ನು ಬಿಟ್ಟುಬಿಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಇದು A ಗೆ ಕಲಿಸುತ್ತದೆ. ಅವರು ಏನು ಮಾಡಲಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ಅವರು ಮಾತನಾಡಬೇಕು. ಬಿ, ಸಿ ಮತ್ತು ಡಿ ಚಲಿಸಬಹುದೇ? B ಮತ್ತು C ಸಾಧ್ಯವಾದರೆ, ಆದರೆ D ಹಳೆಯ ಅಲ್ಗಾರಿದಮ್‌ನ ನಡವಳಿಕೆಯ ಅಡ್ಡ ಪರಿಣಾಮದೊಂದಿಗೆ ನಿಕಟ ಸಂಬಂಧ ಹೊಂದಿದ್ದರೆ?

ನಂತರ ನಾವು ಈ ಪರಿಸ್ಥಿತಿಯಿಂದ ಹೇಗೆ ಹೊರಬರುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡಬೇಕು:

1. ಬಹು ಆಂತರಿಕ API ಗಳಿಗೆ ಬೆಂಬಲ, ಮತ್ತು D ಅದನ್ನು ಬಳಸುವುದನ್ನು ನಿಲ್ಲಿಸುವವರೆಗೆ ಹಳೆಯ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಅಸಮ್ಮತಿಸಲಾಗಿದೆ ಎಂದು ಗುರುತಿಸುತ್ತದೆ.
2. ಬಹು ಬಿಡುಗಡೆಯ ಆವೃತ್ತಿಗಳಿಗೆ ಬೆಂಬಲ, ಒಂದು ಹಳೆಯ ಇಂಟರ್‌ಫೇಸ್‌ನೊಂದಿಗೆ, ಒಂದು ಹೊಸದರೊಂದಿಗೆ.
3. B, C, ಮತ್ತು D ಏಕಕಾಲದಲ್ಲಿ ಅದನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗೆ A ನ ಬದಲಾವಣೆಗಳ ಬಿಡುಗಡೆಯನ್ನು ವಿಳಂಬಗೊಳಿಸಿ.

ನಾವು 1, ಹಲವಾರು API ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಎರಡು ಕೋಡ್ ತುಣುಕುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಹಳೆಯ ಮತ್ತು ಹೊಸ. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಸಾಕಷ್ಟು ಅನುಕೂಲಕರವಾಗಿದೆ. ನಾವು ಹಳೆಯ ಕೋಡ್ ಅನ್ನು ಮತ್ತೆ ಪರಿಶೀಲಿಸುತ್ತೇವೆ, ಅದನ್ನು ಅಸಮ್ಮತಿಸಲಾಗಿದೆ ಎಂದು ಗುರುತಿಸುತ್ತೇವೆ ಮತ್ತು D ತಂಡದೊಂದಿಗೆ ತೆಗೆದುಹಾಕುವ ವೇಳಾಪಟ್ಟಿಯನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತೇವೆ. ಪಾಲಿ ಮತ್ತು ಮೊನೊ ರೆಪೊಸಿಟರಿಗಳಿಗೆ ಮೂಲಭೂತವಾಗಿ ಒಂದೇ ಆಗಿರುತ್ತದೆ.

ಬಹು ಆವೃತ್ತಿಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು, ನಮಗೆ ಶಾಖೆಯ ಅಗತ್ಯವಿದೆ. ಈಗ ನಾವು ಎರಡು ಘಟಕಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ - A1 ಮತ್ತು A2. B ಮತ್ತು C ತಂಡಗಳು A2 ಅನ್ನು ಬಳಸುತ್ತವೆ ಮತ್ತು D A1 ಅನ್ನು ಬಳಸುತ್ತದೆ. ನಮಗೆ ಪ್ರತಿಯೊಂದು ಘಟಕವು ಬಿಡುಗಡೆಗೆ ಸಿದ್ಧವಾಗಬೇಕು ಏಕೆಂದರೆ ಡಿ ಮುಂದುವರೆಯುವ ಮೊದಲು ಭದ್ರತಾ ನವೀಕರಣಗಳು ಮತ್ತು ಇತರ ದೋಷ ಪರಿಹಾರಗಳು ಅಗತ್ಯವಾಗಬಹುದು. ಪಾಲಿರೆಪೊಸಿಟರಿಯಲ್ಲಿ, ನಾವು ಇದನ್ನು ದೀರ್ಘಾವಧಿಯ ಶಾಖೆಯಲ್ಲಿ ಮರೆಮಾಡಬಹುದು ಅದು ಉತ್ತಮವಾಗಿದೆ. ಮೊನೊರೆಪೊಸಿಟರಿಯಲ್ಲಿ, ಹೊಸ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ರಚಿಸುವಂತೆ ನಾವು ಒತ್ತಾಯಿಸುತ್ತೇವೆ. ತಂಡ D ಇನ್ನೂ "ಹಳೆಯ" ಘಟಕಕ್ಕೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ನಾವು ಇಲ್ಲಿ ಪಾವತಿಸುತ್ತಿರುವ ವೆಚ್ಚವನ್ನು ಪ್ರತಿಯೊಬ್ಬರೂ ನೋಡಬಹುದು - ನಾವು ಈಗ ಎರಡು ಪಟ್ಟು ಹೆಚ್ಚು ಕೋಡ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು A1 ಮತ್ತು A2 ಗೆ ಅನ್ವಯಿಸುವ ಯಾವುದೇ ದೋಷ ಪರಿಹಾರಗಳು ಇವೆರಡಕ್ಕೂ ಅನ್ವಯಿಸಬೇಕು. ಪಾಲಿರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಕವಲೊಡೆಯುವ ವಿಧಾನದೊಂದಿಗೆ, ಇದನ್ನು ಚೆರ್ರಿ-ಪಿಕ್ ಹಿಂದೆ ಮರೆಮಾಡಲಾಗಿದೆ. ಯಾವುದೇ ನಕಲು ಇಲ್ಲದ ಕಾರಣ ವೆಚ್ಚ ಕಡಿಮೆ ಎಂದು ನಾವು ಪರಿಗಣಿಸುತ್ತೇವೆ. ಪ್ರಾಯೋಗಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ, ವೆಚ್ಚವು ಒಂದೇ ಆಗಿರುತ್ತದೆ: ನೀವು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಅಳಿಸುವವರೆಗೆ ನೀವು ಎರಡು ಒಂದೇ ರೀತಿಯ ಕೋಡ್‌ಬೇಸ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೀರಿ, ಬಿಡುಗಡೆ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ನಿರ್ವಹಿಸುತ್ತೀರಿ. ವ್ಯತ್ಯಾಸವೆಂದರೆ ಮೊನೊರೆಪೊಸಿಟರಿಯೊಂದಿಗೆ ಈ ನೋವು ನೇರ ಮತ್ತು ಗೋಚರಿಸುತ್ತದೆ. ಇದು ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿದೆ, ಮತ್ತು ಅದು ಒಳ್ಳೆಯದು.

ಅಂತಿಮವಾಗಿ, ನಾವು ಮೂರನೇ ಹಂತಕ್ಕೆ ಬಂದೆವು. ಬಿಡುಗಡೆ ವಿಳಂಬ. A ಮಾಡಿದ ಬದಲಾವಣೆಗಳು A ತಂಡದ ಜೀವನವನ್ನು ಸುಧಾರಿಸುವ ಸಾಧ್ಯತೆಯಿದೆ. ಪ್ರಮುಖ, ಆದರೆ ತುರ್ತು ಅಲ್ಲ. ನಾವು ಸುಮ್ಮನೆ ತಡಮಾಡಬಹುದೇ? ಪಾಲಿರೆಪೊಸಿಟರಿಯಲ್ಲಿ, ಕಲಾಕೃತಿಯನ್ನು ಪಿನ್ ಮಾಡಲು ನಾವು ಇದನ್ನು ತಳ್ಳುತ್ತೇವೆ. ಖಂಡಿತವಾಗಿಯೂ ನಾವು ಇದನ್ನು D ತಂಡಕ್ಕೆ ಹೇಳುತ್ತಿದ್ದೇವೆ. ನೀವು ಹಿಡಿಯುವವರೆಗೂ ಹಳೆಯ ಆವೃತ್ತಿಯಲ್ಲಿಯೇ ಇರಿ! ಇದು ಹೇಡಿತನವನ್ನು ಆಡಲು ನಿಮ್ಮನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ತಂಡವು D ತಂಡವು ಹೆಚ್ಚು ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತಿದೆ ಎಂಬ ಅಂಶವನ್ನು ನಿರ್ಲಕ್ಷಿಸಿ ತಮ್ಮ ಘಟಕದ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸಿದೆ (ಅದು ತಂಡದ D ಯ ಸಮಸ್ಯೆ, ಅವರು ಮೂರ್ಖರು). ಏತನ್ಮಧ್ಯೆ, ಟೀಮ್ D ಅವರು ಕೋಡ್ ಸ್ಥಿರತೆಯ ಬಗ್ಗೆ ಟೀಮ್ A ಯ ಅಸಡ್ಡೆ ವರ್ತನೆಯ ಬಗ್ಗೆ ಕಳಪೆಯಾಗಿ ಮಾತನಾಡುತ್ತಾರೆ, ಅವರು ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ. ತಿಂಗಳುಗಳು ಕಳೆಯುತ್ತವೆ. ಅಂತಿಮವಾಗಿ, D ತಂಡವು ನವೀಕರಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ನೋಡಲು ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದರೆ A ಮಾತ್ರ ಹೆಚ್ಚಿನ ಬದಲಾವಣೆಗಳನ್ನು ಹೊಂದಿದೆ. A ತಂಡವು D ಅನ್ನು ಯಾವಾಗ ಅಥವಾ ಹೇಗೆ ಮುರಿದುಕೊಂಡಿತು ಎಂಬುದನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಅಪ್‌ಗ್ರೇಡ್ ಹೆಚ್ಚು ನೋವಿನಿಂದ ಕೂಡಿದೆ ಮತ್ತು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಇದು ಆದ್ಯತೆಯ ಸ್ಟಾಕ್ ಅನ್ನು ಮತ್ತಷ್ಟು ಕೆಳಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ನಾವು ಶಾಖೆಯನ್ನು ಮಾಡಲು ಒತ್ತಾಯಿಸುವ A ನಲ್ಲಿ ಭದ್ರತಾ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿರುವ ದಿನದವರೆಗೆ. A ತಂಡವು ಸಮಯಕ್ಕೆ ಹಿಂತಿರುಗಬೇಕು, D ಸ್ಥಿರವಾಗಿದ್ದಾಗ ಬಿಂದುವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು, ಅಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಬಿಡುಗಡೆಗೆ ಸಿದ್ಧಗೊಳಿಸಬೇಕು. ಇದು ಜನರು ಮಾಡುವ ವಾಸ್ತವಿಕ ಆಯ್ಕೆಯಾಗಿದೆ ಮತ್ತು ಇದು ಅತ್ಯಂತ ಕೆಟ್ಟದಾಗಿದೆ. ನಾವು ಒಬ್ಬರನ್ನೊಬ್ಬರು ನಿರ್ಲಕ್ಷಿಸುವವರೆಗೆ ಇದು ತಂಡ A ಮತ್ತು D ತಂಡಕ್ಕೆ ಒಳ್ಳೆಯದು ಎಂದು ತೋರುತ್ತದೆ.

ಮೊನೊರೆಪೊಸಿಟರಿಯಲ್ಲಿ, ಮೂರನೆಯದು ನಿಜವಾಗಿಯೂ ಒಂದು ಆಯ್ಕೆಯಾಗಿಲ್ಲ. ನೀವು ಎರಡು ರೀತಿಯಲ್ಲಿ ಪರಿಸ್ಥಿತಿಯನ್ನು ಎದುರಿಸಲು ಬಲವಂತವಾಗಿ. ಎರಡು ಬಿಡುಗಡೆ ಶಾಖೆಗಳನ್ನು ಹೊಂದಿರುವ ವೆಚ್ಚವನ್ನು ನೀವು ನೋಡಬೇಕಾಗಿದೆ. ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಮುರಿಯುವ ನವೀಕರಣಗಳಿಂದ ನಿಮ್ಮನ್ನು ರಕ್ಷಿಸಿಕೊಳ್ಳಲು ಕಲಿಯಿರಿ. ಆದರೆ ಮುಖ್ಯವಾಗಿ: ನೀವು ಕಷ್ಟಕರವಾದ ಸಂಭಾಷಣೆಯನ್ನು ತಪ್ಪಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ನನ್ನ ಅನುಭವದಲ್ಲಿ, ತಂಡಗಳು ದೊಡ್ಡದಾಗುವಾಗ, ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಲು ಇನ್ನು ಮುಂದೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅದು ಅತ್ಯಂತ ಪ್ರಮುಖ ಭಾಗವಾಗಿದೆ. ನೀವು ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅಪಶ್ರುತಿಯ ಗೋಚರತೆಯನ್ನು ಸುಧಾರಿಸಬೇಕು. ತಂಡಗಳು ತಮ್ಮ ಘಟಕಗಳಿಂದ ದೂರವಿರಲು ಮತ್ತು ಇತರ ತಂಡಗಳು ಮತ್ತು ಗ್ರಾಹಕರ ಕೆಲಸವನ್ನು ನೋಡಲು ನೀವು ಸಕ್ರಿಯವಾಗಿ ಕೆಲಸ ಮಾಡಬೇಕು.

ಹೌದು, ಪಾಲಿರೆಪೊಸಿಟರಿ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಸಾಧನಗಳನ್ನು ನೀವು ರಚಿಸಬಹುದು. ಆದರೆ ದೊಡ್ಡ ಉದ್ಯಮಗಳಲ್ಲಿ ನಿರಂತರ ವಿತರಣೆ ಮತ್ತು ಯಾಂತ್ರೀಕರಣವನ್ನು ಕಲಿಸುವ ನನ್ನ ಅನುಭವವು ನನಗೆ ಇದನ್ನು ಹೇಳುತ್ತದೆ: ಹೆಚ್ಚುವರಿ ಪರಿಕರಗಳ ಬಳಕೆಯಿಲ್ಲದೆ ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆಯು ನೀವು ನೋಡಲು ನಿರೀಕ್ಷಿಸುವ ನಡವಳಿಕೆಯಾಗಿದೆ. ಪಾಲಿರೆಪೊಸಿಟರಿಯ ಪೂರ್ವನಿಯೋಜಿತ ನಡವಳಿಕೆಯು ಪ್ರತ್ಯೇಕತೆಯಾಗಿದೆ, ಅದು ಸಂಪೂರ್ಣ ಅಂಶವಾಗಿದೆ. ಮೊನೊರೆಪೊಸಿಟರಿಯ ಪೂರ್ವನಿಯೋಜಿತ ನಡವಳಿಕೆಯು ಹಂಚಿಕೆಯ ಜವಾಬ್ದಾರಿ ಮತ್ತು ಪಾರದರ್ಶಕತೆಯಾಗಿದೆ, ಅದು ಸಂಪೂರ್ಣ ಅಂಶವಾಗಿದೆ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಾನು ಒರಟು ಅಂಚುಗಳನ್ನು ಸುಗಮಗೊಳಿಸುವ ಸಾಧನವನ್ನು ರಚಿಸಲಿದ್ದೇನೆ. ನಾಯಕನಾಗಿ, ನಾನು ಪ್ರತಿ ಬಾರಿಯೂ ಮೊನೊರೆಪೊಸಿಟರಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇನೆ ಏಕೆಂದರೆ ಉಪಕರಣಗಳು ನನಗೆ ಬೇಕಾದ ಸಂಸ್ಕೃತಿಯನ್ನು ಬಲಪಡಿಸುವ ಅಗತ್ಯವಿದೆ ಮತ್ತು ಸಂಸ್ಕೃತಿಯು ಸಣ್ಣ ನಿರ್ಧಾರಗಳು ಮತ್ತು ತಂಡದ ದೈನಂದಿನ ಕೆಲಸದಿಂದ ಬರುತ್ತದೆ.

ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. ಸೈನ್ ಇನ್ ಮಾಡಿ, ದಯವಿಟ್ಟು.

ದೊಡ್ಡ ಮತಾಂಧರು ಯಾರು? ಬೆಂಬಲಿಗರು:

• ಮೊನೊರೆಪೊ

• ತುಕ್ಕು

• ತಪ್ಪಾದ ಸಮೀಕ್ಷೆ / ಎರಡೂ

33 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 13 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.

ಮೂಲ: www.habr.com