GitLab ನಲ್ಲಿ ನಾವು ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಹೇಗೆ ಬಿಡುಗಡೆ ಮಾಡುತ್ತೇವೆ

GitLab ನಲ್ಲಿ ನಾವು ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಹೇಗೆ ಬಿಡುಗಡೆ ಮಾಡುತ್ತೇವೆ

GitLab ನಲ್ಲಿ, ನಾವು ಸಾಫ್ಟ್‌ವೇರ್ ಪರಿಹಾರಗಳನ್ನು ಎರಡು ರೀತಿಯಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತೇವೆ: ಹಸ್ತಚಾಲಿತವಾಗಿ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ. gitlab.com ಗೆ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆಯ ಮೂಲಕ ಪ್ರಮುಖ ನವೀಕರಣಗಳನ್ನು ರಚಿಸುವ ಮತ್ತು ತಲುಪಿಸುವ ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರ ಕೆಲಸದ ಬಗ್ಗೆ ತಿಳಿಯಲು ಮುಂದೆ ಓದಿರಿ, ಹಾಗೆಯೇ ಬಳಕೆದಾರರು ತಮ್ಮ ಸ್ವಂತ ಸ್ಥಾಪನೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಪ್ಯಾಚ್‌ಗಳು.

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

ಆದರೆ, ಅಭ್ಯಾಸ ಪ್ರದರ್ಶನಗಳಂತೆ, ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯು ನ್ಯೂನತೆಗಳಿಲ್ಲದೆ ಅಪರೂಪ. ದೋಷ ಅಥವಾ ಭದ್ರತಾ ದುರ್ಬಲತೆ ಪತ್ತೆಯಾದಾಗ, ವಿತರಣಾ ತಂಡದಲ್ಲಿನ ಬಿಡುಗಡೆ ನಿರ್ವಾಹಕರು ನಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಅವರ ಸ್ಥಾಪನೆಗಳೊಂದಿಗೆ ಪರಿಹಾರವನ್ನು ರಚಿಸುತ್ತಾರೆ. CD ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ Gitlab.com ಅನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ. GitLab ನಲ್ಲಿನ CD ವೈಶಿಷ್ಟ್ಯದೊಂದಿಗೆ ಗೊಂದಲವನ್ನು ತಪ್ಪಿಸಲು ನಾವು ಈ CD ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆ ಎಂದು ಕರೆಯುತ್ತೇವೆ. ಈ ಪ್ರಕ್ರಿಯೆಯು ಬಳಕೆದಾರರು, ಗ್ರಾಹಕರು ಮತ್ತು ನಮ್ಮ ಆಂತರಿಕ ಅಭಿವೃದ್ಧಿ ತಂಡದಿಂದ ಸಲ್ಲಿಸಿದ ಪುಲ್ ವಿನಂತಿಗಳಿಂದ ಸಲಹೆಗಳನ್ನು ಸಂಯೋಜಿಸಬಹುದು, ಇದರಿಂದಾಗಿ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ನೀರಸ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದು ಎರಡು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ.

«ಡೆವಲಪರ್‌ಗಳು ಮಾಡುವ ಎಲ್ಲವನ್ನೂ GitLab.com ಗೆ ಹೊರತರುವ ಮೊದಲು ಪ್ರತಿದಿನ ಎಲ್ಲಾ ಪರಿಸರಕ್ಕೆ ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸುತ್ತೇವೆ", ವಿವರಿಸುತ್ತದೆ ಮರಿನ್ ಜಾಂಕೋವ್ಕಿ, ಹಿರಿಯ ತಾಂತ್ರಿಕ ವ್ಯವಸ್ಥಾಪಕರು, ಮೂಲಸೌಕರ್ಯ ಇಲಾಖೆ. "ನಿಮ್ಮ ಸ್ಥಾಪನೆಗಳಿಗಾಗಿ ಬಿಡುಗಡೆಗಳನ್ನು gitlab.com ನಿಯೋಜನೆಗಳಿಗಾಗಿ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳೆಂದು ಯೋಚಿಸಿ, ಇದಕ್ಕಾಗಿ ನಾವು ಪ್ಯಾಕೇಜ್ ರಚಿಸಲು ಪ್ರತ್ಯೇಕ ಹಂತಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ ಇದರಿಂದ ನಮ್ಮ ಬಳಕೆದಾರರು ತಮ್ಮ ಸ್ಥಾಪನೆಗಳಲ್ಲಿ ಸ್ಥಾಪಿಸಲು ಅದನ್ನು ಬಳಸಬಹುದು».

