ಹೊಸ ಪ್ರಾಜೆಕ್ಟ್ ಬಿಡುಗಡೆಯನ್ನು ಉತ್ಪಾದನೆಗೆ ತರಲು ನಿಯೋಜನೆ ವೇಗ ಮತ್ತು ಪರಿಹಾರದ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ನಡುವೆ ಎಚ್ಚರಿಕೆಯ ಸಮತೋಲನದ ಅಗತ್ಯವಿದೆ. ಸ್ಲಾಕ್ ಮೌಲ್ಯಗಳು ವೇಗದ ಪುನರಾವರ್ತನೆಗಳು, ಸಣ್ಣ ಪ್ರತಿಕ್ರಿಯೆ ಚಕ್ರಗಳು ಮತ್ತು ಬಳಕೆದಾರರ ವಿನಂತಿಗಳಿಗೆ ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕಂಪನಿಯು ನೂರಾರು ಪ್ರೋಗ್ರಾಮರ್‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಅವರು ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ಪಾದಕವಾಗಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ.
ವಸ್ತುವಿನ ಲೇಖಕರು, ನಾವು ಇಂದು ಪ್ರಕಟಿಸುತ್ತಿರುವ ಅನುವಾದ, ಅಂತಹ ಮೌಲ್ಯಗಳಿಗೆ ಬದ್ಧವಾಗಿರಲು ಶ್ರಮಿಸುವ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಬೆಳೆಯುವ ಕಂಪನಿಯು ತನ್ನ ಯೋಜನೆಯ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರಂತರವಾಗಿ ಸುಧಾರಿಸಬೇಕು ಎಂದು ಹೇಳುತ್ತಾರೆ. ಕಂಪನಿಯು ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಗಳ ಪಾರದರ್ಶಕತೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಗೆ ಹೂಡಿಕೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಈ ಪ್ರಕ್ರಿಯೆಗಳು ಯೋಜನೆಯ ಪ್ರಮಾಣಕ್ಕೆ ಅನುಗುಣವಾಗಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಇದನ್ನು ಮಾಡುತ್ತವೆ. ಇಲ್ಲಿ ನಾವು ಸ್ಲಾಕ್ನಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಕೆಲಸದ ಹರಿವಿನ ಬಗ್ಗೆ ಮತ್ತು ಕಂಪನಿಯು ಇಂದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರಾಜೆಕ್ಟ್ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಲು ಕಾರಣವಾದ ಕೆಲವು ನಿರ್ಧಾರಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ.
ಯೋಜನೆಯ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಗಳು ಇಂದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ
Slack ನಲ್ಲಿನ ಪ್ರತಿಯೊಂದು PR (ಪುಲ್ ವಿನಂತಿ) ಕೋಡ್ ಪರಿಶೀಲನೆಗೆ ಒಳಪಟ್ಟಿರಬೇಕು ಮತ್ತು ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿ ಉತ್ತೀರ್ಣರಾಗಿರಬೇಕು. ಈ ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸಿದ ನಂತರ ಮಾತ್ರ ಪ್ರೋಗ್ರಾಮರ್ ತನ್ನ ಕೋಡ್ ಅನ್ನು ಯೋಜನೆಯ ಮಾಸ್ಟರ್ ಶಾಖೆಗೆ ವಿಲೀನಗೊಳಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಈ ಕೋಡ್ ಅನ್ನು ವ್ಯಾಪಾರದ ಸಮಯದಲ್ಲಿ, ಉತ್ತರ ಅಮೆರಿಕಾದ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ನಮ್ಮ ಉದ್ಯೋಗಿಗಳು ತಮ್ಮ ಕೆಲಸದ ಸ್ಥಳಗಳಲ್ಲಿರುವುದರಿಂದ, ಯಾವುದೇ ಅನಿರೀಕ್ಷಿತ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ನಾವು ಸಂಪೂರ್ಣವಾಗಿ ಸಿದ್ಧರಾಗಿದ್ದೇವೆ.
ಪ್ರತಿದಿನ ನಾವು ಸುಮಾರು 12 ಯೋಜಿತ ನಿಯೋಜನೆಗಳನ್ನು ಕೈಗೊಳ್ಳುತ್ತೇವೆ. ಪ್ರತಿ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ, ನಿಯೋಜನೆ ಲೀಡ್ ಎಂದು ಗೊತ್ತುಪಡಿಸಿದ ಪ್ರೋಗ್ರಾಮರ್ ಹೊಸ ನಿರ್ಮಾಣವನ್ನು ಉತ್ಪಾದನೆಗೆ ತರಲು ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ. ಇದು ಬಹು-ಹಂತದ ಪ್ರಕ್ರಿಯೆಯಾಗಿದ್ದು ಅದು ಜೋಡಣೆಯನ್ನು ಸರಾಗವಾಗಿ ಉತ್ಪಾದನೆಗೆ ತರುತ್ತದೆ. ಈ ವಿಧಾನಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ನಮ್ಮ ಎಲ್ಲಾ ಬಳಕೆದಾರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಮೊದಲು ನಾವು ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು. ಹಲವಾರು ದೋಷಗಳು ಇದ್ದಲ್ಲಿ, ಜೋಡಣೆಯ ನಿಯೋಜನೆಯನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು. ಬಿಡುಗಡೆಯ ನಂತರ ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಯನ್ನು ಪತ್ತೆಮಾಡಿದರೆ, ಅದಕ್ಕೆ ಪರಿಹಾರವನ್ನು ಸುಲಭವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಬಹುದು.
ಚೆಕ್ಪಾಯಿಂಟ್ ಸಿಸ್ಟಮ್ನ ಇಂಟರ್ಫೇಸ್, ಯೋಜನೆಗಳನ್ನು ನಿಯೋಜಿಸಲು ಸ್ಲಾಕ್ನಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ
ಉತ್ಪಾದನೆಗೆ ಹೊಸ ಬಿಡುಗಡೆಯನ್ನು ನಿಯೋಜಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ನಾಲ್ಕು ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಎಂದು ಭಾವಿಸಬಹುದು.
▍1. ಬಿಡುಗಡೆ ಶಾಖೆಯನ್ನು ರಚಿಸುವುದು
ಪ್ರತಿ ಬಿಡುಗಡೆಯು ಹೊಸ ಬಿಡುಗಡೆ ಶಾಖೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇದು ನಮ್ಮ Git ಇತಿಹಾಸದಲ್ಲಿ ಒಂದು ಅಂಶವಾಗಿದೆ. ಬಿಡುಗಡೆಗೆ ಟ್ಯಾಗ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಉತ್ಪಾದನೆಗೆ ಬಿಡುಗಡೆಗಾಗಿ ಬಿಡುಗಡೆಯನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕಂಡುಬರುವ ದೋಷಗಳಿಗಾಗಿ ನೀವು ಲೈವ್ ಫಿಕ್ಸ್‌ಗಳನ್ನು ಮಾಡುವ ಸ್ಥಳವನ್ನು ಒದಗಿಸುತ್ತದೆ.
▍2. ವೇದಿಕೆಯ ಪರಿಸರದಲ್ಲಿ ನಿಯೋಜನೆ
ಮುಂದಿನ ಹಂತವು ಸ್ಟೇಜಿಂಗ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಅಸೆಂಬ್ಲಿಯನ್ನು ನಿಯೋಜಿಸುವುದು ಮತ್ತು ಯೋಜನೆಯ ಒಟ್ಟಾರೆ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುವುದು (ಹೊಗೆ ಪರೀಕ್ಷೆ). ವೇದಿಕೆಯ ಪರಿಸರವು ಬಾಹ್ಯ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸದ ಉತ್ಪಾದನಾ ಪರಿಸರವಾಗಿದೆ. ಈ ಪರಿಸರದಲ್ಲಿ, ನಾವು ಹೆಚ್ಚುವರಿ ಹಸ್ತಚಾಲಿತ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುತ್ತೇವೆ. ಮಾರ್ಪಡಿಸಿದ ಯೋಜನೆಯು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಇದು ನಮಗೆ ಹೆಚ್ಚುವರಿ ವಿಶ್ವಾಸವನ್ನು ನೀಡುತ್ತದೆ. ಈ ಮಟ್ಟದ ಆತ್ಮವಿಶ್ವಾಸವನ್ನು ಒದಗಿಸಲು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಮಾತ್ರ ಸಾಕಾಗುವುದಿಲ್ಲ.
▍3. ಡಾಗ್‌ಫುಡ್ ಮತ್ತು ಕ್ಯಾನರಿ ಪರಿಸರದಲ್ಲಿ ನಿಯೋಜನೆ
ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜನೆಯು ಡಾಗ್‌ಫುಡ್ ಪರಿಸರದೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ನಮ್ಮ ಆಂತರಿಕ ಸ್ಲಾಕ್ ಕಾರ್ಯಸ್ಥಳಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ಹೋಸ್ಟ್‌ಗಳ ಗುಂಪಿನಿಂದ ಪ್ರತಿನಿಧಿಸಲಾಗುತ್ತದೆ. ನಾವು ತುಂಬಾ ಸಕ್ರಿಯ ಸ್ಲಾಕ್ ಬಳಕೆದಾರರಾಗಿರುವುದರಿಂದ, ಈ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದರಿಂದ ನಿಯೋಜನೆಯ ಆರಂಭದಲ್ಲಿ ಸಾಕಷ್ಟು ದೋಷಗಳನ್ನು ಹಿಡಿಯಲು ನಮಗೆ ಸಹಾಯ ಮಾಡಿದೆ. ಸಿಸ್ಟಮ್ನ ಮೂಲಭೂತ ಕಾರ್ಯಚಟುವಟಿಕೆಯು ಮುರಿದುಹೋಗಿಲ್ಲ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಂಡ ನಂತರ, ಕ್ಯಾನರಿ ಪರಿಸರದಲ್ಲಿ ಜೋಡಣೆಯನ್ನು ನಿಯೋಜಿಸಲಾಗಿದೆ. ಇದು ಉತ್ಪಾದನಾ ದಟ್ಟಣೆಯ ಸರಿಸುಮಾರು 2% ರಷ್ಟಿರುವ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.
▍4. ಉತ್ಪಾದನೆಗೆ ಕ್ರಮೇಣ ಬಿಡುಗಡೆ
ಹೊಸ ಬಿಡುಗಡೆಯ ಮಾನಿಟರಿಂಗ್ ಸೂಚಕಗಳು ಸ್ಥಿರವಾಗಿದ್ದರೆ ಮತ್ತು ಕ್ಯಾನರಿ ಪರಿಸರದಲ್ಲಿ ಯೋಜನೆಯನ್ನು ನಿಯೋಜಿಸಿದ ನಂತರ ನಾವು ಯಾವುದೇ ದೂರುಗಳನ್ನು ಸ್ವೀಕರಿಸದಿದ್ದರೆ, ನಾವು ಉತ್ಪಾದನಾ ಸರ್ವರ್‌ಗಳನ್ನು ಕ್ರಮೇಣ ಹೊಸ ಬಿಡುಗಡೆಗೆ ವರ್ಗಾಯಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಈ ಕೆಳಗಿನ ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ: 10%, 25%, 50%, 75% ಮತ್ತು 100%. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಸಿಸ್ಟಮ್ನ ಹೊಸ ಬಿಡುಗಡೆಗೆ ಉತ್ಪಾದನಾ ದಟ್ಟಣೆಯನ್ನು ನಿಧಾನವಾಗಿ ವರ್ಗಾಯಿಸಬಹುದು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಯಾವುದೇ ವೈಪರೀತ್ಯಗಳು ಪತ್ತೆಯಾದರೆ ಪರಿಸ್ಥಿತಿಯನ್ನು ತನಿಖೆ ಮಾಡಲು ನಮಗೆ ಸಮಯವಿದೆ.
▍ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಏನಾದರೂ ತಪ್ಪಾದಲ್ಲಿ ಏನು?
ಕೋಡ್‌ಗೆ ಮಾರ್ಪಾಡುಗಳನ್ನು ಮಾಡುವುದು ಯಾವಾಗಲೂ ಅಪಾಯವಾಗಿದೆ. ಆದರೆ ಉತ್ಪಾದನೆಗೆ ಹೊಸ ಬಿಡುಗಡೆಯನ್ನು ತರುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸುವ, ಮೇಲ್ವಿಚಾರಣೆ ಸೂಚಕಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಮತ್ತು ಕೋಡ್ ಬಿಡುಗಡೆ ಮಾಡುವ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳ ಕೆಲಸವನ್ನು ಸಂಘಟಿಸುವ ಸುಶಿಕ್ಷಿತ "ನಿಯೋಜನೆ ನಾಯಕರ" ಉಪಸ್ಥಿತಿಗೆ ನಾವು ಇದನ್ನು ನಿಭಾಯಿಸುತ್ತೇವೆ.
ನಿಜವಾಗಿಯೂ ಏನಾದರೂ ತಪ್ಪಾದ ಸಂದರ್ಭದಲ್ಲಿ, ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಸಮಸ್ಯೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ನಾವು ಸಮಸ್ಯೆಯನ್ನು ತನಿಖೆ ಮಾಡುತ್ತೇವೆ, ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡುವ PR ಅನ್ನು ಕಂಡುಹಿಡಿಯುತ್ತೇವೆ, ಅದನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತೇವೆ, ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ ಮತ್ತು ಹೊಸ ನಿರ್ಮಾಣವನ್ನು ರಚಿಸುತ್ತೇವೆ. ನಿಜ, ಕೆಲವೊಮ್ಮೆ ಯೋಜನೆಯು ಉತ್ಪಾದನೆಗೆ ಹೋಗುವವರೆಗೂ ಸಮಸ್ಯೆಯು ಗಮನಿಸುವುದಿಲ್ಲ. ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಸೇವೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸುವುದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವಾಗಿದೆ. ಆದ್ದರಿಂದ, ನಾವು ಸಮಸ್ಯೆಯನ್ನು ತನಿಖೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನಾವು ತಕ್ಷಣ ಹಿಂದಿನ ಕೆಲಸದ ನಿರ್ಮಾಣಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತೇವೆ.
ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್ಸ್
ನಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಗೆ ಆಧಾರವಾಗಿರುವ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ನೋಡೋಣ.
▍ತ್ವರಿತ ನಿಯೋಜನೆಗಳು
ಮೇಲೆ ವಿವರಿಸಿದ ಕೆಲಸದ ಹರಿವು ಹಿನ್ನೋಟದಲ್ಲಿ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣಿಸಬಹುದು. ಆದರೆ ನಮ್ಮ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯು ಈಗಿನಿಂದಲೇ ಆಗಲಿಲ್ಲ.
ಕಂಪನಿಯು ಚಿಕ್ಕದಾಗಿದ್ದಾಗ, ನಮ್ಮ ಸಂಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್ 10 Amazon EC2 ನಿದರ್ಶನಗಳಲ್ಲಿ ರನ್ ಆಗಬಹುದು. ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದು ಎಂದರೆ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು rsync ಅನ್ನು ಬಳಸುತ್ತದೆ. ಹಿಂದೆ, ಹೊಸ ಕೋಡ್ ಉತ್ಪಾದನೆಯಿಂದ ಕೇವಲ ಒಂದು ಹೆಜ್ಜೆ ದೂರದಲ್ಲಿದೆ, ಇದನ್ನು ವೇದಿಕೆಯ ಪರಿಸರದಿಂದ ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಅಂತಹ ವಾತಾವರಣದಲ್ಲಿ ಅಸೆಂಬ್ಲಿಗಳನ್ನು ರಚಿಸಲಾಯಿತು ಮತ್ತು ಪರೀಕ್ಷಿಸಲಾಯಿತು, ಮತ್ತು ನಂತರ ನೇರವಾಗಿ ಉತ್ಪಾದನೆಗೆ ಹೋಯಿತು. ಅಂತಹ ವ್ಯವಸ್ಥೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ತುಂಬಾ ಸುಲಭ; ಯಾವುದೇ ಪ್ರೋಗ್ರಾಮರ್ ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಅವರು ಬರೆದ ಕೋಡ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಇದು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.
ಆದರೆ ನಮ್ಮ ಗ್ರಾಹಕರ ಸಂಖ್ಯೆಯು ಬೆಳೆದಂತೆ, ಯೋಜನೆಯನ್ನು ಬೆಂಬಲಿಸಲು ಅಗತ್ಯವಾದ ಮೂಲಸೌಕರ್ಯಗಳ ಪ್ರಮಾಣವೂ ಹೆಚ್ಚಾಯಿತು. ಶೀಘ್ರದಲ್ಲೇ, ಸಿಸ್ಟಮ್ನ ನಿರಂತರ ಬೆಳವಣಿಗೆಯನ್ನು ನೀಡಿದರೆ, ಹೊಸ ಕೋಡ್ ಅನ್ನು ಸರ್ವರ್‌ಗಳಿಗೆ ತಳ್ಳುವ ಆಧಾರದ ಮೇಲೆ ನಮ್ಮ ನಿಯೋಜನೆ ಮಾದರಿಯು ಇನ್ನು ಮುಂದೆ ತನ್ನ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿಲ್ಲ. ಅವುಗಳೆಂದರೆ, ಪ್ರತಿ ಹೊಸ ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸುವುದು ಎಂದರೆ ನಿಯೋಜನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಬೇಕಾದ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುವುದು. rsync ನ ಸಮಾನಾಂತರ ಬಳಕೆಯ ಆಧಾರದ ಮೇಲೆ ತಂತ್ರಗಳು ಸಹ ಕೆಲವು ಮಿತಿಗಳನ್ನು ಹೊಂದಿವೆ.
ನಾವು ಸಂಪೂರ್ಣವಾಗಿ ಸಮಾನಾಂತರ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಗೆ ಚಲಿಸುವ ಮೂಲಕ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದನ್ನು ಕೊನೆಗೊಳಿಸಿದ್ದೇವೆ, ಇದನ್ನು ಹಳೆಯ ವ್ಯವಸ್ಥೆಯಿಂದ ವಿಭಿನ್ನವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಅವುಗಳೆಂದರೆ, ಈಗ ನಾವು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸರ್ವರ್‌ಗಳಿಗೆ ಕೋಡ್ ಅನ್ನು ಕಳುಹಿಸಲಿಲ್ಲ. ಈಗ ಪ್ರತಿ ಸರ್ವರ್ ಸ್ವತಂತ್ರವಾಗಿ ಹೊಸ ಅಸೆಂಬ್ಲಿಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದೆ, ಕಾನ್ಸುಲ್ ಕೀ ಬದಲಾವಣೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಮೂಲಕ ಅದನ್ನು ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ತಿಳಿದಿದೆ. ಸರ್ವರ್‌ಗಳು ಕೋಡ್ ಅನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಲೋಡ್ ಮಾಡುತ್ತವೆ. ಸ್ಥಿರವಾದ ಸಿಸ್ಟಮ್ ಬೆಳವಣಿಗೆಯ ವಾತಾವರಣದಲ್ಲಿಯೂ ಹೆಚ್ಚಿನ ವೇಗದ ನಿಯೋಜನೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಇದು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.
1. ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್‌ಗಳು ಕಾನ್ಸಲ್ ಕೀಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತವೆ. 2. ಪ್ರಮುಖ ಬದಲಾವಣೆಗಳು, ಹೊಸ ಕೋಡ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುವ ಅಗತ್ಯವಿರುವ ಸರ್ವರ್‌ಗಳಿಗೆ ಇದು ಹೇಳುತ್ತದೆ. 3. ಸರ್ವರ್‌ಗಳು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನೊಂದಿಗೆ ಟಾರ್‌ಬಾಲ್ ಫೈಲ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತವೆ
▍ ಪರಮಾಣು ನಿಯೋಜನೆಗಳು
ಬಹು-ಹಂತದ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯನ್ನು ತಲುಪಲು ನಮಗೆ ಸಹಾಯ ಮಾಡಿದ ಮತ್ತೊಂದು ಪರಿಹಾರವೆಂದರೆ ಪರಮಾಣು ನಿಯೋಜನೆ.
ಪರಮಾಣು ನಿಯೋಜನೆಗಳನ್ನು ಬಳಸುವ ಮೊದಲು, ಪ್ರತಿ ನಿಯೋಜನೆಯು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ದೋಷ ಸಂದೇಶಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಉತ್ಪಾದನಾ ಸರ್ವರ್‌ಗಳಿಗೆ ಹೊಸ ಫೈಲ್‌ಗಳನ್ನು ನಕಲಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಪರಮಾಣು ಅಲ್ಲ ಎಂಬುದು ಸತ್ಯ. ಇದು ಫಂಕ್ಷನ್‌ಗಳು ಲಭ್ಯವಾಗುವ ಮೊದಲು ಹೊಸ ಫಂಕ್ಷನ್‌ಗಳನ್ನು ಕರೆಯುವ ಕೋಡ್ ಲಭ್ಯವಿರುವ ಅಲ್ಪಾವಧಿಯ ವಿಂಡೋಗೆ ಕಾರಣವಾಯಿತು. ಅಂತಹ ಕೋಡ್ ಅನ್ನು ಕರೆದಾಗ, ಅದು ಆಂತರಿಕ ದೋಷಗಳನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಇದು ವಿಫಲವಾದ API ವಿನಂತಿಗಳು ಮತ್ತು ಮುರಿದ ವೆಬ್ ಪುಟಗಳಲ್ಲಿ ಸ್ವತಃ ಸ್ಪಷ್ಟವಾಗಿ ಗೋಚರಿಸುತ್ತದೆ.
ಈ ಸಮಸ್ಯೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡಿದ ತಂಡವು "ಬಿಸಿ" ಮತ್ತು "ಶೀತ" ಡೈರೆಕ್ಟರಿಗಳ ಪರಿಕಲ್ಪನೆಯನ್ನು ಪರಿಚಯಿಸುವ ಮೂಲಕ ಅದನ್ನು ಪರಿಹರಿಸಿದೆ. ಬಿಸಿ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿರುವ ಕೋಡ್ ಉತ್ಪಾದನಾ ದಟ್ಟಣೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಕಾರಣವಾಗಿದೆ. ಮತ್ತು "ಶೀತ" ಡೈರೆಕ್ಟರಿಗಳಲ್ಲಿ, ಕೋಡ್, ಸಿಸ್ಟಮ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ, ಬಳಕೆಗೆ ಮಾತ್ರ ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತಿದೆ. ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ, ಹೊಸ ಕೋಡ್ ಅನ್ನು ಬಳಕೆಯಾಗದ ಕೋಲ್ಡ್ ಡೈರೆಕ್ಟರಿಗೆ ನಕಲಿಸಲಾಗುತ್ತದೆ. ನಂತರ, ಸರ್ವರ್‌ನಲ್ಲಿ ಯಾವುದೇ ಸಕ್ರಿಯ ಪ್ರಕ್ರಿಯೆಗಳಿಲ್ಲದಿದ್ದಾಗ, ತ್ವರಿತ ಡೈರೆಕ್ಟರಿ ಸ್ವಿಚ್ ಅನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ.
1. ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು "ಕೋಲ್ಡ್" ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಅನ್ಪ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತಿದೆ. 2. ಸಿಸ್ಟಮ್ ಅನ್ನು "ಕೋಲ್ಡ್" ಡೈರೆಕ್ಟರಿಗೆ ಬದಲಾಯಿಸುವುದು, ಅದು "ಬಿಸಿ" ಆಗುತ್ತದೆ (ಪರಮಾಣು ಕಾರ್ಯಾಚರಣೆ)
ಫಲಿತಾಂಶಗಳು: ವಿಶ್ವಾಸಾರ್ಹತೆಗೆ ಒತ್ತು ನೀಡುವುದು
2018 ರಲ್ಲಿ, ಯೋಜನೆಯು ಅಂತಹ ಪ್ರಮಾಣಕ್ಕೆ ಬೆಳೆಯಿತು, ಅತ್ಯಂತ ತ್ವರಿತವಾದ ನಿಯೋಜನೆಯು ಉತ್ಪನ್ನದ ಸ್ಥಿರತೆಗೆ ಹಾನಿ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು. ನಾವು ಬಹಳ ಸುಧಾರಿತ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದರಲ್ಲಿ ನಾವು ಸಾಕಷ್ಟು ಸಮಯ ಮತ್ತು ಶ್ರಮವನ್ನು ಹೂಡಿಕೆ ಮಾಡಿದ್ದೇವೆ. ನಾವು ಮಾಡಬೇಕಾಗಿರುವುದು ನಮ್ಮ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡುವುದು ಮತ್ತು ಸುಧಾರಿಸುವುದು. ನಾವು ಸಾಕಷ್ಟು ದೊಡ್ಡ ಕಂಪನಿಯಾಗಿ ಬೆಳೆದಿದ್ದೇವೆ, ಅವರ ಬೆಳವಣಿಗೆಗಳನ್ನು ತಡೆರಹಿತ ಸಂವಹನಗಳನ್ನು ಸಂಘಟಿಸಲು ಮತ್ತು ಪ್ರಮುಖ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಪಂಚದಾದ್ಯಂತ ಬಳಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ವಿಶ್ವಾಸಾರ್ಹತೆಯು ನಮ್ಮ ಗಮನದ ಕೇಂದ್ರಬಿಂದುವಾಯಿತು.
ಹೊಸ ಸ್ಲಾಕ್ ಬಿಡುಗಡೆಗಳನ್ನು ನಿಯೋಜಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಾವು ಹೆಚ್ಚು ಸುರಕ್ಷಿತಗೊಳಿಸಬೇಕಾಗಿದೆ. ಈ ಅಗತ್ಯವು ನಮ್ಮ ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಸುಧಾರಿಸಲು ಕಾರಣವಾಯಿತು. ವಾಸ್ತವವಾಗಿ, ನಾವು ಈ ಸುಧಾರಿತ ವ್ಯವಸ್ಥೆಯನ್ನು ಮೇಲೆ ಚರ್ಚಿಸಿದ್ದೇವೆ. ವ್ಯವಸ್ಥೆಯ ಆಳದಲ್ಲಿ, ನಾವು ವೇಗದ ಮತ್ತು ಪರಮಾಣು ನಿಯೋಜನೆ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. ನಿಯೋಜನೆ ಮಾಡುವ ವಿಧಾನ ಬದಲಾಗಿದೆ. ನಮ್ಮ ಹೊಸ ವ್ಯವಸ್ಥೆಯನ್ನು ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ, ವಿಭಿನ್ನ ಪರಿಸರದಲ್ಲಿ ಕ್ರಮೇಣವಾಗಿ ಹೊಸ ಕೋಡ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ನಾವು ಈಗ ಮೊದಲಿಗಿಂತ ಹೆಚ್ಚು ಸುಧಾರಿತ ಬೆಂಬಲ ಪರಿಕರಗಳು ಮತ್ತು ಸಿಸ್ಟಮ್ ಮಾನಿಟರಿಂಗ್ ಪರಿಕರಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು ಅಂತಿಮ ಬಳಕೆದಾರರನ್ನು ತಲುಪುವ ಅವಕಾಶವನ್ನು ಹೊಂದುವ ಮೊದಲು ದೋಷಗಳನ್ನು ಹಿಡಿಯುವ ಮತ್ತು ಸರಿಪಡಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನಮಗೆ ನೀಡುತ್ತದೆ.
ಆದರೆ ನಾವು ಅಲ್ಲಿ ನಿಲ್ಲಲು ಹೋಗುವುದಿಲ್ಲ. ನಾವು ನಿರಂತರವಾಗಿ ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಸುಧಾರಿಸುತ್ತಿದ್ದೇವೆ, ಹೆಚ್ಚು ಸುಧಾರಿತ ಸಹಾಯಕ ಸಾಧನಗಳು ಮತ್ತು ಕೆಲಸದ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸಾಧನಗಳನ್ನು ಬಳಸುತ್ತೇವೆ.
ಆತ್ಮೀಯ ಓದುಗರು! ನೀವು ಕೆಲಸ ಮಾಡುವ ಸ್ಥಳದಲ್ಲಿ ಹೊಸ ಪ್ರಾಜೆಕ್ಟ್ ಬಿಡುಗಡೆಗಳನ್ನು ನಿಯೋಜಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ?
ಮೂಲ: www.habr.com