DevOps ಅಭ್ಯಾಸಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ. ನಾವು ಬಿಡುಗಡೆಯ ಅನುಸ್ಥಾಪನ ಸಮಯವನ್ನು 10 ಪಟ್ಟು ಕಡಿಮೆಗೊಳಿಸಿದಾಗ ನಮಗೆ ಇದು ಮನವರಿಕೆಯಾಯಿತು. VTB ಯಲ್ಲಿ ನಾವು ಬಳಸುವ FIS ಪ್ರೊಫೈಲ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಅನುಸ್ಥಾಪನೆಯು ಈಗ 90 ಕ್ಕಿಂತ 10 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಬಿಡುಗಡೆಯ ನಿರ್ಮಾಣ ಸಮಯವು ಎರಡು ವಾರಗಳಿಂದ ಎರಡು ದಿನಗಳವರೆಗೆ ಕಡಿಮೆಯಾಗಿದೆ. ನಿರಂತರ ಅನುಷ್ಠಾನ ದೋಷಗಳ ಸಂಖ್ಯೆಯು ಬಹುತೇಕ ಕನಿಷ್ಠ ಮಟ್ಟಕ್ಕೆ ಇಳಿದಿದೆ. "ಕೈಪಿಡಿ ಕೆಲಸ" ದಿಂದ ದೂರವಿರಲು ಮತ್ತು ಮಾರಾಟಗಾರರ ಮೇಲೆ ಅವಲಂಬನೆಯನ್ನು ತೊಡೆದುಹಾಕಲು, ನಾವು ಊರುಗೋಲುಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬೇಕಾಗಿತ್ತು ಮತ್ತು ಅನಿರೀಕ್ಷಿತ ಪರಿಹಾರಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು. ಕಟ್ ಕೆಳಗೆ ನಾವು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಆಂತರಿಕ ಅಭಿವೃದ್ಧಿಯನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ವಿವರವಾದ ಕಥೆಯಾಗಿದೆ.
ಮುನ್ನುಡಿ: DevOps ಒಂದು ತತ್ವಶಾಸ್ತ್ರ
ಕಳೆದ ವರ್ಷದಲ್ಲಿ, VTB ನಲ್ಲಿ DevOps ಅಭ್ಯಾಸಗಳ ಆಂತರಿಕ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಅನುಷ್ಠಾನವನ್ನು ಸಂಘಟಿಸಲು ನಾವು ಸಾಕಷ್ಟು ಕೆಲಸ ಮಾಡಿದ್ದೇವೆ:
- ನಾವು 12 ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಆಂತರಿಕ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ;
- ನಾವು 15 ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಅವುಗಳಲ್ಲಿ ನಾಲ್ಕು ಉತ್ಪಾದನೆಗೆ ತರಲಾಗಿದೆ;
- ಸ್ವಯಂಚಾಲಿತ 1445 ಪರೀಕ್ಷಾ ಸನ್ನಿವೇಶಗಳು;
- ಆಂತರಿಕ ತಂಡಗಳು ಸಿದ್ಧಪಡಿಸಿದ ಹಲವಾರು ಬಿಡುಗಡೆಗಳನ್ನು ನಾವು ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ.
DevSecOps ಅಭ್ಯಾಸಗಳ ಆಂತರಿಕ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಅನುಷ್ಠಾನವನ್ನು ಸಂಘಟಿಸಲು ಅತ್ಯಂತ ಕಷ್ಟಕರವಾದದ್ದು FIS ಪ್ರೊಫೈಲ್ ಸಿಸ್ಟಮ್ - ಸಂಬಂಧವಿಲ್ಲದ DBMS ನಲ್ಲಿ ಚಿಲ್ಲರೆ ಉತ್ಪನ್ನ ಪ್ರೊಸೆಸರ್. ಅದೇನೇ ಇದ್ದರೂ, ನಾವು ಅಭಿವೃದ್ಧಿಯನ್ನು ನಿರ್ಮಿಸಲು, ಪೈಪ್ಲೈನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು, ಉತ್ಪನ್ನದ ಮೇಲೆ ಪ್ರತ್ಯೇಕ ನಾನ್-ರಿಲೀಸ್ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ಮತ್ತು ಬಿಡುಗಡೆಗಳನ್ನು ಹೇಗೆ ಜೋಡಿಸುವುದು ಎಂಬುದನ್ನು ಕಲಿತಿದ್ದೇವೆ. ಕಾರ್ಯವು ಸುಲಭವಲ್ಲ, ಆದರೆ ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ಅನುಷ್ಠಾನದಲ್ಲಿ ಸ್ಪಷ್ಟ ನಿರ್ಬಂಧಗಳಿಲ್ಲದೆ: ಇಲ್ಲಿ ಸಿಸ್ಟಮ್ ಇದೆ - ನೀವು ಆಂತರಿಕ ಅಭಿವೃದ್ಧಿಯನ್ನು ನಿರ್ಮಿಸಬೇಕಾಗಿದೆ. ಉತ್ಪಾದಕ ಪರಿಸರದ ಮೊದಲು ಸಿಡಿಯನ್ನು ಬಳಸುವುದು ಮಾತ್ರ ಷರತ್ತು.
ಮೊದಲಿಗೆ, ಅನುಷ್ಠಾನ ಅಲ್ಗಾರಿದಮ್ ಸರಳ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿದೆ:
- ನಾವು ಆರಂಭಿಕ ಅಭಿವೃದ್ಧಿ ಪರಿಣತಿಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇವೆ ಮತ್ತು ಸಮಗ್ರ ದೋಷಗಳಿಲ್ಲದೆ ಕೋಡ್ ತಂಡದಿಂದ ಸ್ವೀಕಾರಾರ್ಹ ಗುಣಮಟ್ಟದ ಗುಣಮಟ್ಟವನ್ನು ಸಾಧಿಸುತ್ತೇವೆ;
- ನಾವು ಸಾಧ್ಯವಾದಷ್ಟು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಸಂಯೋಜಿಸುತ್ತೇವೆ;
- ಸ್ಪಷ್ಟ ಹಂತಗಳ ನಡುವೆ ಕೋಡ್ ಅನ್ನು ವರ್ಗಾಯಿಸಲು, ನಾವು ಪೈಪ್ಲೈನ್ ಅನ್ನು ಕತ್ತರಿಸಿ ಅದರ ತುದಿಗಳಲ್ಲಿ ಒಂದನ್ನು ಮುಂದುವರಿಕೆಗೆ ತಳ್ಳುತ್ತೇವೆ.
ಈ ಸಮಯದಲ್ಲಿ, ಅಗತ್ಯವಿರುವ ಗಾತ್ರದ ಅಭಿವೃದ್ಧಿ ತಂಡವು ಕೌಶಲ್ಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕು ಮತ್ತು ಸ್ವೀಕಾರಾರ್ಹ ಮಟ್ಟಕ್ಕೆ ಬಿಡುಗಡೆಗಳಿಗೆ ಅದರ ಕೊಡುಗೆಯ ಪಾಲನ್ನು ಹೆಚ್ಚಿಸಬೇಕು. ಮತ್ತು ಅದು ಇಲ್ಲಿದೆ, ಪೂರ್ಣಗೊಂಡ ಕಾರ್ಯವನ್ನು ನಾವು ಪರಿಗಣಿಸಬಹುದು.
ಅಗತ್ಯವಿರುವ ಫಲಿತಾಂಶಕ್ಕೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಶಕ್ತಿ-ಸಮರ್ಥ ಮಾರ್ಗವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ: ಇಲ್ಲಿ DevOps ಇದೆ, ತಂಡದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೆಟ್ರಿಕ್‌ಗಳು ಇಲ್ಲಿವೆ, ಇಲ್ಲಿ ಸಂಗ್ರಹವಾದ ಪರಿಣತಿ ಇಲ್ಲಿದೆ... ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ, DevOps ಇನ್ನೂ ತತ್ತ್ವಶಾಸ್ತ್ರದ ಬಗ್ಗೆ ನಮಗೆ ಮತ್ತೊಂದು ದೃಢೀಕರಣ ಸಿಕ್ಕಿದೆ , ಮತ್ತು "ಗಿಟ್ಲ್ಯಾಬ್ ಪ್ರಕ್ರಿಯೆಗೆ ಲಗತ್ತಿಸಲಾಗಿಲ್ಲ, ಅನ್ಸಿಬಲ್, ನೆಕ್ಸಸ್ ಮತ್ತು ಪಟ್ಟಿಯ ಕೆಳಗೆ."
ಕ್ರಿಯಾ ಯೋಜನೆಯನ್ನು ಮತ್ತೊಮ್ಮೆ ವಿಶ್ಲೇಷಿಸಿದ ನಂತರ, ನಾವು ನಮ್ಮೊಳಗೆ ಒಂದು ರೀತಿಯ ಹೊರಗುತ್ತಿಗೆ ಮಾರಾಟಗಾರರನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡೆವು. ಆದ್ದರಿಂದ, ಪ್ರಕ್ರಿಯೆಯ ಮರುಇಂಜಿನಿಯರಿಂಗ್ ಅನ್ನು ಮೇಲೆ ವಿವರಿಸಿದ ಅಲ್ಗಾರಿದಮ್‌ಗೆ ಸೇರಿಸಲಾಯಿತು, ಜೊತೆಗೆ ಈ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಪ್ರಮುಖ ಪಾತ್ರವನ್ನು ಸಾಧಿಸಲು ಸಂಪೂರ್ಣ ಅಭಿವೃದ್ಧಿ ಮಾರ್ಗದಲ್ಲಿ ಪರಿಣತಿಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಯಿತು. ಸುಲಭವಾದ ಆಯ್ಕೆಯಲ್ಲ, ಆದರೆ ಇದು ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಸರಿಯಾದ ಅಭಿವೃದ್ಧಿಯ ಮಾರ್ಗವಾಗಿದೆ.
ಆಂತರಿಕ ಅಭಿವೃದ್ಧಿ ಎಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ?
ಇದು ಕೆಲಸ ಮಾಡಲು ಅತ್ಯಂತ ಸ್ನೇಹಪರ ವ್ಯವಸ್ಥೆಯಾಗಿರಲಿಲ್ಲ. ವಾಸ್ತುಶಿಲ್ಪದ ಪ್ರಕಾರ, ಇದು ಒಂದು ದೊಡ್ಡ ಸಂಬಂಧವಿಲ್ಲದ DBMS ಆಗಿದ್ದು, ಅನೇಕ ಪ್ರತ್ಯೇಕ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ವಸ್ತುಗಳನ್ನು (ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, ಕಾರ್ಯವಿಧಾನಗಳು, ಬ್ಯಾಚ್‌ಗಳು, ಇತ್ಯಾದಿ) ಒಳಗೊಂಡಿತ್ತು, ಇವುಗಳನ್ನು ಅಗತ್ಯವಿರುವಂತೆ ಕರೆಯಲಾಗುತ್ತಿತ್ತು ಮತ್ತು ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯ ತತ್ತ್ವದ ಮೇಲೆ ಕೆಲಸ ಮಾಡಲಾಗುತ್ತಿತ್ತು: ಇದು ವಿನಂತಿಯನ್ನು ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಒಂದು ಪ್ರತಿಕ್ರಿಯೆ. ಗಮನಿಸಬೇಕಾದ ಇತರ ತೊಂದರೆಗಳು ಸೇರಿವೆ:
- ವಿಲಕ್ಷಣ ಭಾಷೆ (MUMPS);
- ಕನ್ಸೋಲ್ ಇಂಟರ್ಫೇಸ್;
- ಜನಪ್ರಿಯ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪರಿಕರಗಳು ಮತ್ತು ಚೌಕಟ್ಟುಗಳೊಂದಿಗೆ ಏಕೀಕರಣದ ಕೊರತೆ;
- ಹತ್ತಾರು ಟೆರಾಬೈಟ್‌ಗಳಲ್ಲಿ ಡೇಟಾ ಪರಿಮಾಣ;
- ಗಂಟೆಗೆ 2 ಮಿಲಿಯನ್ ಕಾರ್ಯಾಚರಣೆಗಳ ಲೋಡ್;
- ಮಹತ್ವ - ವ್ಯಾಪಾರ-ನಿರ್ಣಾಯಕ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ನಮ್ಮ ಕಡೆ ಯಾವುದೇ ಮೂಲ ಕೋಡ್ ರೆಪೊಸಿಟರಿ ಇರಲಿಲ್ಲ. ಎಲ್ಲಾ. ದಾಖಲಾತಿ ಇತ್ತು, ಆದರೆ ಎಲ್ಲಾ ಪ್ರಮುಖ ಜ್ಞಾನ ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳು ಬಾಹ್ಯ ಸಂಸ್ಥೆಯ ಬದಿಯಲ್ಲಿವೆ.
ನಾವು ಮೊದಲಿನಿಂದಲೂ ಸಿಸ್ಟಮ್ನ ಅಭಿವೃದ್ಧಿಯನ್ನು ಮಾಸ್ಟರಿಂಗ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಅದರ ವೈಶಿಷ್ಟ್ಯಗಳು ಮತ್ತು ಕಡಿಮೆ ವಿತರಣೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ. ಅಕ್ಟೋಬರ್ 2018 ರಲ್ಲಿ ಪ್ರಾರಂಭವಾಯಿತು:
- ಕೋಡ್ ಉತ್ಪಾದನೆಯ ದಸ್ತಾವೇಜನ್ನು ಮತ್ತು ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡಿದೆ;
- ನಾವು ಮಾರಾಟಗಾರರಿಂದ ಪಡೆದ ಅಭಿವೃದ್ಧಿಯ ಕಿರು ಕೋರ್ಸ್ ಅನ್ನು ಅಧ್ಯಯನ ಮಾಡುತ್ತೇವೆ;
- ಮಾಸ್ಟರಿಂಗ್ ಆರಂಭಿಕ ಅಭಿವೃದ್ಧಿ ಕೌಶಲ್ಯಗಳು;
- ನಾವು ಹೊಸ ತಂಡದ ಸದಸ್ಯರಿಗೆ ತರಬೇತಿ ಕೈಪಿಡಿಯನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ;
- ನಾವು ತಂಡವನ್ನು "ಯುದ್ಧ" ಕ್ರಮದಲ್ಲಿ ಸೇರಿಸಲು ಒಪ್ಪಿಕೊಂಡಿದ್ದೇವೆ;
- ಕೋಡ್ ಗುಣಮಟ್ಟ ನಿಯಂತ್ರಣದೊಂದಿಗೆ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ;
- ನಾವು ಅಭಿವೃದ್ಧಿಯ ನಿಲುವನ್ನು ಆಯೋಜಿಸಿದ್ದೇವೆ.
ನಾವು ಪರಿಣತಿಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಮತ್ತು ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಮ್ಮನ್ನು ಮುಳುಗಿಸಲು ಮೂರು ತಿಂಗಳುಗಳನ್ನು ಕಳೆದಿದ್ದೇವೆ ಮತ್ತು 2019 ರ ಆರಂಭದಿಂದ, ಆಂತರಿಕ ಅಭಿವೃದ್ಧಿಯು ಉಜ್ವಲ ಭವಿಷ್ಯದ ಕಡೆಗೆ ತನ್ನ ಚಲನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿತು, ಕೆಲವೊಮ್ಮೆ ಕಷ್ಟದಿಂದ, ಆದರೆ ವಿಶ್ವಾಸದಿಂದ ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ.
ರೆಪೊಸಿಟರಿ ವಲಸೆ ಮತ್ತು ಸ್ವಯಂ ಪರೀಕ್ಷೆಗಳು
ಮೊದಲ DevOps ಕಾರ್ಯವು ರೆಪೊಸಿಟರಿಯಾಗಿದೆ. ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಲು ನಾವು ತ್ವರಿತವಾಗಿ ಒಪ್ಪಿಕೊಂಡಿದ್ದೇವೆ, ಆದರೆ ಹಲವಾರು ಶಾಖೆಗಳ ಮಾದರಿಗೆ ಪರಿವರ್ತನೆ ಮತ್ತು Git ಫ್ಲೋ ಅಭಿವೃದ್ಧಿಯೊಂದಿಗೆ ಪ್ರಸ್ತುತ SVN ನಿಂದ ಒಂದು ಟ್ರಂಕ್ ಶಾಖೆಯೊಂದಿಗೆ ನಮ್ಮ ಗುರಿ Git ಗೆ ವಲಸೆ ಹೋಗುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ನಾವು ತಮ್ಮದೇ ಆದ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ 2 ತಂಡಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಜೊತೆಗೆ ವಿದೇಶದಲ್ಲಿ ಮಾರಾಟಗಾರರ ತಂಡದ ಭಾಗವಾಗಿದೆ. ನಾನು ಎರಡು ಗಿಟ್‌ಗಳೊಂದಿಗೆ ಬದುಕಬೇಕಾಗಿತ್ತು ಮತ್ತು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕಾಗಿತ್ತು. ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಇದು ಎರಡು ಕೆಟ್ಟದ್ದಕ್ಕಿಂತ ಕಡಿಮೆಯಾಗಿದೆ.
ರೆಪೊಸಿಟರಿಯ ವಲಸೆಯನ್ನು ಪದೇ ಪದೇ ಮುಂದೂಡಲಾಯಿತು; ಇದು ಮುಂಚೂಣಿಯಲ್ಲಿರುವ ಸಹೋದ್ಯೋಗಿಗಳ ಸಹಾಯದಿಂದ ಏಪ್ರಿಲ್‌ನಲ್ಲಿ ಮಾತ್ರ ಪೂರ್ಣಗೊಂಡಿತು. Git Flow ನೊಂದಿಗೆ, ನಾವು ಪ್ರಾರಂಭಕ್ಕಾಗಿ ವಿಷಯಗಳನ್ನು ಸರಳವಾಗಿಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಹಾಟ್‌ಫಿಕ್ಸ್, ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಬಿಡುಗಡೆಯೊಂದಿಗೆ ಕ್ಲಾಸಿಕ್ ಸ್ಕೀಮ್‌ನಲ್ಲಿ ನೆಲೆಸಿದ್ದೇವೆ. ಅವರು ಮಾಸ್ಟರ್ ಅನ್ನು ತ್ಯಜಿಸಲು ನಿರ್ಧರಿಸಿದರು (ಅಕಾ ಪ್ರಾಡ್-ಲೈಕ್). ಈ ಆಯ್ಕೆಯು ನಮಗೆ ಏಕೆ ಸೂಕ್ತವಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ಕೆಳಗೆ ವಿವರಿಸುತ್ತೇವೆ. ಎರಡು ತಂಡಗಳಿಗೆ ಸಾಮಾನ್ಯವಾದ ಮಾರಾಟಗಾರನಿಗೆ ಸೇರಿದ ಬಾಹ್ಯ ಭಂಡಾರವನ್ನು ಕೆಲಸಗಾರನಾಗಿ ಬಳಸಲಾಗಿದೆ. ಇದು ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ ಆಂತರಿಕ ರೆಪೊಸಿಟರಿಯೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಆಗಿದೆ. ಈಗ Git ಮತ್ತು Gitlab ನೊಂದಿಗೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಯಿತು.
ಆಟೋಟೆಸ್ಟ್‌ಗಳ ಸಮಸ್ಯೆಯನ್ನು ಆಶ್ಚರ್ಯಕರವಾಗಿ ಸುಲಭವಾಗಿ ಪರಿಹರಿಸಲಾಗಿದೆ - ನಮಗೆ ಸಿದ್ಧ ಚೌಕಟ್ಟನ್ನು ಒದಗಿಸಲಾಗಿದೆ. ಸಿಸ್ಟಮ್ನ ವಿಶಿಷ್ಟತೆಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ಪ್ರತ್ಯೇಕ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಕರೆಯುವುದು ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಯ ಅರ್ಥವಾಗುವ ಭಾಗವಾಗಿದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಘಟಕ ಪರೀಕ್ಷೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಪರೀಕ್ಷಾ ಡೇಟಾವನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಕರೆಯುವ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಅಪೇಕ್ಷಿತ ಕ್ರಮವನ್ನು ಹೊಂದಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ. ಕಾರ್ಯಾಚರಣೆಯ ಅಂಕಿಅಂಶಗಳು, ಪ್ರಕ್ರಿಯೆಗಳ ವಿಮರ್ಶಾತ್ಮಕತೆ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ರಿಗ್ರೆಷನ್ ವಿಧಾನದ ಆಧಾರದ ಮೇಲೆ ರೂಪುಗೊಂಡ ಸನ್ನಿವೇಶಗಳ ಪಟ್ಟಿಯನ್ನು ಭರ್ತಿ ಮಾಡಿ, ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದವು. ಈಗ ನಾವು ಪೈಪ್ಲೈನ್ ನಿರ್ಮಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು.
ಅದು ಹೇಗೆ: ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಮೊದಲು ಮಾದರಿ
ಅನುಷ್ಠಾನ ಪ್ರಕ್ರಿಯೆಯ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾದರಿಯು ಪ್ರತ್ಯೇಕ ಕಥೆಯಾಗಿದೆ. ಪ್ರತಿಯೊಂದು ಮಾರ್ಪಾಡುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಇನ್‌ಕ್ರಿಮೆಂಟಲ್ ಇನ್‌ಸ್ಟಾಲೇಶನ್ ಪ್ಯಾಕೇಜ್‌ನಂತೆ ಹಸ್ತಚಾಲಿತವಾಗಿ ವರ್ಗಾಯಿಸಲಾಗಿದೆ. ಮುಂದೆ ಜಿರಾದಲ್ಲಿ ಹಸ್ತಚಾಲಿತ ನೋಂದಣಿ ಮತ್ತು ಪರಿಸರದಲ್ಲಿ ಹಸ್ತಚಾಲಿತ ಸ್ಥಾಪನೆ. ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೇಜ್‌ಗಳಿಗಾಗಿ, ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಬಿಡುಗಡೆಯ ತಯಾರಿಕೆಯೊಂದಿಗೆ, ವಿಷಯಗಳು ಹೆಚ್ಚು ಜಟಿಲವಾಗಿವೆ.
ಅಸೆಂಬ್ಲಿಯನ್ನು ಪ್ರತ್ಯೇಕ ವಿತರಣೆಗಳ ಮಟ್ಟದಲ್ಲಿ ನಡೆಸಲಾಯಿತು, ಅವುಗಳು ಸ್ವತಂತ್ರ ವಸ್ತುಗಳಾಗಿವೆ. ಯಾವುದೇ ಬದಲಾವಣೆಯು ಹೊಸ ವಿತರಣೆಯಾಗಿದೆ. ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ಮುಖ್ಯ ಬಿಡುಗಡೆಯ ಸಂಯೋಜನೆಯ 60-70 ಪ್ಯಾಕೇಜ್‌ಗಳಿಗೆ 10-15 ತಾಂತ್ರಿಕ ಆವೃತ್ತಿಗಳನ್ನು ಸೇರಿಸಲಾಯಿತು - ಬಿಡುಗಡೆಯಿಂದ ಏನನ್ನಾದರೂ ಸೇರಿಸಿದಾಗ ಅಥವಾ ಹೊರಗಿಡುವಾಗ ಮತ್ತು ಬಿಡುಗಡೆಯ ಹೊರಗಿನ ಮಾರಾಟದಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವಾಗ ಪಡೆದ ಆವೃತ್ತಿಗಳು.
ವಿತರಣೆಯೊಳಗಿನ ವಸ್ತುಗಳು ಪರಸ್ಪರ ಅತಿಕ್ರಮಿಸಲ್ಪಟ್ಟಿವೆ, ವಿಶೇಷವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಕೋಡ್‌ನಲ್ಲಿ, ಇದು ಅರ್ಧಕ್ಕಿಂತ ಕಡಿಮೆ ಅನನ್ಯವಾಗಿದೆ. ಈಗಾಗಲೇ ಸ್ಥಾಪಿಸಲಾದ ಕೋಡ್ ಮತ್ತು ಅದರ ಸ್ಥಾಪನೆಯನ್ನು ಈಗಷ್ಟೇ ಯೋಜಿಸಿರುವ ಒಂದರ ಮೇಲೆ ಅನೇಕ ಅವಲಂಬನೆಗಳು ಇದ್ದವು.
ಕೋಡ್‌ನ ಅಗತ್ಯವಿರುವ ಆವೃತ್ತಿಯನ್ನು ಪಡೆಯಲು, ಅನುಸ್ಥಾಪನಾ ಕ್ರಮವನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಅನುಸರಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು, ಈ ಸಮಯದಲ್ಲಿ ವಸ್ತುಗಳನ್ನು ಭೌತಿಕವಾಗಿ ಹಲವಾರು ಬಾರಿ ಪುನಃ ಬರೆಯಲಾಗುತ್ತದೆ, ಕೆಲವು 10-12 ಬಾರಿ.
ಪ್ಯಾಕೇಜ್‌ಗಳ ಬ್ಯಾಚ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ ನಂತರ, ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಾನು ಕೈಯಾರೆ ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಬೇಕಾಗಿತ್ತು. ಬಿಡುಗಡೆಯನ್ನು ಮಾರಾಟಗಾರರಿಂದ ಜೋಡಿಸಲಾಗಿದೆ ಮತ್ತು ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ಬಿಡುಗಡೆಯ ಸಂಯೋಜನೆಯು ಅನುಷ್ಠಾನದ ಕ್ಷಣಕ್ಕಿಂತ ಮುಂಚೆಯೇ ಸ್ಪಷ್ಟಪಡಿಸಲ್ಪಟ್ಟಿದೆ, ಇದು "ಡಿಕೌಪ್ಲಿಂಗ್" ಪ್ಯಾಕೇಜುಗಳ ರಚನೆಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಸರಬರಾಜುಗಳ ಗಮನಾರ್ಹ ಭಾಗವು "ಡಿಕೌಪ್ಲಿಂಗ್ಸ್" ನ ತನ್ನದೇ ಆದ ಬಾಲದೊಂದಿಗೆ ಬಿಡುಗಡೆಯಿಂದ ಬಿಡುಗಡೆಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿತು.
ಈ ವಿಧಾನದೊಂದಿಗೆ - ಪ್ಯಾಕೇಜ್ ಮಟ್ಟದಲ್ಲಿ ಬಿಡುಗಡೆಯ ಪಝಲ್ ಅನ್ನು ಜೋಡಿಸುವುದು - ಒಂದೇ ಮಾಸ್ಟರ್ ಶಾಖೆಯು ಪ್ರಾಯೋಗಿಕ ಅರ್ಥವನ್ನು ಹೊಂದಿಲ್ಲ ಎಂಬುದು ಈಗ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಉತ್ಪಾದನೆಯ ಮೇಲೆ ಅನುಸ್ಥಾಪನೆಯು ಒಂದೂವರೆ ರಿಂದ ಎರಡು ಗಂಟೆಗಳವರೆಗೆ ಕೈಯಿಂದ ಕೆಲಸ ಮಾಡಿತು. ಕನಿಷ್ಠ ಸ್ಥಾಪಕ ಮಟ್ಟದಲ್ಲಿ ವಸ್ತು ಸಂಸ್ಕರಣೆಯ ಕ್ರಮವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿರುವುದು ಒಳ್ಳೆಯದು: ಕ್ಷೇತ್ರಗಳು ಮತ್ತು ರಚನೆಗಳನ್ನು ಡೇಟಾ ಮತ್ತು ಕಾರ್ಯವಿಧಾನಗಳಿಗೆ ಮೊದಲು ನಮೂದಿಸಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಇದು ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೇಜ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಈ ವಿಧಾನದ ತಾರ್ಕಿಕ ಫಲಿತಾಂಶವೆಂದರೆ ವಸ್ತುಗಳ ವಕ್ರ ಆವೃತ್ತಿಗಳು, ಅನಗತ್ಯ ಕೋಡ್, ಕಾಣೆಯಾದ ಸೂಚನೆಗಳು ಮತ್ತು ವಸ್ತುಗಳ ಪರಸ್ಪರ ಪ್ರಭಾವಗಳಿಗೆ ಲೆಕ್ಕವಿಲ್ಲದ ರೂಪದಲ್ಲಿ ಕಡ್ಡಾಯವಾದ ಅನುಸ್ಥಾಪನ ದೋಷಗಳು, ಬಿಡುಗಡೆಯ ನಂತರ ಜ್ವರದಿಂದ ಹೊರಹಾಕಲ್ಪಟ್ಟವು.
ಮೊದಲ ನವೀಕರಣಗಳು: ಅಸೆಂಬ್ಲಿ ಮತ್ತು ವಿತರಣೆಯನ್ನು ಒಪ್ಪಿಸಿ
ಈ ಮಾರ್ಗದಲ್ಲಿ ಪೈಪ್ ಮೂಲಕ ಕೋಡ್ ಅನ್ನು ರವಾನಿಸುವ ಮೂಲಕ ಆಟೊಮೇಷನ್ ಪ್ರಾರಂಭವಾಯಿತು:
- ಸಂಗ್ರಹಣೆಯಿಂದ ಮುಗಿದ ವಿತರಣೆಯನ್ನು ಎತ್ತಿಕೊಳ್ಳಿ;
- ಮೀಸಲಾದ ಪರಿಸರದಲ್ಲಿ ಅದನ್ನು ಸ್ಥಾಪಿಸಿ;
- ಸ್ವಯಂ ಪರೀಕ್ಷೆಗಳನ್ನು ಚಲಾಯಿಸಿ;
- ಅನುಸ್ಥಾಪನೆಯ ಫಲಿತಾಂಶವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ;
- ಪರೀಕ್ಷಾ ಆಜ್ಞೆಯ ಬದಿಯಲ್ಲಿ ಕೆಳಗಿನ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಕರೆ ಮಾಡಿ.
ಮುಂದಿನ ಪೈಪ್ಲೈನ್ ಜಿರಾದಲ್ಲಿ ಕಾರ್ಯವನ್ನು ನೋಂದಾಯಿಸಬೇಕು ಮತ್ತು ಆಯ್ದ ಪರೀಕ್ಷಾ ಲೂಪ್‌ಗಳಿಗೆ ಆಜ್ಞೆಗಳನ್ನು ವಿತರಿಸಲು ಕಾಯಬೇಕು, ಇದು ಕಾರ್ಯದ ಅನುಷ್ಠಾನದ ಸಮಯವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಪ್ರಚೋದಕ - ನಿರ್ದಿಷ್ಟ ವಿಳಾಸಕ್ಕೆ ತಲುಪಿಸಲು ಸನ್ನದ್ಧತೆಯ ಬಗ್ಗೆ ಪತ್ರ. ಇದು ಸಹಜವಾಗಿ, ಸ್ಪಷ್ಟವಾದ ಊರುಗೋಲು, ಆದರೆ ನಾನು ಎಲ್ಲೋ ಪ್ರಾರಂಭಿಸಬೇಕಾಗಿತ್ತು. ಮೇ 2019 ರಲ್ಲಿ, ನಮ್ಮ ಪರಿಸರದ ಪರಿಶೀಲನೆಯೊಂದಿಗೆ ಕೋಡ್‌ನ ವರ್ಗಾವಣೆ ಪ್ರಾರಂಭವಾಯಿತು. ಪ್ರಕ್ರಿಯೆಯು ಪ್ರಾರಂಭವಾಗಿದೆ, ಅದನ್ನು ಯೋಗ್ಯವಾದ ಆಕಾರಕ್ಕೆ ತರಲು ಮಾತ್ರ ಉಳಿದಿದೆ:
- ಪ್ರತಿಯೊಂದು ಮಾರ್ಪಾಡುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಶಾಖೆಯಲ್ಲಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ, ಇದು ಅನುಸ್ಥಾಪನ ಪ್ಯಾಕೇಜ್ಗೆ ಅನುರೂಪವಾಗಿದೆ ಮತ್ತು ಗುರಿ ಮಾಸ್ಟರ್ ಶಾಖೆಗೆ ವಿಲೀನಗೊಳ್ಳುತ್ತದೆ;
- ಪೈಪ್ಲೈನ್ ಉಡಾವಣೆ ಪ್ರಚೋದಕವು ವಿಲೀನ ವಿನಂತಿಯ ಮೂಲಕ ಮಾಸ್ಟರ್ ಶಾಖೆಯಲ್ಲಿ ಹೊಸ ಬದ್ಧತೆಯ ಗೋಚರಿಸುವಿಕೆಯಾಗಿದೆ, ಇದನ್ನು ಇನ್‌ಹೌಸ್ ತಂಡದ ನಿರ್ವಾಹಕರು ಮುಚ್ಚುತ್ತಾರೆ;
- ರೆಪೊಸಿಟರಿಗಳನ್ನು ಪ್ರತಿ ಐದು ನಿಮಿಷಗಳಿಗೊಮ್ಮೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ;
- ಅನುಸ್ಥಾಪನಾ ಪ್ಯಾಕೇಜ್ನ ಜೋಡಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ - ಮಾರಾಟಗಾರರಿಂದ ಪಡೆದ ಅಸೆಂಬ್ಲರ್ ಅನ್ನು ಬಳಸಿ.
ಇದರ ನಂತರ, ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ಮತ್ತು ವರ್ಗಾಯಿಸಲು, ಪೈಪ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ನಮ್ಮ ಬದಿಯಲ್ಲಿ ಜೋಡಿಸಲು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಹಂತಗಳು ಇದ್ದವು.
ಈ ಆಯ್ಕೆಯನ್ನು ಜುಲೈನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಯಿತು. ಪರಿವರ್ತನೆಯ ತೊಂದರೆಗಳು ಮಾರಾಟಗಾರ ಮತ್ತು ಮುಂಚೂಣಿಯಲ್ಲಿ ಕೆಲವು ಅಸಮಾಧಾನಕ್ಕೆ ಕಾರಣವಾಯಿತು, ಆದರೆ ಮುಂದಿನ ತಿಂಗಳಲ್ಲಿ ನಾವು ಎಲ್ಲಾ ಒರಟು ಅಂಚುಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಮತ್ತು ತಂಡಗಳ ನಡುವೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ಥಾಪಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ. ನಾವು ಈಗ ಬದ್ಧತೆ ಮತ್ತು ವಿತರಣೆಯ ಮೂಲಕ ಜೋಡಣೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಆಗಸ್ಟ್‌ನಲ್ಲಿ, ನಮ್ಮ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೇಜ್ನ ಮೊದಲ ಸ್ಥಾಪನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ನಾವು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಸೆಪ್ಟೆಂಬರ್‌ನಿಂದ ವಿನಾಯಿತಿ ಇಲ್ಲದೆ, ವೈಯಕ್ತಿಕ ಬಿಡುಗಡೆ ರಹಿತ ಪ್ಯಾಕೇಜ್‌ಗಳ ಎಲ್ಲಾ ಸ್ಥಾಪನೆಗಳನ್ನು ನಮ್ಮ ಸಿಡಿ ಉಪಕರಣದ ಮೂಲಕ ನಿರ್ವಹಿಸಲಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಮಾರಾಟಗಾರರಿಗಿಂತ ಚಿಕ್ಕ ತಂಡದೊಂದಿಗೆ ಬಿಡುಗಡೆಯ ಸಂಯೋಜನೆಯ 40% ರಲ್ಲಿ ಆಂತರಿಕ ಕಾರ್ಯಗಳ ಪಾಲನ್ನು ಸಾಧಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ - ಇದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಯಶಸ್ಸು. ಅತ್ಯಂತ ಗಂಭೀರವಾದ ಕಾರ್ಯವು ಉಳಿದಿದೆ - ಬಿಡುಗಡೆಯನ್ನು ಜೋಡಿಸಲು ಮತ್ತು ಸ್ಥಾಪಿಸಲು.
ಅಂತಿಮ ಪರಿಹಾರ: ಸಂಚಿತ ಅನುಸ್ಥಾಪನ ಪ್ಯಾಕೇಜುಗಳು
ಮಾರಾಟಗಾರರ ಸೂಚನೆಗಳನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವುದು ತುಂಬಾ ಯಾಂತ್ರೀಕೃತವಾಗಿದೆ ಎಂದು ನಾವು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ; ನಾವು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವತಃ ಪುನರ್ವಿಮರ್ಶಿಸಬೇಕಾಗಿದೆ. ಪರಿಹಾರವು ಸ್ಪಷ್ಟವಾಗಿತ್ತು - ಅಗತ್ಯವಿರುವ ಆವೃತ್ತಿಗಳ ಎಲ್ಲಾ ವಸ್ತುಗಳೊಂದಿಗೆ ಬಿಡುಗಡೆ ಶಾಖೆಯಿಂದ ಸಂಚಿತ ಪೂರೈಕೆಯನ್ನು ಸಂಗ್ರಹಿಸಲು.
ನಾವು ಪರಿಕಲ್ಪನೆಯ ಪುರಾವೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ: ಹಿಂದಿನ ಅನುಷ್ಠಾನದ ವಿಷಯಗಳ ಪ್ರಕಾರ ನಾವು ಬಿಡುಗಡೆ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಕೈಯಿಂದ ಜೋಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ನಮ್ಮ ಪರಿಸರದಲ್ಲಿ ಸ್ಥಾಪಿಸಿದ್ದೇವೆ. ಎಲ್ಲವೂ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬಂದವು, ಪರಿಕಲ್ಪನೆಯು ಕಾರ್ಯಸಾಧ್ಯವಾಗಿದೆ. ಮುಂದೆ, ನಾವು ಪ್ರಾರಂಭಿಕ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಬದ್ಧತೆಯಲ್ಲಿ ಸೇರಿಸಿದ್ದೇವೆ. ನಾವು ಹೊಸ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಬಾಹ್ಯರೇಖೆಯ ನವೀಕರಣದ ಭಾಗವಾಗಿ ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಅದನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ. ಅನುಷ್ಠಾನ ತಂಡದಿಂದ ವ್ಯಾಪಕವಾದ ಕಾಮೆಂಟ್‌ಗಳೊಂದಿಗೆ ಅನುಸ್ಥಾಪನೆಯು ಯಶಸ್ವಿಯಾಗಿದೆ. ಆದರೆ ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ನಮ್ಮ ಅಸೆಂಬ್ಲಿಯೊಂದಿಗೆ ನವೆಂಬರ್ ಬಿಡುಗಡೆಯಲ್ಲಿ ಉತ್ಪಾದನೆಗೆ ಹೋಗಲು ನಮಗೆ ಅವಕಾಶ ನೀಡಲಾಯಿತು.
ಕೇವಲ ಒಂದು ತಿಂಗಳು ಉಳಿದಿರುವಾಗ, ಕೈಯಿಂದ ಆರಿಸಲ್ಪಟ್ಟ ಸರಬರಾಜುಗಳು ಸಮಯವು ಮುಗಿದಿದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಸುಳಿವು ನೀಡಿತು. ಅವರು ಬಿಡುಗಡೆ ಶಾಖೆಯಿಂದ ನಿರ್ಮಾಣವನ್ನು ಮಾಡಲು ನಿರ್ಧರಿಸಿದರು, ಆದರೆ ಅದನ್ನು ಏಕೆ ಬೇರ್ಪಡಿಸಬೇಕು? ನಮ್ಮಲ್ಲಿ ಉತ್ಪನ್ನದಂತಹ ಉತ್ಪನ್ನವಿಲ್ಲ, ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಶಾಖೆಗಳು ಉತ್ತಮವಾಗಿಲ್ಲ - ಬಹಳಷ್ಟು ಅನಗತ್ಯ ಕೋಡ್‌ಗಳಿವೆ. ನಾವು ತುರ್ತಾಗಿ ಪ್ರಾಡ್-ಲೈಕ್‌ಗಳನ್ನು ಕತ್ತರಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ಇದು ಮೂರು ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ಕಮಿಟ್‌ಗಳು. ಕೈಯಿಂದ ಜೋಡಿಸುವುದು ಒಂದು ಆಯ್ಕೆಯಾಗಿಲ್ಲ. ಉತ್ಪನ್ನ ಸ್ಥಾಪನೆ ಲಾಗ್ ಮೂಲಕ ಚಲಿಸುವ ಮತ್ತು ಶಾಖೆಗೆ ಕಮಿಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ನಾವು ಚಿತ್ರಿಸಿದ್ದೇವೆ. ಮೂರನೆಯ ಬಾರಿ ಅದು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ, ಮತ್ತು "ಫೈಲ್ನೊಂದಿಗೆ ಮುಗಿದ" ನಂತರ ಶಾಖೆ ಸಿದ್ಧವಾಗಿದೆ.
ನಾವು ಅನುಸ್ಥಾಪನ ಪ್ಯಾಕೇಜ್‌ಗಾಗಿ ನಮ್ಮ ಸ್ವಂತ ಬಿಲ್ಡರ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಒಂದು ವಾರದಲ್ಲಿ ಮುಗಿಸಿದ್ದೇವೆ. ನಂತರ ನಾವು ಸ್ಥಾಪಕವನ್ನು ಸಿಸ್ಟಮ್ನ ಪ್ರಮುಖ ಕಾರ್ಯನಿರ್ವಹಣೆಯಿಂದ ಮಾರ್ಪಡಿಸಬೇಕಾಗಿತ್ತು, ಏಕೆಂದರೆ ಅದು ತೆರೆದ ಮೂಲವಾಗಿದೆ. ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ಮಾರ್ಪಾಡುಗಳ ಸರಣಿಯ ನಂತರ, ಫಲಿತಾಂಶವು ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ. ಈ ಮಧ್ಯೆ, ಬಿಡುಗಡೆಯ ಸಂಯೋಜನೆಯು ಆಕಾರವನ್ನು ಪಡೆದುಕೊಂಡಿತು, ಅದರ ಸರಿಯಾದ ಸ್ಥಾಪನೆಗಾಗಿ ಪರೀಕ್ಷಾ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಉತ್ಪಾದನೆಯೊಂದಿಗೆ ಜೋಡಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು ಮತ್ತು ಇದಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬರೆಯಲಾಗಿದೆ.
ಸ್ವಾಭಾವಿಕವಾಗಿ, ಮೊದಲ ಅನುಸ್ಥಾಪನೆಯ ಬಗ್ಗೆ ಬಹಳಷ್ಟು ಕಾಮೆಂಟ್ಗಳು ಇದ್ದವು, ಆದರೆ ಒಟ್ಟಾರೆ ಕೋಡ್ ಕೆಲಸ ಮಾಡಿದೆ. ಮತ್ತು ಮೂರನೇ ಅನುಸ್ಥಾಪನೆಯ ನಂತರ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾಣಲಾರಂಭಿಸಿತು. ಸಂಯೋಜನೆ ನಿಯಂತ್ರಣ ಮತ್ತು ವಸ್ತುಗಳ ಆವೃತ್ತಿ ನಿಯಂತ್ರಣವನ್ನು ಹಸ್ತಚಾಲಿತ ಕ್ರಮದಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಯಿತು, ಈ ಹಂತದಲ್ಲಿ ಇದು ಸಾಕಷ್ಟು ಸಮರ್ಥನೆಯಾಗಿದೆ.
ಹೆಚ್ಚುವರಿ ಸವಾಲೆಂದರೆ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ನಾನ್-ರಿಲೀಸ್‌ಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗಿತ್ತು. ಆದರೆ ಪ್ರಾಡ್ ತರಹದ ಶಾಖೆ ಮತ್ತು ರಿಬೇಸ್‌ನೊಂದಿಗೆ, ಕಾರ್ಯವು ಪಾರದರ್ಶಕವಾಯಿತು.
ಮೊದಲ ಬಾರಿಗೆ, ತ್ವರಿತವಾಗಿ ಮತ್ತು ದೋಷಗಳಿಲ್ಲದೆ
ನಾವು ಆಶಾವಾದಿ ವರ್ತನೆ ಮತ್ತು ವಿವಿಧ ಸರ್ಕ್ಯೂಟ್‌ಗಳಲ್ಲಿ ಒಂದು ಡಜನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು ಯಶಸ್ವಿ ಸ್ಥಾಪನೆಗಳೊಂದಿಗೆ ಬಿಡುಗಡೆಯನ್ನು ಸಮೀಪಿಸಿದ್ದೇವೆ. ಆದರೆ ಅಕ್ಷರಶಃ ಗಡುವಿನ ಒಂದು ದಿನದ ಮೊದಲು, ಮಾರಾಟಗಾರನು ಒಪ್ಪಿಕೊಂಡ ರೀತಿಯಲ್ಲಿ ಅನುಸ್ಥಾಪನೆಗೆ ಬಿಡುಗಡೆಯನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಿಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಕೆಲವು ಕಾರಣಗಳಿಂದ ನಮ್ಮ ನಿರ್ಮಾಣವು ಕಾರ್ಯನಿರ್ವಹಿಸದಿದ್ದರೆ, ಬಿಡುಗಡೆಯು ಅಡ್ಡಿಯಾಗುತ್ತದೆ. ಇದಲ್ಲದೆ, ನಮ್ಮ ಪ್ರಯತ್ನಗಳ ಮೂಲಕ, ಇದು ವಿಶೇಷವಾಗಿ ಅಹಿತಕರವಾಗಿದೆ. ನಮಗೆ ಹಿಮ್ಮೆಟ್ಟಲು ದಾರಿಯೇ ಇರಲಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ಪರ್ಯಾಯ ಆಯ್ಕೆಗಳ ಮೂಲಕ ಯೋಚಿಸಿದ್ದೇವೆ, ಕ್ರಿಯಾ ಯೋಜನೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಅನುಸ್ಥಾಪನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.
ಆಶ್ಚರ್ಯಕರವಾಗಿ, 800 ಕ್ಕೂ ಹೆಚ್ಚು ವಸ್ತುಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಸಂಪೂರ್ಣ ಬಿಡುಗಡೆಯು ಸರಿಯಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು, ಮೊದಲ ಬಾರಿಗೆ ಮತ್ತು ಕೇವಲ 10 ನಿಮಿಷಗಳಲ್ಲಿ. ದೋಷಗಳಿಗಾಗಿ ಲಾಗ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ನಾವು ಒಂದು ಗಂಟೆ ಕಳೆದಿದ್ದೇವೆ, ಆದರೆ ಯಾವುದೂ ಕಂಡುಬಂದಿಲ್ಲ.
ಮರುದಿನ ಸಂಪೂರ್ಣ ಬಿಡುಗಡೆ ಚಾಟ್‌ನಲ್ಲಿ ಮೌನವಿತ್ತು: ಯಾವುದೇ ಅನುಷ್ಠಾನ ಸಮಸ್ಯೆಗಳಿಲ್ಲ, ವಕ್ರ ಆವೃತ್ತಿಗಳು ಅಥವಾ "ಅನುಚಿತ" ಕೋಡ್. ಇದು ಹೇಗಾದರೂ ವಿಚಿತ್ರವಾಗಿತ್ತು. ನಂತರ, ಕೆಲವು ಕಾಮೆಂಟ್ಗಳು ಹೊರಹೊಮ್ಮಿದವು, ಆದರೆ ಇತರ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ಹಿಂದಿನ ಅನುಭವಕ್ಕೆ ಹೋಲಿಸಿದರೆ, ಅವುಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಆದ್ಯತೆಯು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ.
ಸಂಚಿತ ಪರಿಣಾಮದಿಂದ ಹೆಚ್ಚುವರಿ ಪರಿಣಾಮವೆಂದರೆ ಜೋಡಣೆ ಮತ್ತು ಪರೀಕ್ಷೆಯ ಗುಣಮಟ್ಟದಲ್ಲಿ ಹೆಚ್ಚಳ. ಪೂರ್ಣ ಬಿಡುಗಡೆಯ ಬಹು ಸ್ಥಾಪನೆಗಳ ಕಾರಣ, ಬಿಲ್ಡ್ ದೋಷಗಳು ಮತ್ತು ನಿಯೋಜನೆ ದೋಷಗಳನ್ನು ಸಮಯೋಚಿತವಾಗಿ ಗುರುತಿಸಲಾಗಿದೆ. ಪೂರ್ಣ ಬಿಡುಗಡೆಯ ಸಂರಚನೆಗಳಲ್ಲಿ ಪರೀಕ್ಷೆಯು ಹೆಚ್ಚುತ್ತಿರುವ ಅನುಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ ಕಂಡುಬರದ ವಸ್ತುಗಳ ಪರಸ್ಪರ ಪ್ರಭಾವದಲ್ಲಿನ ದೋಷಗಳನ್ನು ಹೆಚ್ಚುವರಿಯಾಗಿ ಗುರುತಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ಇದು ಖಂಡಿತವಾಗಿಯೂ ಯಶಸ್ವಿಯಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಬಿಡುಗಡೆಗೆ ನಮ್ಮ 57% ಕೊಡುಗೆಯನ್ನು ನೀಡಲಾಗಿದೆ.
ಫಲಿತಾಂಶಗಳು ಮತ್ತು ತೀರ್ಮಾನಗಳು
ಒಂದು ವರ್ಷದೊಳಗೆ ನಾವು ನಿರ್ವಹಿಸಿದ್ದೇವೆ:
- ವಿಲಕ್ಷಣ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಆಂತರಿಕ ಅಭಿವೃದ್ಧಿಯನ್ನು ನಿರ್ಮಿಸಿ;
- ನಿರ್ಣಾಯಕ ಮಾರಾಟಗಾರರ ಅವಲಂಬನೆಯನ್ನು ನಿವಾರಿಸಿ;
- ಅತ್ಯಂತ ಸ್ನೇಹಿಯಲ್ಲದ ಪರಂಪರೆಗಾಗಿ CI/CD ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ;
- ಹೊಸ ತಾಂತ್ರಿಕ ಮಟ್ಟಕ್ಕೆ ಅನುಷ್ಠಾನ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೆಚ್ಚಿಸಿ;
- ನಿಯೋಜನೆ ಸಮಯವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಿ;
- ಅನುಷ್ಠಾನ ದೋಷಗಳ ಸಂಖ್ಯೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಿ;
- ನಿಮ್ಮನ್ನು ಪ್ರಮುಖ ಅಭಿವೃದ್ಧಿ ತಜ್ಞರೆಂದು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಘೋಷಿಸಿಕೊಳ್ಳಿ.
ಸಹಜವಾಗಿ, ವಿವರಿಸಿದ ಹೆಚ್ಚಿನವುಗಳು ಸಂಪೂರ್ಣ ಅಮೇಧ್ಯದಂತೆ ತೋರುತ್ತಿವೆ, ಆದರೆ ಇವುಗಳು ಸಿಸ್ಟಮ್ನ ವೈಶಿಷ್ಟ್ಯಗಳು ಮತ್ತು ಅದರಲ್ಲಿ ಇರುವ ಪ್ರಕ್ರಿಯೆಯ ಮಿತಿಗಳಾಗಿವೆ. ಈ ಸಮಯದಲ್ಲಿ, ಬದಲಾವಣೆಗಳು IS ಪ್ರೊಫೈಲ್ ಉತ್ಪನ್ನಗಳು ಮತ್ತು ಸೇವೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಿವೆ (ಮಾಸ್ಟರ್ ಖಾತೆಗಳು, ಪ್ಲಾಸ್ಟಿಕ್ ಕಾರ್ಡ್‌ಗಳು, ಉಳಿತಾಯ ಖಾತೆಗಳು, ಎಸ್ಕ್ರೊ, ನಗದು ಸಾಲಗಳು), ಆದರೆ ಸಂಭಾವ್ಯವಾಗಿ ಈ ವಿಧಾನವನ್ನು DevOps ಅಭ್ಯಾಸಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಕಾರ್ಯವನ್ನು ಹೊಂದಿಸಿರುವ ಯಾವುದೇ IS ಗೆ ಅನ್ವಯಿಸಬಹುದು. ಸಂಚಿತ ಮಾದರಿಯನ್ನು ಅನೇಕ ವಿತರಣೆಗಳಿಂದ ನಂತರದ ಅಳವಡಿಕೆಗಳಿಗೆ (ಬಿಡುಗಡೆ ಮಾಡದವುಗಳನ್ನು ಒಳಗೊಂಡಂತೆ) ಸುರಕ್ಷಿತವಾಗಿ ಪುನರಾವರ್ತಿಸಬಹುದು.
ಮೂಲ: www.habr.com