ದೋಷ ಅಥವಾ ದುರ್ಬಲತೆಯ ಹೊರತಾಗಿಯೂ, gitlab.com ಗ್ರಾಹಕರು ಅವರು ಪ್ರಕಟಿಸಿದ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಪರಿಹಾರಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ, ಇದು ಸ್ವಯಂಚಾಲಿತ CD ಪ್ರಕ್ರಿಯೆಯ ಪ್ರಯೋಜನವಾಗಿದೆ. ತಮ್ಮದೇ ಆದ ಅನುಸ್ಥಾಪನೆಗಳೊಂದಿಗೆ ಬಳಕೆದಾರರಿಗೆ ಪ್ಯಾಚ್‌ಗಳಿಗೆ ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರಿಂದ ಪ್ರತ್ಯೇಕ ಸಿದ್ಧತೆ ಅಗತ್ಯವಿರುತ್ತದೆ.

ವಿತರಣಾ ತಂಡವು ಕಡಿಮೆ ಮಾಡಲು ಬಿಡುಗಡೆಗಳನ್ನು ರಚಿಸುವಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ಹೆಚ್ಚಿನ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಶ್ರಮಿಸುತ್ತಿದೆ MTTP (ಉತ್ಪಾದನೆಯ ಸರಾಸರಿ ಸಮಯ, ಅಂದರೆ ಉತ್ಪಾದನೆಗೆ ಖರ್ಚು ಮಾಡಿದ ಸಮಯ), ಡೆವಲಪರ್‌ನಿಂದ ವಿಲೀನ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದರಿಂದ ಹಿಡಿದು gitlab.com ನಲ್ಲಿ ನಿಯೋಜನೆಯವರೆಗೆ.

«ವಿತರಣಾ ತಂಡದ ಗುರಿಯು ನಾವು ಕಂಪನಿಯಾಗಿ ವೇಗವಾಗಿ ಚಲಿಸಬಹುದು ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅಥವಾ ಕನಿಷ್ಠ ಡೆಲಿವರಿ ಜನರು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡುವುದು.?, ಮರಿನ್ ಹೇಳುತ್ತಾರೆ.

gitlab.com ಗ್ರಾಹಕರು ಮತ್ತು ಅವರ ಸ್ಥಾಪನೆಗಳ ಬಳಕೆದಾರರು ಸೈಕಲ್ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ನಿಯೋಜನೆಗಳನ್ನು ವೇಗಗೊಳಿಸಲು ಡೆಲಿವರಿ ತಂಡದ ಪ್ರಯತ್ನಗಳಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತಾರೆ. ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಈ ಎರಡು ವಿಧಾನಗಳ ನಡುವಿನ ಹೋಲಿಕೆಗಳು ಮತ್ತು ವ್ಯತ್ಯಾಸಗಳನ್ನು ವಿವರಿಸುತ್ತೇವೆ. ಸಮಸ್ಯೆಗಳು, ಮತ್ತು ನಮ್ಮ ವಿತರಣಾ ತಂಡವು ಅವರ ಸೌಲಭ್ಯಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಬಳಕೆದಾರರಿಗೆ ಹೇಗೆ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಸಹ ನಾವು ವಿವರಿಸುತ್ತೇವೆ, ಹಾಗೆಯೇ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆಯನ್ನು ಬಳಸಿಕೊಂಡು gitlab.com ನವೀಕೃತವಾಗಿದೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ.

ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರು ಏನು ಮಾಡುತ್ತಾರೆ?

ತಂಡದ ಸದಸ್ಯರು ಮಾಸಿಕ ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರ ಪಾತ್ರವನ್ನು ವರ್ಗಾಯಿಸಿ ಬಿಡುಗಡೆಗಳ ನಡುವೆ ಸಂಭವಿಸಬಹುದಾದ ಪ್ಯಾಚ್‌ಗಳು ಮತ್ತು ಭದ್ರತಾ ಬಿಡುಗಡೆಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಅವರ ಸೌಲಭ್ಯಗಳಲ್ಲಿ ಬಳಕೆದಾರರಿಗೆ ನಮ್ಮ ಬಿಡುಗಡೆಗಳು. ಸ್ವಯಂಚಾಲಿತ, ನಿರಂತರ ನಿಯೋಜನೆಗೆ ಕಂಪನಿಯ ಪರಿವರ್ತನೆಯನ್ನು ಮುನ್ನಡೆಸಲು ಅವರು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ.

ಸ್ವಯಂ-ಸ್ಥಾಪನೆ ಬಿಡುಗಡೆಗಳು ಮತ್ತು gitlab.com ಬಿಡುಗಡೆಗಳು ಒಂದೇ ರೀತಿಯ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ಬಳಸುತ್ತವೆ ಆದರೆ ವಿಭಿನ್ನ ಸಮಯಗಳಲ್ಲಿ ರನ್ ಆಗುತ್ತವೆ, ಮರಿನ್ ವಿವರಿಸುತ್ತಾರೆ.

ಮೊದಲ ಮತ್ತು ಅಗ್ರಗಣ್ಯವಾಗಿ, ಬಿಡುಗಡೆಯ ಮ್ಯಾನೇಜರ್, ಬಿಡುಗಡೆಯ ಪ್ರಕಾರವನ್ನು ಲೆಕ್ಕಿಸದೆ, gitlab.com ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಕ್ಷಣದಿಂದ GitLab ಲಭ್ಯವಿದೆ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಅದೇ ಸಮಸ್ಯೆಗಳು ಗ್ರಾಹಕರ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಸೇರಿದಂತೆ. ಸ್ವಂತ ಸಾಮರ್ಥ್ಯಗಳು.

GitLab ನಲ್ಲಿ ದೋಷ ಅಥವಾ ದುರ್ಬಲತೆಯನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ ಎಂದು ಗುರುತಿಸಿದ ನಂತರ, ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರು ಅದನ್ನು ಪ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಅಥವಾ ಅವರ ಸ್ಥಾಪನೆಗಳೊಂದಿಗೆ ಬಳಕೆದಾರರಿಗೆ ಭದ್ರತಾ ನವೀಕರಣಗಳಲ್ಲಿ ಸೇರಿಸಲಾಗುವುದು ಎಂದು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು. ದೋಷ ಅಥವಾ ದುರ್ಬಲತೆಯು ನವೀಕರಣಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ ಎಂದು ಅವರು ನಿರ್ಧರಿಸಿದರೆ, ಪೂರ್ವಸಿದ್ಧತಾ ಕೆಲಸ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರು ಪರಿಹಾರವನ್ನು ಸಿದ್ಧಪಡಿಸಬೇಕೆ ಅಥವಾ ಅದನ್ನು ಯಾವಾಗ ನಿಯೋಜಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬೇಕು - ಮತ್ತು ಇದು ಪರಿಸ್ಥಿತಿಯ ಸಂದರ್ಭದ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿದೆ, "ಈ ಮಧ್ಯೆ, ಯಂತ್ರಗಳು ಜನರಂತೆ ಸಂದರ್ಭವನ್ನು ನಿರ್ವಹಿಸುವಲ್ಲಿ ಉತ್ತಮವಾಗಿಲ್ಲ"ಮರಿನ್ ಹೇಳುತ್ತಾರೆ.

ಇದು ಪರಿಹಾರಗಳ ಬಗ್ಗೆ ಅಷ್ಟೆ

ಪ್ಯಾಚ್‌ಗಳು ಯಾವುವು ಮತ್ತು ನಮಗೆ ಅವು ಏಕೆ ಬೇಕು?

ದೋಷದ ತೀವ್ರತೆಯ ಆಧಾರದ ಮೇಲೆ ಪರಿಹಾರವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬೇಕೆ ಎಂದು ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರು ನಿರ್ಧರಿಸುತ್ತಾರೆ.

ದೋಷಗಳು ಅವುಗಳ ತೀವ್ರತೆಯನ್ನು ಅವಲಂಬಿಸಿ ಬದಲಾಗುತ್ತವೆ. ಆದ್ದರಿಂದ S4 ಅಥವಾ S3 ದೋಷಗಳು ಸ್ಟೈಲಿಸ್ಟಿಕ್ ಆಗಿರಬಹುದು, ಉದಾಹರಣೆಗೆ ಪಿಕ್ಸೆಲ್ ಅಥವಾ ಐಕಾನ್ ಸ್ಥಳಾಂತರ. ಇದು ಕಡಿಮೆ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೊಂದಿಲ್ಲ, ಆದರೆ ಯಾರೊಬ್ಬರ ಕೆಲಸದ ಹರಿವಿನ ಮೇಲೆ ಯಾವುದೇ ಮಹತ್ವದ ಪರಿಣಾಮವಿಲ್ಲ, ಅಂದರೆ ಅಂತಹ S3 ಅಥವಾ S4 ದೋಷಗಳಿಗೆ ಪರಿಹಾರವನ್ನು ರಚಿಸುವ ಸಾಧ್ಯತೆ ಚಿಕ್ಕದಾಗಿದೆ ಎಂದು ಮರಿನ್ ವಿವರಿಸುತ್ತಾರೆ.

ಆದಾಗ್ಯೂ, ದುರ್ಬಲತೆಗಳು S1 ಅಥವಾ S2 ಎಂದರೆ ಬಳಕೆದಾರರು ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗೆ ನವೀಕರಿಸಬಾರದು ಅಥವಾ ಬಳಕೆದಾರರ ಕೆಲಸದ ಹರಿವಿನ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಗಮನಾರ್ಹ ದೋಷವಿದೆ. ಅವುಗಳನ್ನು ಟ್ರ್ಯಾಕರ್‌ನಲ್ಲಿ ಸೇರಿಸಿದರೆ, ಅನೇಕ ಬಳಕೆದಾರರು ಅವರನ್ನು ಎದುರಿಸಿದ್ದಾರೆ, ಆದ್ದರಿಂದ ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರು ತಕ್ಷಣವೇ ಪರಿಹಾರವನ್ನು ಸಿದ್ಧಪಡಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.

ದುರ್ಬಲತೆಗಳ S1 ಅಥವಾ S2 ಪ್ಯಾಚ್ ಸಿದ್ಧವಾದ ನಂತರ, ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರು ಪ್ಯಾಚ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.

ಉದಾಹರಣೆಗೆ, GitLab 12.10.1 ಪ್ಯಾಚ್ ಅನ್ನು ಹಲವಾರು ನಿರ್ಬಂಧಿಸುವ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಿದ ನಂತರ ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಅಭಿವರ್ಧಕರು ಅವುಗಳನ್ನು ಉಂಟುಮಾಡುವ ಮೂಲ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ್ದಾರೆ. ಬಿಡುಗಡೆ ಮ್ಯಾನೇಜರ್ ನಿಯೋಜಿತ ತೀವ್ರತೆಯ ಮಟ್ಟಗಳ ನಿಖರತೆಯನ್ನು ನಿರ್ಣಯಿಸಿದರು, ಮತ್ತು ದೃಢೀಕರಣದ ನಂತರ, ಫಿಕ್ಸ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಯಿತು, ಇದು ನಿರ್ಬಂಧಿಸುವ ಸಮಸ್ಯೆಗಳನ್ನು ಕಂಡುಹಿಡಿದ ನಂತರ XNUMX ಗಂಟೆಗಳ ಒಳಗೆ ಸಿದ್ಧವಾಗಿದೆ.

S4, S3 ಮತ್ತು S2 ಬಹಳಷ್ಟು ಸಂಗ್ರಹವಾದಾಗ, ಬಿಡುಗಡೆ ನಿರ್ವಾಹಕರು ಫಿಕ್ಸ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ತುರ್ತುಸ್ಥಿತಿಯನ್ನು ನಿರ್ಧರಿಸಲು ಸಂದರ್ಭವನ್ನು ನೋಡುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯನ್ನು ತಲುಪಿದಾಗ, ಅವೆಲ್ಲವನ್ನೂ ಸಂಯೋಜಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಬಿಡುಗಡೆ ಮಾಡಲಾಗುತ್ತದೆ. ಬಿಡುಗಡೆಯ ನಂತರದ ಪರಿಹಾರಗಳು ಅಥವಾ ಭದ್ರತಾ ನವೀಕರಣಗಳನ್ನು ಬ್ಲಾಗ್ ಪೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಸಂಕ್ಷೇಪಿಸಲಾಗಿದೆ.

ಬಿಡುಗಡೆ ನಿರ್ವಾಹಕರು ಹೇಗೆ ಪ್ಯಾಚ್‌ಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ

ಪ್ಯಾಚ್‌ಗಳನ್ನು ರಚಿಸಲು ನಾವು GitLab CI ಮತ್ತು ನಮ್ಮ ChatOps ನಂತಹ ಇತರ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ನಮ್ಮ ಆಂತರಿಕ ಚಾನಲ್‌ನಲ್ಲಿ ChatOps ತಂಡವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಮೂಲಕ ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರು ಫಿಕ್ಸ್‌ನ ಬಿಡುಗಡೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ #releases ಸ್ಲಾಕ್‌ನಲ್ಲಿ.

/chatops run release prepare 12.10.1

ವಿಭಿನ್ನ ಈವೆಂಟ್‌ಗಳನ್ನು ಪ್ರಚೋದಿಸಲು ಚಾಟ್‌ಆಪ್‌ಗಳು ಸ್ಲಾಕ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ನಂತರ ಅದನ್ನು GitLab ನಿಂದ ಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ವಿತರಣಾ ತಂಡವು ಪ್ಯಾಚ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ವಿವಿಧ ವಿಷಯಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ChatOps ಅನ್ನು ಹೊಂದಿಸುತ್ತದೆ.

ಬಿಡುಗಡೆ ಮ್ಯಾನೇಜರ್ ಸ್ಲಾಕ್‌ನಲ್ಲಿ ಚಾಟ್‌ಆಪ್ಸ್ ತಂಡವನ್ನು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ, ಉಳಿದ ಕೆಲಸವು CICD ಬಳಸಿಕೊಂಡು GitLab ನಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಡೆಯುತ್ತದೆ. ಬಿಡುಗಡೆಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸ್ಲಾಕ್ ಮತ್ತು GitLab ನಲ್ಲಿ ಚಾಟ್‌ಆಪ್‌ಗಳ ನಡುವೆ ದ್ವಿಮುಖ ಸಂವಹನವಿದೆ, ಏಕೆಂದರೆ ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕವು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ ಕೆಲವು ಪ್ರಮುಖ ಹಂತಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ.

ಕೆಳಗಿನ ವೀಡಿಯೊ GitLab ಗಾಗಿ ಪ್ಯಾಚ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸುವ ತಾಂತ್ರಿಕ ಪ್ರಕ್ರಿಯೆಯನ್ನು ತೋರಿಸುತ್ತದೆ.

gitlab.com ನಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

gitlab.com ಅನ್ನು ನವೀಕರಿಸಲು ಬಳಸುವ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಪರಿಕರಗಳು ಪ್ಯಾಚ್‌ಗಳನ್ನು ರಚಿಸಲು ಬಳಸುವಂತೆಯೇ ಇರುತ್ತವೆ. gitlab.com ಅನ್ನು ನವೀಕರಿಸಲು ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರ ದೃಷ್ಟಿಕೋನದಿಂದ ಕಡಿಮೆ ಹಸ್ತಚಾಲಿತ ಕೆಲಸದ ಅಗತ್ಯವಿದೆ.

ಚಾಟ್‌ಆಪ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಿಯೋಜನೆಗಳನ್ನು ಚಾಲನೆ ಮಾಡುವ ಬದಲು, ನಾವು CI ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಳಸುತ್ತೇವೆ ಉದಾ. ನಿಗದಿತ ಪೈಪ್ಲೈನ್ಗಳು, ಇದರೊಂದಿಗೆ ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರು ಅಗತ್ಯವಿರುವ ಸಮಯದಲ್ಲಿ ನಿರ್ವಹಿಸಲು ಕೆಲವು ಕ್ರಿಯೆಗಳನ್ನು ನಿಗದಿಪಡಿಸಬಹುದು. ಹಸ್ತಚಾಲಿತ ಪ್ರಕ್ರಿಯೆಯ ಬದಲಿಗೆ, GitLab ಯೋಜನೆಗಳಿಗೆ ಮಾಡಿದ ಹೊಸ ಬದಲಾವಣೆಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವ, ಅವುಗಳನ್ನು ಪ್ಯಾಕೇಜ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಿಯೋಜನೆಯನ್ನು ನಿಗದಿಪಡಿಸುವ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪರೀಕ್ಷೆ, QA ಮತ್ತು ಇತರ ಅಗತ್ಯ ಹಂತಗಳನ್ನು ರನ್ ಮಾಡುವ ಪೈಪ್‌ಲೈನ್ ನಿಯತಕಾಲಿಕವಾಗಿ ಗಂಟೆಗೆ ಒಮ್ಮೆ ಚಲಿಸುತ್ತದೆ.

"ಆದ್ದರಿಂದ ನಾವು gitlab.com ಗಿಂತ ಮೊದಲು ವಿಭಿನ್ನ ಪರಿಸರದಲ್ಲಿ ಸಾಕಷ್ಟು ನಿಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಆ ಪರಿಸರವು ಉತ್ತಮ ಆಕಾರದಲ್ಲಿದೆ ಮತ್ತು ಪರೀಕ್ಷೆಯು ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ತೋರಿಸಿದ ನಂತರ, ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರು gitlab.com ನಿಯೋಜನೆ ಕ್ರಮಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ" ಎಂದು ಮರಿನ್ ಹೇಳುತ್ತಾರೆ.

Gitlab.com ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ CICD ತಂತ್ರಜ್ಞಾನವು ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರು ಉತ್ಪಾದನಾ ಪರಿಸರದ ನಿಯೋಜನೆಯನ್ನು gitlab.com ಗೆ ಹಸ್ತಚಾಲಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಬೇಕು.

ಕೆಳಗಿನ ವೀಡಿಯೊದಲ್ಲಿ gitlab.com ಅಪ್‌ಡೇಟ್ ಪ್ರಕ್ರಿಯೆಯ ಕುರಿತು ಮರಿನ್ ವಿವರವಾಗಿ ತಿಳಿಸುತ್ತಾರೆ.

ವಿತರಣಾ ತಂಡವು ಇನ್ನೇನು ಮಾಡುತ್ತದೆ?

gitlab.com ಅಪ್‌ಡೇಟ್ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಗ್ರಾಹಕರಿಗೆ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ನಡುವಿನ ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವೆಂದರೆ ನಂತರದ ಪ್ರಕ್ರಿಯೆಗೆ ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರಿಂದ ಹೆಚ್ಚಿನ ಸಮಯ ಮತ್ತು ಹೆಚ್ಚಿನ ಕೈಯಿಂದ ಕೆಲಸ ಬೇಕಾಗುತ್ತದೆ.

"ನಾವು ಕೆಲವೊಮ್ಮೆ ವರದಿ ಮಾಡಿದ ಸಮಸ್ಯೆಗಳು, ಟೂಲಿಂಗ್ ಸಮಸ್ಯೆಗಳಿಂದ ಗ್ರಾಹಕರಿಗೆ ಅವರ ಸ್ಥಾಪನೆಗಳೊಂದಿಗೆ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವುದನ್ನು ವಿಳಂಬಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ಒಂದೇ ಪ್ಯಾಚ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವಾಗ ಹಲವಾರು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ" ಎಂದು ಮರಿನ್ ಹೇಳುತ್ತಾರೆ.

ವಿತರಣಾ ತಂಡದ ಅಲ್ಪಾವಧಿಯ ಗುರಿಗಳಲ್ಲಿ ಒಂದು ಬಿಡುಗಡೆಯ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಲು ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರ ಕಡೆಯಿಂದ ಕೈಯಿಂದ ಮಾಡಿದ ಕೆಲಸದ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು. ಬಿಡುಗಡೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸರಳೀಕರಿಸಲು, ಸರಳೀಕರಿಸಲು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ತಂಡವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಇದು ಕಡಿಮೆ ತೀವ್ರತೆಯ ಸಮಸ್ಯೆಗಳಿಗೆ ಪರಿಹಾರಗಳನ್ನು ಪಡೆಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ (S3 ಮತ್ತು S4, ಅಂದಾಜು ಅನುವಾದಕ) ವೇಗದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವುದು ಪ್ರಮುಖ ಕಾರ್ಯಕ್ಷಮತೆ ಸೂಚಕವಾಗಿದೆ: MTTP ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಅವಶ್ಯಕ - ವಿಲೀನ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುವ ಸಮಯದಿಂದ gitlab.com ಗೆ ಫಲಿತಾಂಶವನ್ನು ನಿಯೋಜಿಸುವ ಸಮಯ - ಪ್ರಸ್ತುತ 50 ಗಂಟೆಗಳಿಂದ 8 ಗಂಟೆಗಳವರೆಗೆ.

ವಿತರಣಾ ತಂಡವು ಗಿಟ್ಲ್ಯಾಬ್.ಕಾಮ್ ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್-ಆಧಾರಿತ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಸ್ಥಳಾಂತರಿಸಲು ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ.

ಸಂಪಾದಕರಾದ ಎನ್.ಬಿ.: ನೀವು ಈಗಾಗಲೇ ಕುಬರ್ನೆಟ್ಸ್ ತಂತ್ರಜ್ಞಾನದ ಬಗ್ಗೆ ಕೇಳಿದ್ದರೆ (ಮತ್ತು ನೀವು ಹೊಂದಿರುವಿರಿ ಎಂಬುದರಲ್ಲಿ ನನಗೆ ಸಂದೇಹವಿಲ್ಲ), ಆದರೆ ಅದನ್ನು ನಿಮ್ಮ ಕೈಗಳಿಂದ ಇನ್ನೂ ಮುಟ್ಟದಿದ್ದರೆ, ಆನ್‌ಲೈನ್ ತೀವ್ರ ಕೋರ್ಸ್‌ಗಳಲ್ಲಿ ಭಾಗವಹಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ಕುಬರ್ನೆಟ್ಸ್ ಬೇಸ್, ಇದು ಸೆಪ್ಟೆಂಬರ್ 28-30 ನಡೆಯಲಿದೆ, ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಮೆಗಾ, ಇದು ಅಕ್ಟೋಬರ್ 14-16 ರಂದು ನಡೆಯುತ್ತದೆ. ತಂತ್ರಜ್ಞಾನದೊಂದಿಗೆ ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ನ್ಯಾವಿಗೇಟ್ ಮಾಡಲು ಮತ್ತು ಕೆಲಸ ಮಾಡಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ಇವುಗಳು ಒಂದೇ ಗುರಿಯನ್ನು ಅನುಸರಿಸುವ ಎರಡು ವಿಧಾನಗಳಾಗಿವೆ: gitlab.com ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಅವರ ಸೌಲಭ್ಯಗಳಲ್ಲಿ ನವೀಕರಣಗಳ ವೇಗದ ವಿತರಣೆ.

ನಮಗೆ ಯಾವುದೇ ಆಲೋಚನೆಗಳು ಅಥವಾ ಶಿಫಾರಸುಗಳು?

GitLab ಗೆ ಕೊಡುಗೆ ನೀಡಲು ಎಲ್ಲರಿಗೂ ಸ್ವಾಗತ, ಮತ್ತು ನಮ್ಮ ಓದುಗರಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಾವು ಸ್ವಾಗತಿಸುತ್ತೇವೆ. ನಮ್ಮ ವಿತರಣಾ ತಂಡಕ್ಕಾಗಿ ನೀವು ಯಾವುದೇ ಆಲೋಚನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಹಿಂಜರಿಯಬೇಡಿ ವಿನಂತಿಯನ್ನು ರಚಿಸಿ ಸೂಚನೆಯೊಂದಿಗೆ team: Delivery.

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