ವರದಿಯು ಕೆಲವು DevOps ಅಭ್ಯಾಸಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತದೆ, ಆದರೆ ಡೆವಲಪರ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ. ವಿಶಿಷ್ಟವಾಗಿ, DevOps ಗೆ ಸೇರುವ ಎಲ್ಲಾ ಎಂಜಿನಿಯರ್‌ಗಳು ಈಗಾಗಲೇ ತಮ್ಮ ಬೆಲ್ಟ್ ಅಡಿಯಲ್ಲಿ ಹಲವಾರು ವರ್ಷಗಳ ಆಡಳಿತಾತ್ಮಕ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಆದರೆ ಇಲ್ಲಿ ಡೆವಲಪರ್‌ಗೆ ಸ್ಥಳವಿಲ್ಲ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ. ಹೆಚ್ಚಾಗಿ, ಡೆವಲಪರ್ಗಳು "ದಿನದ ಮುಂದಿನ ತುರ್ತಾಗಿ ನಿರ್ಣಾಯಕ ದೋಷವನ್ನು" ಸರಿಪಡಿಸುವಲ್ಲಿ ನಿರತರಾಗಿದ್ದಾರೆ ಮತ್ತು DevOps ಕ್ಷೇತ್ರವನ್ನು ತ್ವರಿತವಾಗಿ ನೋಡಲು ಅವರಿಗೆ ಸಮಯವಿಲ್ಲ. ಲೇಖಕರ ತಿಳುವಳಿಕೆಯಲ್ಲಿ, DevOps, ಮೊದಲನೆಯದಾಗಿ, ಸಾಮಾನ್ಯ ಅರ್ಥದಲ್ಲಿ. ಎರಡನೆಯದಾಗಿ, ಇದು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಲು ಒಂದು ಅವಕಾಶ. ನೀವು ಡೆವಲಪರ್ ಆಗಿದ್ದರೆ, ಸಾಮಾನ್ಯ ಜ್ಞಾನವನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ತಂಡದ ಆಟಗಾರನಾಗಿ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರಲು ಬಯಸಿದರೆ, ಈ ವರದಿಯು ನಿಮಗಾಗಿ ಆಗಿದೆ.
ನಾನು ನನ್ನನ್ನು ಪರಿಚಯಿಸುತ್ತೇನೆ, ಕೋಣೆಯಲ್ಲಿ ನನಗೆ ತಿಳಿದಿಲ್ಲದ ಜನರಿದ್ದಾರೆ ಎಂದು ನಾನು ಸಂಪೂರ್ಣವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳುತ್ತೇನೆ. ನನ್ನ ಹೆಸರು ಆಂಟನ್ ಬಾಯ್ಕೊ, ನಾನು ಮೈಕ್ರೋಸಾಫ್ಟ್ ಅಜುರೆ ಎಂವಿಪಿ. MVP ಎಂದರೇನು? ಇದು ಮಾಡೆಲ್-ವ್ಯೂ-ಪ್ರೆಸೆಂಟರ್ ಆಗಿದೆ. ಮಾಡೆಲ್-ವ್ಯೂ-ಪ್ರೆಸೆಂಟರ್ ನಿಖರವಾಗಿ ನಾನೇ.
ಜೊತೆಗೆ, ನಾನು ಪ್ರಸ್ತುತ ಸಿಕ್ಲಮ್‌ನಲ್ಲಿ ಪರಿಹಾರ ವಾಸ್ತುಶಿಲ್ಪಿ ಹುದ್ದೆಯನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಮತ್ತು ಇತ್ತೀಚೆಗೆ ನಾನು ಅಂತಹ ಸುಂದರವಾದ ಡೊಮೇನ್ ಅನ್ನು ಖರೀದಿಸಿದೆ ಮತ್ತು ನನ್ನ ಇಮೇಲ್ ಅನ್ನು ನಾನು ನವೀಕರಿಸಿದ್ದೇನೆ, ಅದನ್ನು ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಸ್ತುತಿಗಳಲ್ಲಿ ತೋರಿಸುತ್ತೇನೆ. ನೀವು ನನಗೆ ಇಲ್ಲಿ ಬರೆಯಬಹುದು: me [ನಾಯಿ] byokoant.pro. ನೀವು ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ನನಗೆ ಇಮೇಲ್ ಮಾಡಬಹುದು. ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಅವರಿಗೆ ಉತ್ತರಿಸುತ್ತೇನೆ. ಒಂದೇ ವಿಷಯವೆಂದರೆ ನಾನು ಇಮೇಲ್ ಮೂಲಕ ಎರಡು ವಿಷಯಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಶ್ನೆಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಇಷ್ಟಪಡುವುದಿಲ್ಲ: ರಾಜಕೀಯ ಮತ್ತು ಧರ್ಮ. ನೀವು ಇಮೇಲ್ ಮೂಲಕ ಎಲ್ಲದರ ಬಗ್ಗೆ ನನಗೆ ಬರೆಯಬಹುದು. ಸ್ವಲ್ಪ ಸಮಯ ಹೋಗುತ್ತದೆ, ನಾನು ಉತ್ತರಿಸುತ್ತೇನೆ.
ನಿಮ್ಮ ಬಗ್ಗೆ ಕೆಲವು ಮಾತುಗಳು:
- ನಾನು ಈ ಕ್ಷೇತ್ರದಲ್ಲಿ 10 ವರ್ಷಗಳಿಂದ ಇದ್ದೇನೆ.
- ನಾನು ಮೈಕ್ರೋಸಾಫ್ಟ್ ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ.
- ನಾನು 2014 ರಲ್ಲಿ ಎಲ್ಲೋ ಸ್ಥಾಪಿಸಿದ ಉಕ್ರೇನಿಯನ್ ಅಜುರೆ ಸಮುದಾಯದ ಸ್ಥಾಪಕ ಪಿತಾಮಹ. ಮತ್ತು ನಾವು ಇನ್ನೂ ಅದನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇವೆ.
- ನಾವು ಉಕ್ರೇನ್‌ನಲ್ಲಿ ಆಯೋಜಿಸುತ್ತಿರುವ ಅಜುರೆ ಸಮ್ಮೇಳನದ ಸಂಸ್ಥಾಪಕರ ತಂದೆಯೂ ನಾನು.
- ನಾನು ಕೈವ್‌ನಲ್ಲಿ ಗ್ಲೋಬಲ್ ಅಜುರೆ ಬೂಟ್‌ಕ್ಯಾಂಪ್ ಅನ್ನು ಸಂಘಟಿಸಲು ಸಹ ಸಹಾಯ ಮಾಡುತ್ತೇನೆ.
- ನಾನು ಹೇಳಿದಂತೆ, ನಾನು Microsoft Azure MVP.
- ನಾನು ಆಗಾಗ್ಗೆ ಸಮ್ಮೇಳನಗಳಲ್ಲಿ ಮಾತನಾಡುತ್ತೇನೆ. ನಾನು ಸಮ್ಮೇಳನಗಳಲ್ಲಿ ಮಾತನಾಡುವುದನ್ನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುತ್ತೇನೆ. ಕಳೆದ ವರ್ಷದಲ್ಲಿ ನಾನು ಸುಮಾರು 40 ಬಾರಿ ಪ್ರದರ್ಶನ ನೀಡಲು ಸಾಧ್ಯವಾಯಿತು. ನೀವು ಉಕ್ರೇನ್, ಬೆಲಾರಸ್, ಪೋಲೆಂಡ್, ಬಲ್ಗೇರಿಯಾ, ಸ್ವೀಡನ್, ಡೆನ್ಮಾರ್ಕ್, ನೆದರ್ಲ್ಯಾಂಡ್ಸ್, ಸ್ಪೇನ್ ಮೂಲಕ ಹಾದು ಹೋದರೆ ಅಥವಾ ಯುರೋಪ್ನಲ್ಲಿ ಬೇರೆ ದೇಶವನ್ನು ನೀಡಿದರೆ ಅಥವಾ ತೆಗೆದುಕೊಂಡರೆ, ನೀವು ಅದರ ಸ್ಟ್ರೀಮ್ನಲ್ಲಿ ಕ್ಲೌಡ್ ಥೀಮ್ ಹೊಂದಿರುವ ಸಮ್ಮೇಳನಕ್ಕೆ ಹೋದಾಗ ಅದು ಸಾಕಷ್ಟು ಸಾಧ್ಯ. ನೀವು ನನ್ನನ್ನು ಮಾತನಾಡುವವರ ಪಟ್ಟಿಯಲ್ಲಿ ನೋಡಬಹುದು.
- ನಾನು ಸಹ ಸ್ಟಾರ್ ಟ್ರೆಕ್ ಅಭಿಮಾನಿ.
ಅಜೆಂಡಾದ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಮಾತನಾಡೋಣ. ನಮ್ಮ ಕಾರ್ಯಸೂಚಿ ತುಂಬಾ ಸರಳವಾಗಿದೆ:
- DevOps ಎಂದರೇನು ಎಂಬುದರ ಕುರಿತು ನಾವು ಮಾತನಾಡುತ್ತೇವೆ. ಇದು ಏಕೆ ಮುಖ್ಯ ಎಂದು ಮಾತನಾಡೋಣ. ಹಿಂದೆ, DevOps ಎಂಬುದು ನಿಮ್ಮ ರೆಸ್ಯೂಮ್‌ನಲ್ಲಿ ನೀವು ಬರೆದ ಕೀವರ್ಡ್ ಆಗಿತ್ತು ಮತ್ತು ತಕ್ಷಣವೇ +$500 ಸಂಬಳವನ್ನು ಪಡೆದುಕೊಂಡಿದೆ. ಈಗ ನೀವು ಬರೆಯಬೇಕಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಸಂಬಳಕ್ಕೆ +500 ಡಾಲರ್‌ಗಳನ್ನು ಪಡೆಯಲು ನಿಮ್ಮ ರೆಸ್ಯೂಮ್‌ನಲ್ಲಿ ಬ್ಲಾಕ್‌ಚೈನ್.
- ತದನಂತರ, ಇದು ಏನು ಎಂಬುದರ ಕುರಿತು ನಾವು ಸ್ವಲ್ಪ ಅರ್ಥಮಾಡಿಕೊಂಡಾಗ, ನಾವು DevOps ಅಭ್ಯಾಸಗಳು ಯಾವುವು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತೇವೆ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ DevOps ಸಂದರ್ಭದಲ್ಲಿ ಹೆಚ್ಚು ಅಲ್ಲ, ಆದರೆ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಆಸಕ್ತಿಯಿರುವ ಆ DevOps ಅಭ್ಯಾಸಗಳ ಬಗ್ಗೆ. ಅವರು ನಿಮಗೆ ಏಕೆ ಆಸಕ್ತಿ ಹೊಂದಿರಬಹುದು ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. ನೀವು ಇದನ್ನು ಏಕೆ ಮಾಡಬೇಕು ಮತ್ತು ಕಡಿಮೆ ನೋವನ್ನು ಅನುಭವಿಸಲು ಇದು ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
ಅನೇಕ ಜನರು ತೋರಿಸುವ ಸಾಂಪ್ರದಾಯಿಕ ಚಿತ್ರ. ಅನೇಕ ಯೋಜನೆಗಳಲ್ಲಿ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ನಮ್ಮ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಬೆಂಬಲಿಸುವ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆ ವಿಭಾಗಗಳನ್ನು ನಾವು ಹೊಂದಿರುವಾಗ ಇದು. ಮತ್ತು ಈ ಇಲಾಖೆಗಳು ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುವುದಿಲ್ಲ.
ಬಹುಶಃ, DevOps ಮತ್ತು ಕಾರ್ಯಾಚರಣೆ ವಿಭಾಗಗಳಲ್ಲಿ ನೀವು ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಅನುಭವಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನೀವು Dev ಮತ್ತು QA ವಿಭಾಗಗಳೊಂದಿಗೆ ಸಾದೃಶ್ಯವನ್ನು ಸೆಳೆಯಬಹುದು. ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಜನರಿದ್ದಾರೆ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳ ದೃಷ್ಟಿಕೋನದಿಂದ ಕೆಟ್ಟ ಕ್ಯೂಎ ಜನರಿದ್ದಾರೆ. ಉದಾಹರಣೆಗೆ, ನಾನು ನನ್ನ ಅದ್ಭುತ ಕೋಡ್ ಅನ್ನು ರೆಪೊಸಿಟರಿಗೆ ಒಪ್ಪಿಸುತ್ತೇನೆ ಮತ್ತು ಅಲ್ಲಿ ಕುಳಿತಿರುವ ಕೆಲವು ದುಷ್ಟರು ಈ ಕೋಡ್ ಅನ್ನು ನನಗೆ ಹಿಂತಿರುಗಿಸುತ್ತಾರೆ ಮತ್ತು ನಿಮ್ಮ ಕೋಡ್ ಕೆಟ್ಟದಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತಾರೆ.
ಜನರು ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸದ ಕಾರಣ ಇದೆಲ್ಲವೂ ಸಂಭವಿಸುತ್ತದೆ. ಮತ್ತು ಅವರು ಕೆಲವು ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು, ಕೆಲವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಕೆಲವು ತಪ್ಪುಗ್ರಹಿಕೆಯ ಗೋಡೆಯ ಮೂಲಕ ಪರಸ್ಪರ ಎಸೆದು ಅವರೊಂದಿಗೆ ಏನನ್ನಾದರೂ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ.
ನಿಖರವಾಗಿ ಈ ಗೋಡೆಯೇ DevOps ಸಂಸ್ಕೃತಿಯನ್ನು ನಾಶಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಅಂದರೆ. ಜನರನ್ನು ಪರಸ್ಪರ ಸಂವಹನ ಮಾಡಲು ಒತ್ತಾಯಿಸಿ ಮತ್ತು ಯೋಜನೆಯಲ್ಲಿ ವಿಭಿನ್ನ ಜನರು ಏನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅವರ ಕೆಲಸ ಏಕೆ ಮುಖ್ಯ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ.
ಮತ್ತು ನಾವು DevOps ಕುರಿತು ಮಾತನಾಡುವಾಗ, ಯೋಜನೆಯು ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಹೊಂದಿರುವಾಗ DevOps ಎಂದು ಯಾರಾದರೂ ನಿಮಗೆ ತಿಳಿಸುತ್ತಾರೆ; ಯೋಜನೆಯು "ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ" ಅಭ್ಯಾಸವನ್ನು ಅಳವಡಿಸಿದರೆ DevOps ಎಂದು ಯಾರಾದರೂ ಹೇಳುತ್ತಾರೆ; DevOps ಗೆ ಮೊದಲ ಹಂತವೆಂದರೆ ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆ, ವೈಶಿಷ್ಟ್ಯ ಫ್ಲ್ಯಾಗ್‌ಗಳು ಎಂದು ಯಾರಾದರೂ ಹೇಳುತ್ತಾರೆ.
ಮೂಲಭೂತವಾಗಿ, ಇದೆಲ್ಲವೂ ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ ನಿಜವಾಗಿದೆ. ಆದರೆ ಇವು ನಮ್ಮಲ್ಲಿರುವ ಅಂತಿಮ ಅಭ್ಯಾಸಗಳು ಮಾತ್ರ. ಈ ಅಭ್ಯಾಸಗಳಿಗೆ ತೆರಳುವ ಮೊದಲು, ಈ ಸ್ಲೈಡ್ ಅನ್ನು ನೋಡಲು ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ, ಇದು ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ, ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಡೆವ್-ಆಪ್ಸ್ ವಿಧಾನವನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ 3 ಹಂತಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.
ಈ ಸ್ಲೈಡ್ ಎರಡನೇ ಅನಧಿಕೃತ ಹೆಸರನ್ನು ಸಹ ಹೊಂದಿದೆ. DevOps ನ 3 ಮಸ್ಕಿಟೀರ್‌ಗಳು ಏನೆಂದು ಕಂಡುಹಿಡಿಯಲು ನೀವು ಆನ್‌ಲೈನ್‌ನಲ್ಲಿ ಹುಡುಕಬಹುದು. ಈ ಲೇಖನವನ್ನು ನೀವು ಕಂಡುಕೊಳ್ಳುವ ಸಾಧ್ಯತೆಯಿದೆ. ಏಕೆ 3 ಮಸ್ಕಿಟೀರ್ಸ್? ಇದು ಕೆಳಗೆ ಹೇಳುತ್ತದೆ: ಜನರು, ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಉತ್ಪನ್ನಗಳು, ಅಂದರೆ. PPP - Porthos, Porthos ಮತ್ತು Porthos. DevOps ನ 3 ಮಸ್ಕಿಟೀರ್‌ಗಳು ಇಲ್ಲಿವೆ. ಈ ಲೇಖನವು ಏಕೆ ಮುಖ್ಯ ಮತ್ತು ಅದು ಏನನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಎಂಬುದನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸುತ್ತದೆ.
ನೀವು DevOps ಸಂಸ್ಕೃತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಅದನ್ನು ಈ ಕೆಳಗಿನ ಕ್ರಮದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಬಹಳ ಮುಖ್ಯ.
ಆರಂಭದಲ್ಲಿ ನೀವು ಜನರೊಂದಿಗೆ ಮಾತನಾಡಬೇಕು. ಮತ್ತು ಅದು ಏನು ಮತ್ತು ಅದರಿಂದ ಕೆಲವು ಪ್ರಯೋಜನಗಳನ್ನು ಹೇಗೆ ಪಡೆಯಬಹುದು ಎಂಬುದನ್ನು ನೀವು ಜನರಿಗೆ ವಿವರಿಸಬೇಕು.
ನಮ್ಮ ಸಮ್ಮೇಳನವನ್ನು ಡಾಟ್‌ನೆಟ್ ಫೆಸ್ಟ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಮತ್ತು ಸಂಘಟಕರು ನನಗೆ ಹೇಳಿದಂತೆ, ನಾವು ಮುಖ್ಯವಾಗಿ ಇಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳ ಪ್ರೇಕ್ಷಕರನ್ನು ಆಹ್ವಾನಿಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಸಭಾಂಗಣದಲ್ಲಿ ಹೆಚ್ಚಿನ ಜನರು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ನಾವು ಜನರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ, ಡೆವಲಪರ್ಗಳು ಪ್ರತಿದಿನ ಏನು ಮಾಡಲು ಬಯಸುತ್ತಾರೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಮಾತನಾಡುತ್ತೇವೆ. ಅವರು ಹೆಚ್ಚು ಏನು ಬಯಸುತ್ತಾರೆ? ಅವರು ಕೆಲವು ಹೊಸ ಕೋಡ್ ಅನ್ನು ಬರೆಯಲು ಬಯಸುತ್ತಾರೆ, ಹೊಸ ವಿಲಕ್ಷಣ ಚೌಕಟ್ಟುಗಳನ್ನು ಬಳಸಲು, ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ರಚಿಸಲು. ಅಭಿವರ್ಧಕರು ಕನಿಷ್ಠ ಏನು ಬಯಸುತ್ತಾರೆ? ಹಳೆಯ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಿ. ನೀವು ನನ್ನೊಂದಿಗೆ ಒಪ್ಪುತ್ತೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಅಭಿವರ್ಧಕರು ಬಯಸುವುದು ಇದನ್ನೇ. ಅವರು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬರೆಯಲು ಬಯಸುತ್ತಾರೆ, ಅವರು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಲು ಬಯಸುವುದಿಲ್ಲ.
ನಿರ್ದಿಷ್ಟ ಡೆವಲಪರ್ ಉತ್ಪಾದಿಸುವ ದೋಷಗಳ ಸಂಖ್ಯೆಯು ಅವನ ತೋಳುಗಳು ಎಷ್ಟು ನೇರವಾಗಿರುತ್ತವೆ ಮತ್ತು ಅವನ ಭುಜಗಳಿಂದ ಎಷ್ಟು ಬೆಳೆಯುತ್ತವೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು ಅವನ ಬಟ್ ಪಾಕೆಟ್ಸ್ನಿಂದ ಅಲ್ಲ. ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ, ನಾವು ದೊಡ್ಡ ಯೋಜನೆಯನ್ನು ಹೊಂದಿರುವಾಗ, ಎಲ್ಲವನ್ನೂ ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಅಸಾಧ್ಯವೆಂದು ಕೆಲವೊಮ್ಮೆ ಸಂಭವಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೆಚ್ಚು ಸ್ಥಿರ ಮತ್ತು ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಕೋಡ್ ಅನ್ನು ಬರೆಯಲು ನಮಗೆ ಸಹಾಯ ಮಾಡುವ ಕೆಲವು ವಿಧಾನಗಳನ್ನು ಬಳಸುವುದು ನಮಗೆ ಒಳ್ಳೆಯದು.
QA ಗಳು ಹೆಚ್ಚು ಏನು ಬಯಸುತ್ತವೆ? ಅವರು ಹಾಲ್‌ನಲ್ಲಿದ್ದರೆ ನನಗೆ ಗೊತ್ತಿಲ್ಲ. ನನಗೆ QA ಬೇಕು ಎಂದು ಹೇಳುವುದು ನನಗೆ ಕಷ್ಟ, ಏಕೆಂದರೆ ನಾನು ಎಂದಿಗೂ ಒಂದಾಗಿರಲಿಲ್ಲ. ಮತ್ತು ಹುಡುಗರಿಗೆ ಯಾವುದೇ ಅಪರಾಧವಿಲ್ಲ, ನಾನು ಎಂದಿಗೂ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಎಂದು ಹೇಳಲಾಗುತ್ತದೆ. ಆದರೆ ನಾನು ಅವರ ಕೆಲಸವನ್ನು ಅರ್ಥಹೀನ ಮತ್ತು ನಿಷ್ಪ್ರಯೋಜಕವೆಂದು ಪರಿಗಣಿಸುವ ಕಾರಣಕ್ಕಾಗಿ ಅಲ್ಲ, ಆದರೆ ನಾನು ಈ ಕೆಲಸವನ್ನು ಸಮರ್ಥವಾಗಿ ಮಾಡಬಲ್ಲ ವ್ಯಕ್ತಿ ಎಂದು ಪರಿಗಣಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ಅದನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ. ಆದರೆ ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, QA ಹೆಚ್ಚು ಇಷ್ಟಪಡದಿರುವುದು ಬೆಳಿಗ್ಗೆ ಕೆಲಸ ಮಾಡುವುದು, ನಿರಂತರವಾಗಿ ಕೆಲವು ರೀತಿಯ ರಿಗ್ರೆಷನ್ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವುದು, ಅವರು 3 ಸ್ಪ್ರಿಂಟ್‌ಗಳ ಹಿಂದೆ ಡೆವಲಪರ್‌ಗಳಿಗೆ ವರದಿ ಮಾಡಿದ ಅದೇ ದೋಷಗಳ ಮೇಲೆ ಹೆಜ್ಜೆ ಹಾಕುವುದು ಮತ್ತು ಹೇಳುವುದು: “ನೀವು ಯಾವಾಗ , ಮಾನ್ಸಿಯರ್ ಡಿ 'ಅರ್ಟಾಗ್ನಾನ್, ಈ ದೋಷವನ್ನು ಸರಿಪಡಿಸಿ.' ಮತ್ತು ಮಾನ್ಸಿಯರ್ ಡಿ'ಅರ್ಟಾಗ್ನಾನ್ ಅವರಿಗೆ ಉತ್ತರಿಸುತ್ತಾರೆ: "ಹೌದು, ಹೌದು, ಹೌದು, ನಾನು ಈಗಾಗಲೇ ಅದನ್ನು ಸರಿಪಡಿಸಿದ್ದೇನೆ." ಮತ್ತು ನಾನು ಒಂದು ದೋಷವನ್ನು ಸರಿಪಡಿಸಿದ್ದೇನೆ ಮತ್ತು ದಾರಿಯುದ್ದಕ್ಕೂ 5 ಅನ್ನು ಮಾಡಿದ್ದೇನೆ.
ಉತ್ಪಾದನೆಯಲ್ಲಿ ಈ ಪರಿಹಾರವನ್ನು ಬೆಂಬಲಿಸುವ ಜನರು ಈ ಪರಿಹಾರವು ದೋಷಗಳಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡಲು ಬಯಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಅವರು ಪ್ರತಿ ಶುಕ್ರವಾರ ಸರ್ವರ್ ಅನ್ನು ರೀಬೂಟ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ, ಎಲ್ಲಾ ಸಾಮಾನ್ಯ ಜನರು ಬಾರ್‌ಗೆ ಹೋದಾಗ. ಶುಕ್ರವಾರದಂದು ಡೆವಲಪರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲಾಗಿದೆ, ನಿರ್ವಾಹಕರು ಶನಿವಾರದವರೆಗೆ ಕುಳಿತು, ಈ ನಿಯೋಜನೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಮತ್ತು ಸರಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ.
ಮತ್ತು ಅವರು ಅದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಗುರಿಯನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂದು ನೀವು ಜನರಿಗೆ ವಿವರಿಸಿದಾಗ, ನೀವು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಔಪಚಾರಿಕಗೊಳಿಸಲು ಮುಂದುವರಿಯಬಹುದು. ಇದು ಅತೀ ಮುಖ್ಯವಾದುದು. ಏಕೆ? ಏಕೆಂದರೆ ನಾವು "ಔಪಚಾರಿಕಗೊಳಿಸುವಿಕೆ" ಎಂದು ಹೇಳಿದಾಗ, ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಗಳು ಕರವಸ್ತ್ರದ ಮೇಲೆ ಎಲ್ಲೋ ಹೇಗೆ ಸಂಭವಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ನಿಮಗೆ ಮುಖ್ಯವಾಗಿದೆ. ನೀವು, ಉದಾಹರಣೆಗೆ, QA ಪರಿಸರ ಅಥವಾ ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ನಿಯೋಜಿಸಿದರೆ, ಅದು ಯಾವಾಗಲೂ ಈ ಕ್ರಮದಲ್ಲಿ ನಡೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು; ಈ ಹಂತಗಳಲ್ಲಿ ನಾವು ನಡೆಸುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ, ಸ್ವಯಂಚಾಲಿತ ಘಟಕ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು UI ಪರೀಕ್ಷೆಗಳು. ನಿಯೋಜನೆಯ ನಂತರ, ನಿಯೋಜನೆಯು ಉತ್ತಮವಾಗಿ ಅಥವಾ ಕಳಪೆಯಾಗಿದೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಆದರೆ ನೀವು ಈಗಾಗಲೇ ಕ್ರಿಯೆಗಳ ಸ್ಪಷ್ಟ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದ್ದೀರಿ, ನೀವು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಿದಾಗ ಮತ್ತೆ ಮತ್ತೆ ಪುನರಾವರ್ತಿಸಬೇಕು.
ಮತ್ತು ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಔಪಚಾರಿಕಗೊಳಿಸಿದಾಗ ಮಾತ್ರ, ಈ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುವ ಉತ್ಪನ್ನಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ನೀವು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.
ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಹಿಮ್ಮುಖವಾಗಿ ಸಂಭವಿಸುವುದನ್ನು ನಾನು ಆಗಾಗ್ಗೆ ನೋಡುತ್ತೇನೆ. ಯಾರಾದರೂ "DevOps" ಪದವನ್ನು ಕೇಳಿದ ತಕ್ಷಣ, ಅವರು ತಕ್ಷಣ ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಸಲಹೆ ನೀಡುತ್ತಾರೆ, ಏಕೆಂದರೆ ಅವರು ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ ತಕ್ಷಣ, ಅವರು DevOps ಅನ್ನು ಹೊಂದಿರುತ್ತಾರೆ ಎಂದು ಅವರು ನಂಬುತ್ತಾರೆ. ಅವರು ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದರು, ಜೆಂಕಿನ್ಸ್ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ "ಹೇಗೆ" ಲೇಖನಗಳನ್ನು ಓದಿದರು, ಈ ಲೇಖನಗಳಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ತುಂಬಲು ಪ್ರಯತ್ನಿಸಿದರು ಮತ್ತು ನಂತರ ಜನರ ಬಳಿಗೆ ಬಂದು ಜನರನ್ನು ಬಾಗಿಸಿ, ನೀವು ಇದನ್ನು ಈ ರೀತಿ ಮಾಡಬೇಕೆಂದು ಪುಸ್ತಕವು ಹೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು ಇದನ್ನು ಈ ರೀತಿ ಮಾಡುತ್ತೇವೆ.
ಜೆಂಕಿನ್ಸ್ ಕೆಟ್ಟ ಸಾಧನ ಎಂದು ಅಲ್ಲ. ನಾನು ಅದನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಹೇಳಲು ಬಯಸುವುದಿಲ್ಲ. ಆದರೆ ಇದು ಉತ್ಪನ್ನಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಮತ್ತು ನೀವು ಯಾವ ಉತ್ಪನ್ನವನ್ನು ಬಳಸುತ್ತೀರಿ ಎಂಬುದು ನಿಮ್ಮ ಕೊನೆಯ ನಿರ್ಧಾರವಾಗಿರಬೇಕು ಮತ್ತು ನಿಮ್ಮ ಮೊದಲನೆಯದು. ನಿಮ್ಮ ಉತ್ಪನ್ನವು ಸಂಸ್ಕೃತಿ ಮತ್ತು ವಿಧಾನಗಳ ಅನುಷ್ಠಾನದಿಂದ ನಡೆಸಲ್ಪಡಬಾರದು. ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ, ಅದಕ್ಕಾಗಿಯೇ ನಾನು ಈ ಸ್ಲೈಡ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ಸಮಯವನ್ನು ಕಳೆಯುತ್ತೇನೆ ಮತ್ತು ಇಷ್ಟು ದಿನ ಎಲ್ಲವನ್ನೂ ವಿವರಿಸುತ್ತೇನೆ.
ಸಾಮಾನ್ಯವಾಗಿ DevOps ಅಭ್ಯಾಸಗಳ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ. ಅವು ಯಾವುವು? ವ್ಯತ್ಯಾಸವೇನು? ಅವುಗಳನ್ನು ಹೇಗೆ ಪ್ರಯತ್ನಿಸುವುದು? ಅವು ಏಕೆ ಮುಖ್ಯವಾಗಿವೆ?
ನೀವು ಕೇಳಿರಬಹುದಾದ ಮೊದಲ ಅಭ್ಯಾಸವನ್ನು ನಿರಂತರ ಏಕೀಕರಣ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಬಹುಶಃ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿರುವ ಯಾರಾದರೂ ನಿರಂತರ ಏಕೀಕರಣವನ್ನು (CI) ಹೊಂದಿರಬಹುದು.
ದೊಡ್ಡ ಸಮಸ್ಯೆ ಎಂದರೆ ನಾನು ಒಬ್ಬ ವ್ಯಕ್ತಿಯನ್ನು ಕೇಳಿದಾಗ: "ನೀವು ಯೋಜನೆಯಲ್ಲಿ CI ಹೊಂದಿದ್ದೀರಾ?" ಮತ್ತು ಅವರು ಹೇಳುತ್ತಾರೆ: "ಹೌದು," ನಂತರ ಅವನು ಏನು ಮಾಡುತ್ತಾನೆ ಎಂದು ನಾನು ಕೇಳಿದಾಗ, ಅವನು ನನಗೆ ಸಂಪೂರ್ಣ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿವರಿಸುತ್ತಾನೆ. ಇದು ಸಂಪೂರ್ಣ ಸತ್ಯವಲ್ಲ.
ವಾಸ್ತವವಾಗಿ, CI ಯ ಅಭ್ಯಾಸವು ವಿಭಿನ್ನ ಜನರು ಬರೆಯುವ ಕೋಡ್ ಅನ್ನು ಕೆಲವು ರೀತಿಯ ಏಕ ಕೋಡ್ ಬೇಸ್‌ಗೆ ಸಂಯೋಜಿಸುವ ಗುರಿಯನ್ನು ಹೊಂದಿದೆ. ಅಷ್ಟೇ.
CI ಜೊತೆಗೆ, ಸಾಮಾನ್ಯವಾಗಿ ಇತರ ಅಭ್ಯಾಸಗಳಿವೆ - ಉದಾಹರಣೆಗೆ ನಿರಂತರ ನಿಯೋಜನೆ, ಬಿಡುಗಡೆ ನಿರ್ವಹಣೆ, ಆದರೆ ನಾವು ಅದರ ಬಗ್ಗೆ ನಂತರ ಮಾತನಾಡುತ್ತೇವೆ.
ವಿಭಿನ್ನ ಜನರು ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಈ ಕೋಡ್ ಅನ್ನು ಒಂದೇ ಕೋಡ್ ಬೇಸ್ ಆಗಿ ನಿರಂತರವಾಗಿ ಸಂಯೋಜಿಸಬೇಕು ಎಂದು CI ಸ್ವತಃ ನಮಗೆ ಹೇಳುತ್ತದೆ.
ಇದು ನಮಗೆ ಏನು ನೀಡುತ್ತದೆ ಮತ್ತು ಅದು ಏಕೆ ಮುಖ್ಯವಾಗಿದೆ? ನಾವು ಡಾಟ್‌ನೆಟ್ ಹೊಂದಿದ್ದರೆ, ಅದು ಒಳ್ಳೆಯದು, ಇದು ಸಂಕಲಿಸಿದ ಭಾಷೆ, ನಾವು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡಬಹುದು. ಅದು ಕಂಪೈಲ್ ಮಾಡಿದರೆ, ಇದು ಈಗಾಗಲೇ ಒಳ್ಳೆಯ ಸಂಕೇತವಾಗಿದೆ. ಇದು ಇನ್ನೂ ಏನನ್ನೂ ಅರ್ಥವಲ್ಲ, ಆದರೆ ನಾವು ಕನಿಷ್ಟ ಕಂಪೈಲ್ ಮಾಡಬಹುದಾದ ಮೊದಲ ಉತ್ತಮ ಸಂಕೇತವಾಗಿದೆ.
ನಂತರ ನಾವು ಕೆಲವು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಬಹುದು, ಅದು ಪ್ರತ್ಯೇಕ ಅಭ್ಯಾಸವೂ ಆಗಿದೆ. ಪರೀಕ್ಷೆಗಳು ಎಲ್ಲಾ ಹಸಿರು - ಇದು ಎರಡನೇ ಉತ್ತಮ ಸಂಕೇತವಾಗಿದೆ. ಆದರೆ ಮತ್ತೆ, ಇದು ಏನನ್ನೂ ಅರ್ಥವಲ್ಲ.
ಆದರೆ ನೀವು ಇದನ್ನು ಏಕೆ ಮಾಡುತ್ತೀರಿ? ನಾನು ಇಂದು ಮಾತನಾಡುವ ಎಲ್ಲಾ ಅಭ್ಯಾಸಗಳು ಸರಿಸುಮಾರು ಒಂದೇ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿವೆ, ಅಂದರೆ ಸರಿಸುಮಾರು ಒಂದೇ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಸರಿಸುಮಾರು ಅದೇ ರೀತಿಯಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ.
ಮೊದಲನೆಯದಾಗಿ, ವಿತರಣೆಯನ್ನು ವೇಗಗೊಳಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ವಿತರಣೆಯನ್ನು ವೇಗಗೊಳಿಸಲು ಇದು ನಿಮಗೆ ಹೇಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ? ನಮ್ಮ ಕೋಡ್ ಬೇಸ್‌ಗೆ ನಾವು ಕೆಲವು ಹೊಸ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದಾಗ, ನಾವು ತಕ್ಷಣ ಈ ಕೋಡ್‌ನೊಂದಿಗೆ ಏನನ್ನಾದರೂ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಬಹುದು. ಗುರುವಾರ ಬರುವವರೆಗೆ ನಾವು ಕಾಯುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಗುರುವಾರ ನಾವು ಅದನ್ನು QA ಪರಿಸರಕ್ಕೆ ಬಿಡುಗಡೆ ಮಾಡುತ್ತೇವೆ, ನಾವು ಅದನ್ನು ಇಲ್ಲಿಯೇ ಮತ್ತು ಇಲ್ಲಿಯೇ ಮಾಡುತ್ತೇವೆ.
ನನ್ನ ಜೀವನದ ಒಂದು ದುಃಖದ ಕಥೆಯನ್ನು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. ಇದು ಬಹಳ ಹಿಂದೆ, ನಾನು ಇನ್ನೂ ಚಿಕ್ಕವನಾಗಿದ್ದ ಮತ್ತು ಸುಂದರವಾಗಿದ್ದಾಗ. ಈಗ ನಾನು ಈಗಾಗಲೇ ಯುವ, ಸುಂದರ ಮತ್ತು ಸ್ಮಾರ್ಟ್, ಮತ್ತು ಸಾಧಾರಣ. ಸ್ವಲ್ಪ ಸಮಯದ ಹಿಂದೆ ನಾನು ಯೋಜನೆಯಲ್ಲಿದ್ದೆ. ನಾವು ಸುಮಾರು 30 ಡೆವಲಪರ್‌ಗಳ ದೊಡ್ಡ ತಂಡವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಸುಮಾರು 10 ವರ್ಷಗಳ ಕಾಲ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ದೊಡ್ಡ, ದೊಡ್ಡ ಎಂಟರ್‌ಪ್ರೈಸ್ ಯೋಜನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ವಿವಿಧ ಶಾಖೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ನಾವು ಡೆವಲಪರ್ಗಳು ನಡೆದಾಡುವ ಶಾಖೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿರುವ ಕೋಡ್‌ನ ಆವೃತ್ತಿಯನ್ನು ಪ್ರದರ್ಶಿಸುವ ಒಂದು ಶಾಖೆ ಇತ್ತು.
ಉತ್ಪಾದನಾ ಶಾಖೆಯು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಲಭ್ಯವಿರುವ ಶಾಖೆಗಿಂತ 3 ತಿಂಗಳ ಹಿಂದೆ ಇತ್ತು. ಇದರ ಅರ್ಥ ಏನು? ಇದರರ್ಥ ಡೆವಲಪರ್‌ಗಳ ದೋಷದಿಂದಾಗಿ ನಾನು ಎಲ್ಲೋ ಒಂದು ದೋಷವನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಅವರು ಅದನ್ನು ಅನುಮತಿಸಿದ ಕಾರಣ ಮತ್ತು QA ಯ ದೋಷದಿಂದಾಗಿ, ಅವರು ಅದನ್ನು ನೋಡಿದ್ದರಿಂದ, ಇದರರ್ಥ ನಾನು ಸ್ವೀಕರಿಸಿದರೆ ಉತ್ಪಾದನೆಗಾಗಿ ಹಾಟ್‌ಫಿಕ್ಸ್‌ಗಾಗಿ ಕಾರ್ಯ, ನಂತರ ನಾನು 3 ತಿಂಗಳ ಹಿಂದೆ ನನ್ನ ಕೋಡ್ ಬದಲಾವಣೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು. ನಾನು 3 ತಿಂಗಳ ಹಿಂದೆ ಇದ್ದದ್ದನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಅದನ್ನು ಸರಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸಬೇಕು.
ನೀವು ಇನ್ನೂ ಈ ಅನುಭವವನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ ಹೋಮ್ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ನೀವು ಇದನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು. ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ, ಅದನ್ನು ವಾಣಿಜ್ಯಿಕವಾಗಿ ಪ್ರಯತ್ನಿಸಬೇಡಿ. ಕೋಡ್‌ನ ಒಂದೆರಡು ಸಾಲುಗಳನ್ನು ಬರೆಯಿರಿ, ಆರು ತಿಂಗಳವರೆಗೆ ಅವುಗಳನ್ನು ಮರೆತುಬಿಡಿ, ತದನಂತರ ಹಿಂತಿರುಗಿ ಮತ್ತು ಆ ಕೋಡ್‌ಗಳ ಸಾಲುಗಳು ಯಾವುವು ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸಬಹುದು ಅಥವಾ ಆಪ್ಟಿಮೈಜ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ತ್ವರಿತವಾಗಿ ವಿವರಿಸಲು ಪ್ರಯತ್ನಿಸಿ. ಇದು ತುಂಬಾ ತುಂಬಾ ರೋಮಾಂಚನಕಾರಿ ಅನುಭವ.
ನಾವು ನಿರಂತರ ಏಕೀಕರಣ ಅಭ್ಯಾಸವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಾನು ನನ್ನ ಕೋಡ್ ಅನ್ನು ಬರೆದ ತಕ್ಷಣ ಇಲ್ಲಿಯೇ ಮತ್ತು ಇದೀಗ ಹಲವಾರು ಸ್ವಯಂಚಾಲಿತ ಪರಿಕರಗಳೊಂದಿಗೆ ಅದನ್ನು ಪರಿಶೀಲಿಸಲು ಇದು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದು ನನಗೆ ಸಂಪೂರ್ಣ ಚಿತ್ರವನ್ನು ನೀಡದಿರಬಹುದು, ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ, ಇದು ಕನಿಷ್ಠ ಕೆಲವು ಅಪಾಯಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಮತ್ತು ಯಾವುದೇ ಸಂಭಾವ್ಯ ದೋಷವಿದ್ದರೆ, ನಾನು ಇದೀಗ ಅದರ ಬಗ್ಗೆ ತಿಳಿಯುತ್ತೇನೆ, ಅಂದರೆ, ಅಕ್ಷರಶಃ ಒಂದೆರಡು ನಿಮಿಷಗಳಲ್ಲಿ. ನಾನು 3 ತಿಂಗಳು ಹಿಂತಿರುಗುವ ಅಗತ್ಯವಿಲ್ಲ. ನಾನು ಕೇವಲ 2 ನಿಮಿಷಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕಾಗಿದೆ. ಉತ್ತಮ ಕಾಫಿ ಯಂತ್ರವು 2 ನಿಮಿಷಗಳಲ್ಲಿ ಕಾಫಿಯನ್ನು ತಯಾರಿಸಲು ಸಹ ಸಮಯವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದು ತುಂಬಾ ತಂಪಾಗಿದೆ.
ಇದು ಪ್ರತಿ ಯೋಜನೆಯಲ್ಲಿ ಸಮಯದ ನಂತರ ಪುನರಾವರ್ತಿಸಬಹುದಾದ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿದೆ, ಅಂದರೆ. ನೀವು ಅದನ್ನು ಸ್ಥಾಪಿಸಿದ ಮೇಲೆ ಮಾತ್ರವಲ್ಲ. ನೀವು ಅಭ್ಯಾಸವನ್ನು ಸ್ವತಃ ಪುನರಾವರ್ತಿಸಬಹುದು ಮತ್ತು ಯೋಜನೆಯಲ್ಲಿ ನೀವು ಮಾಡುವ ಪ್ರತಿಯೊಂದು ಹೊಸ ಬದಲಾವಣೆಗೆ CI ಸ್ವತಃ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ. ನಿಮ್ಮ ತಂಡವು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕಾರಣ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ನೀವು 3 ತಿಂಗಳ ಹಿಂದೆ ಕೆಲಸ ಮಾಡಿದ ಕೋಡ್‌ನಿಂದ ನಿಮಗೆ ದೋಷ ಬರುವ ಪರಿಸ್ಥಿತಿ ಇನ್ನು ಮುಂದೆ ಇರುವುದಿಲ್ಲ. ನೀವು ಕುಳಿತುಕೊಂಡು ಮೊದಲ ಎರಡು ಗಂಟೆಗಳ ಕಾಲ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ನೀವು ಏನನ್ನಾದರೂ ಸರಿಪಡಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಸಂದರ್ಭದ ಸಾರವನ್ನು ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸುವಾಗ ನೀವು ಇನ್ನು ಮುಂದೆ ಸಂದರ್ಭ ಬದಲಾವಣೆಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ.
ಈ ಅಭ್ಯಾಸದ ಯಶಸ್ಸು ಅಥವಾ ವೈಫಲ್ಯವನ್ನು ನಾವು ಹೇಗೆ ಅಳೆಯಬಹುದು? CI ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸಿರುವುದನ್ನು ನೀವು ಬಿಗ್ ಬಾಸ್‌ಗೆ ವರದಿ ಮಾಡಿದರೆ, ಅವರು ಬ್ಲಾ ಬ್ಲಾ ಬ್ಲಾ ಎಂದು ಕೇಳುತ್ತಾರೆ. ನಾವು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ, ಸರಿ, ಆದರೆ ಏಕೆ, ಅದು ನಮಗೆ ಏನು ತಂದಿತು, ನಾವು ಅದನ್ನು ಹೇಗೆ ಅಳೆಯುತ್ತೇವೆ, ನಾವು ಅದನ್ನು ಎಷ್ಟು ಸರಿಯಾಗಿ ಅಥವಾ ತಪ್ಪಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿದ್ದೇವೆ?
ಮೊದಲನೆಯದು, CI ಗೆ ಧನ್ಯವಾದಗಳು, ನಾವು ಹೆಚ್ಚು ಹೆಚ್ಚು ಬಾರಿ ನಿಯೋಜಿಸಬಹುದು, ಮತ್ತು ಹೆಚ್ಚಾಗಿ ನಿಖರವಾಗಿ ಏಕೆಂದರೆ ನಮ್ಮ ಕೋಡ್ ಸಮರ್ಥವಾಗಿ ಹೆಚ್ಚು ಸ್ಥಿರವಾಗಿರುತ್ತದೆ. ಅದೇ ರೀತಿಯಲ್ಲಿ, ದೋಷವನ್ನು ಕಂಡುಹಿಡಿಯುವ ನಮ್ಮ ಸಮಯವು ಕಡಿಮೆಯಾಗುತ್ತದೆ ಮತ್ತು ಈ ದೋಷವನ್ನು ಸರಿಪಡಿಸುವ ಸಮಯವು ನಿಖರವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ ಏಕೆಂದರೆ ನಾವು ಇಲ್ಲಿಯೇ ಮತ್ತು ಇದೀಗ ಸಿಸ್ಟಮ್‌ನಿಂದ ಉತ್ತರವನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ, ನಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ಏನು ತಪ್ಪಾಗಿದೆ.
ನಾವು ಹೊಂದಿರುವ ಮತ್ತೊಂದು ಅಭ್ಯಾಸವೆಂದರೆ ಆಟೋಮೇಷನ್ ಟೆಸ್ಟಿಂಗ್ ಅಭ್ಯಾಸ, ಇದು ಹೆಚ್ಚಾಗಿ CI ಅಭ್ಯಾಸದೊಂದಿಗೆ ಬರುತ್ತದೆ. ಅವರು ಕೈಯಲ್ಲಿ ಹೋಗುತ್ತಾರೆ.
ಇಲ್ಲಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮುಖ್ಯವಾದುದು ಏನು? ನಮ್ಮ ಪರೀಕ್ಷೆಗಳು ವಿಭಿನ್ನವಾಗಿವೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ. ಮತ್ತು ಪ್ರತಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯು ತನ್ನದೇ ಆದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಗುರಿಯನ್ನು ಹೊಂದಿದೆ. ನಾವು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಲು ಅನುಮತಿಸುವ ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ, ಅಂದರೆ. ನಿರ್ವಾತದಲ್ಲಿ ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ? ಇದು ಒಳ್ಳೆಯದಿದೆ.
ನಾವು ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದು ವಿಭಿನ್ನ ಮಾಡ್ಯೂಲ್‌ಗಳು ಪರಸ್ಪರ ಹೇಗೆ ಸಂಯೋಜಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದು ಕೂಡ ಒಳ್ಳೆಯದು.
ನಾವು UI ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿರಬಹುದು, ಅದು UI ಯೊಂದಿಗಿನ ಕೆಲಸವು ಗ್ರಾಹಕರು ನಿಗದಿಪಡಿಸಿದ ಕೆಲವು ಅವಶ್ಯಕತೆಗಳನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಪೂರೈಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಲು ನಮಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ.
ನೀವು ನಡೆಸುವ ನಿರ್ದಿಷ್ಟ ಪರೀಕ್ಷೆಗಳು ನೀವು ಎಷ್ಟು ಬಾರಿ ಓಡುತ್ತೀರಿ ಎಂಬುದರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು. ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಚಿಕ್ಕದಾಗಿ ಮತ್ತು ಚಿಕ್ಕದಾಗಿ ಬರೆಯಲಾಗುತ್ತದೆ. ಮತ್ತು ಅವುಗಳನ್ನು ನಿಯಮಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಬಹುದು.
ನಾವು UI ಆಟೊಮೇಷನ್ ಪರೀಕ್ಷೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಚಿಕ್ಕದಾಗಿದ್ದರೆ ಒಳ್ಳೆಯದು. ನಿಮ್ಮ UI ಆಟೊಮೇಷನ್ ಪರೀಕ್ಷೆಗಳು ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ UI ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪರೀಕ್ಷೆಯು ದೊಡ್ಡ ಯೋಜನೆಯಲ್ಲಿ ಹಲವಾರು ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತು ಇದು ಕೆಲವು ಗಂಟೆಗಳಿದ್ದರೆ ಒಳ್ಳೆಯದು. ಒಂದೇ ವಿಷಯವೆಂದರೆ ಪ್ರತಿ ನಿರ್ಮಾಣಕ್ಕೂ ಅವುಗಳನ್ನು ಚಲಾಯಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ರಾತ್ರಿಯಲ್ಲಿ ಅವುಗಳನ್ನು ಚಲಾಯಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಮತ್ತು ಎಲ್ಲರೂ ಬೆಳಿಗ್ಗೆ ಕೆಲಸಕ್ಕೆ ಬಂದಾಗ: ಪರೀಕ್ಷಕರು ಮತ್ತು ಡೆವಲಪರ್ಗಳು ಇಬ್ಬರೂ, ನಾವು ರಾತ್ರಿಯಲ್ಲಿ UI ಸ್ವಯಂ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದ್ದೇವೆ ಮತ್ತು ಈ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ ಎಂದು ಅವರು ಕೆಲವು ರೀತಿಯ ವರದಿಯನ್ನು ಸ್ವೀಕರಿಸಿದರು. ಮತ್ತು ಇಲ್ಲಿ, ನಿಮ್ಮ ಉತ್ಪನ್ನವು ಕೆಲವು ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವ ಸರ್ವರ್‌ನ ಒಂದು ಗಂಟೆಯ ಕೆಲಸವು ಅದೇ QA ಇಂಜಿನಿಯರ್‌ನ ಒಂದು ಗಂಟೆಯ ಕೆಲಸಕ್ಕಿಂತ ಅಗ್ಗವಾಗಿರುತ್ತದೆ, ಅವನು ಆಹಾರಕ್ಕಾಗಿ ಮತ್ತು ಧನ್ಯವಾದಗಳಿಗಾಗಿ ಕೆಲಸ ಮಾಡುವ ಜೂನಿಯರ್ QA ಇಂಜಿನಿಯರ್ ಆಗಿದ್ದರೂ ಸಹ. ಒಂದೇ ಒಂದು ಗಂಟೆಯ ಯಂತ್ರದ ಕಾರ್ಯಾಚರಣೆಯು ಅಗ್ಗವಾಗಲಿದೆ. ಅದಕ್ಕಾಗಿಯೇ ಅದರಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ.
ನಾನು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಇನ್ನೊಂದು ಯೋಜನೆ ಇದೆ. ಈ ಯೋಜನೆಯಲ್ಲಿ ನಾವು ಎರಡು ವಾರಗಳ ಸ್ಪ್ರಿಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಯೋಜನೆಯು ದೊಡ್ಡದಾಗಿದೆ, ಹಣಕಾಸು ಕ್ಷೇತ್ರಕ್ಕೆ ಮುಖ್ಯವಾಗಿದೆ ಮತ್ತು ತಪ್ಪು ಮಾಡಲಾಗಲಿಲ್ಲ. ಮತ್ತು ಎರಡು ವಾರಗಳ ಸ್ಪ್ರಿಂಟ್ ನಂತರ, ಅಭಿವೃದ್ಧಿ ಚಕ್ರವನ್ನು ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಅನುಸರಿಸಲಾಯಿತು, ಇದು ಇನ್ನೊಂದು 4 ವಾರಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ದುರಂತದ ಪ್ರಮಾಣವನ್ನು ಊಹಿಸಲು ಪ್ರಯತ್ನಿಸಿ. ನಾವು ಎರಡು ವಾರಗಳವರೆಗೆ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತೇವೆ, ನಂತರ ನಾವು ಅದನ್ನು ಅಲಾ ಕೋಡ್‌ಫ್ರೀಜ್ ಮಾಡುತ್ತೇವೆ, ಅದನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗೆ ಪ್ಯಾಕೇಜ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಪರೀಕ್ಷಕರಿಗೆ ರೋಲ್ ಮಾಡುತ್ತೇವೆ. ಪರೀಕ್ಷಕರು ಅದನ್ನು ಇನ್ನೊಂದು 4 ವಾರಗಳವರೆಗೆ ಪರೀಕ್ಷಿಸುತ್ತಾರೆ, ಅಂದರೆ. ಅವರು ಅದನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿರುವಾಗ, ಅವರಿಗೆ ಇನ್ನೂ ಎರಡು ಆವೃತ್ತಿಗಳನ್ನು ತಯಾರಿಸಲು ನಮಗೆ ಸಮಯವಿದೆ. ಇದು ನಿಜಕ್ಕೂ ದುಃಖದ ಪ್ರಕರಣ.
ಮತ್ತು ನೀವು ಹೆಚ್ಚು ಉತ್ಪಾದಕರಾಗಲು ಬಯಸಿದರೆ, ನೀವು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷಾ ಅಭ್ಯಾಸಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ ಎಂದು ನಾವು ಅವರಿಗೆ ಹೇಳಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಇದು ಇದೀಗ ಇಲ್ಲಿಯೇ ನಿಮಗೆ ನೋವುಂಟು ಮಾಡುತ್ತದೆ.
ನಿರಂತರ ನಿಯೋಜನೆಯನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿ. ಅದ್ಭುತವಾಗಿದೆ, ನೀವು ನಿರ್ಮಿಸಿದ್ದೀರಿ. ಇದು ಈಗಾಗಲೇ ಒಳ್ಳೆಯದು. ನಿಮ್ಮ ಕೋಡ್ ಕಂಪೈಲ್ ಮಾಡಲಾಗಿದೆ. ಈಗ ಈ ನಿರ್ಮಾಣವನ್ನು ಕೆಲವು ಪರಿಸರದಲ್ಲಿ ನಿಯೋಜಿಸಲು ಒಳ್ಳೆಯದು. ಡೆವಲಪರ್‌ಗಳಿಗೆ ಪರಿಸರದಲ್ಲಿ ಹೇಳೋಣ.
ಇದು ಏಕೆ ಮುಖ್ಯ? ಮೊದಲಿಗೆ, ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನೀವು ಎಷ್ಟು ಯಶಸ್ವಿಯಾಗಿದ್ದೀರಿ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು. ನಾನು ಈ ರೀತಿಯ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಭೇಟಿ ಮಾಡಿದ್ದೇನೆ, ನಾನು ಕೇಳಿದಾಗ: “ನೀವು ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಹೇಗೆ ನಿಯೋಜಿಸುತ್ತೀರಿ?”, ಹುಡುಗರು ನನಗೆ ಹೇಳುತ್ತಾರೆ: “ನಾವು ಅದನ್ನು ಜೋಡಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಜಿಪ್ ಆರ್ಕೈವ್‌ಗೆ ಪ್ಯಾಕ್ ಮಾಡುತ್ತೇವೆ. ನಾವು ಅದನ್ನು ಮೇಲ್ ಮೂಲಕ ನಿರ್ವಾಹಕರಿಗೆ ಕಳುಹಿಸುತ್ತೇವೆ. ನಿರ್ವಾಹಕರು ಈ ಆರ್ಕೈವ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ವಿಸ್ತರಿಸುತ್ತಾರೆ. ಮತ್ತು ಇಡೀ ಕಚೇರಿಯು ಸರ್ವರ್ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುವಂತೆ ಪ್ರಾರ್ಥಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
ಸರಳವಾದ ಯಾವುದನ್ನಾದರೂ ಪ್ರಾರಂಭಿಸೋಣ. ಉದಾಹರಣೆಗೆ, ಅವರು ಆರ್ಕೈವ್‌ನಲ್ಲಿ CSS ಅನ್ನು ಹಾಕಲು ಮರೆತಿದ್ದಾರೆ ಅಥವಾ ಜಾವಾ-ಸ್ಕ್ರಿಪ್ಟ್ ಫೈಲ್ ಹೆಸರಿನಲ್ಲಿ ಹ್ಯಾಶ್‌ಟ್ಯಾಗ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ಮರೆತಿದ್ದಾರೆ. ಮತ್ತು ನಾವು ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡಿದಾಗ, ಬ್ರೌಸರ್ ಈಗಾಗಲೇ ಈ ಜಾವಾ-ಸ್ಕ್ರಿಪ್ಟ್ ಫೈಲ್ ಅನ್ನು ಹೊಂದಿದೆ ಎಂದು ಭಾವಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡದಿರಲು ನಿರ್ಧರಿಸುತ್ತದೆ. ಮತ್ತು ಹಳೆಯ ಆವೃತ್ತಿ ಇತ್ತು, ಏನೋ ಕಾಣೆಯಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಅನೇಕ ಸಮಸ್ಯೆಗಳಿರಬಹುದು. ಆದ್ದರಿಂದ, ನಿರಂತರ ನಿಯೋಜನೆಯ ಅಭ್ಯಾಸವು ನೀವು ಒಂದು ಕ್ಲೀನ್ ರೆಫರೆನ್ಸ್ ಇಮೇಜ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಚ್ಛವಾದ ಹೊಸ ಪರಿಸರಕ್ಕೆ ಅಪ್ಲೋಡ್ ಮಾಡಿದರೆ ಏನಾಗಬಹುದು ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದು ಎಲ್ಲಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು.
ಅಲ್ಲದೆ, ನೀವು ಪರಸ್ಪರ ನಡುವೆ ಕೋಡ್ ಅನ್ನು ಸಂಯೋಜಿಸಿದಾಗ, ಅಂದರೆ. ಆಜ್ಞೆಯ ನಡುವೆ, ಇದು UI ನಲ್ಲಿ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಬಹಳಷ್ಟು ವೆನಿಲ್ಲಾ ಜಾವಾ-ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬಳಸುವಾಗ ಸಂಭವಿಸುವ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದಾದ ಎರಡು ಡೆವಲಪರ್ಗಳು ವಿಂಡೋ ಆಬ್ಜೆಕ್ಟ್‌ನಲ್ಲಿ ಒಂದೇ ಹೆಸರಿನೊಂದಿಗೆ ವೇರಿಯೇಬಲ್ ಅನ್ನು ದುಡುಕಿನ ರೀತಿಯಲ್ಲಿ ಘೋಷಿಸಿದ್ದಾರೆ. ತದನಂತರ, ನಿಮ್ಮ ಅದೃಷ್ಟವನ್ನು ಅವಲಂಬಿಸಿ. ಯಾರ ಜಾವಾ-ಸ್ಕ್ರಿಪ್ಟ್ ಫೈಲ್ ಅನ್ನು ಎರಡನೆಯದಾಗಿ ಹೊರತೆಗೆದರೆ ಇತರ ಬದಲಾವಣೆಗಳನ್ನು ಓವರ್‌ರೈಟ್ ಮಾಡುತ್ತದೆ. ಇದು ತುಂಬಾ ರೋಚಕವೂ ಆಗಿದೆ. ನೀವು ಒಳಗೆ ಬನ್ನಿ: ಒಂದು ವಿಷಯ ಒಬ್ಬ ವ್ಯಕ್ತಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಇನ್ನೊಂದು ಇನ್ನೊಬ್ಬರಿಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಮತ್ತು ಇದು ಎಲ್ಲಾ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಹೊರಬಂದಾಗ "ಅದ್ಭುತ".
ನಾವು ಹೊಂದಿರುವ ಮುಂದಿನ ಅಭ್ಯಾಸವೆಂದರೆ ಸ್ವಯಂಚಾಲಿತ ಮರುಸ್ಥಾಪನೆಯ ಅಭ್ಯಾಸ, ಅವುಗಳೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗುವುದು.
ಡೆವಲಪರ್‌ಗಳಿಗೆ ಇದು ಏಕೆ ಮುಖ್ಯವಾಗಿದೆ? ಕಂಪ್ಯೂಟರ್‌ಗಳು ದೊಡ್ಡದಾಗಿದ್ದ ಮತ್ತು ಪ್ರೋಗ್ರಾಂಗಳು ಚಿಕ್ಕದಾಗಿದ್ದ ದೂರದ, ದೂರದ 90 ರ ದಶಕವನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುವವರು ಇನ್ನೂ ಇದ್ದಾರೆ. ಮತ್ತು ವೆಬ್ ಅಭಿವೃದ್ಧಿಗೆ ಏಕೈಕ ಮಾರ್ಗವೆಂದರೆ PHP ಮೂಲಕ. PHP ಕೆಟ್ಟ ಭಾಷೆ ಎಂದು ಅಲ್ಲ, ಆದರೂ.
ಆದರೆ ಸಮಸ್ಯೆ ಬೇರೆಯೇ ಆಗಿತ್ತು. ನಮ್ಮ php ಸೈಟ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ನಾವು ನಿಯೋಜಿಸಿದಾಗ, ನಾವು ಅದನ್ನು ಹೇಗೆ ನಿಯೋಜಿಸಿದ್ದೇವೆ? ಹೆಚ್ಚಾಗಿ ನಾವು ಫಾರ್ ಮ್ಯಾನೇಜರ್ ಅಥವಾ ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ತೆರೆಯುತ್ತೇವೆ. ಮತ್ತು ಈ ಫೈಲ್‌ಗಳನ್ನು FTP ಗೆ ಅಪ್ಲೋಡ್ ಮಾಡಲಾಗಿದೆ. ಮತ್ತು ನಾವು ಕೆಲವು ಸಣ್ಣ, ಸಣ್ಣ ದೋಷವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನಾವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅರಿತುಕೊಂಡಿದ್ದೇವೆ, ಉದಾಹರಣೆಗೆ, ನಾವು ಸೆಮಿಕೋಲನ್ ಅನ್ನು ಹಾಕಲು ಮರೆತಿದ್ದೇವೆ ಅಥವಾ ಡೇಟಾಬೇಸ್ಗಾಗಿ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ಮರೆತಿದ್ದೇವೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ಗಾಗಿ ಪಾಸ್ವರ್ಡ್ ಇದೆ, ಅದು ಸ್ಥಳೀಯ ಹೋಸ್ಟ್ನಲ್ಲಿದೆ. ಮತ್ತು ನಾವು ತ್ವರಿತವಾಗಿ FTP ಗೆ ಸಂಪರ್ಕಿಸಲು ಮತ್ತು ಫೈಲ್‌ಗಳನ್ನು ಅಲ್ಲಿಯೇ ಸಂಪಾದಿಸಲು ನಿರ್ಧರಿಸುತ್ತೇವೆ. ಇದು ಕೇವಲ ಬೆಂಕಿ! ಇದು 90 ರ ದಶಕದಲ್ಲಿ ಜನಪ್ರಿಯವಾಗಿತ್ತು.
ಆದರೆ, ನೀವು ಕ್ಯಾಲೆಂಡರ್ ಅನ್ನು ನೋಡದಿದ್ದರೆ, 90 ರ ದಶಕವು ಸುಮಾರು 30 ವರ್ಷಗಳ ಹಿಂದಿನದು. ಈಗ ಎಲ್ಲವೂ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ನಡೆಯುತ್ತಿದೆ. ಮತ್ತು ಅವರು ನಿಮಗೆ ಹೇಳಿದಾಗ ದುರಂತದ ಪ್ರಮಾಣವನ್ನು ಊಹಿಸಲು ಪ್ರಯತ್ನಿಸಿ: "ನಾವು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಿದ್ದೇವೆ, ಆದರೆ ಅಲ್ಲಿ ಏನೋ ತಪ್ಪಾಗಿದೆ. ನಿಮ್ಮ FTP ಲಾಗಿನ್ ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಇಲ್ಲಿದೆ, ಉತ್ಪಾದನೆಗೆ ಸಂಪರ್ಕಪಡಿಸಿ ಮತ್ತು ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಸರಿಪಡಿಸಿ. ನೀವು ಚಕ್ ನಾರ್ರಿಸ್ ಆಗಿದ್ದರೆ, ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಒಂದು ದೋಷವನ್ನು ಸರಿಪಡಿಸಿದರೆ, ನೀವು ಇನ್ನೂ 10 ಅನ್ನು ಮಾಡುವ ಅಪಾಯವಿದೆ. ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗುವ ಈ ಅಭ್ಯಾಸವು ನಿಮಗೆ ಬಹಳಷ್ಟು ಸಾಧಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಏನಾದರೂ ಕೆಟ್ಟದ್ದನ್ನು ಹೇಗಾದರೂ ಎಲ್ಲೋ ಪ್ರಾಡಕ್ಟ್ ಮಾಡಿದರೂ, ಅದು ಕೆಟ್ಟದು, ಆದರೆ ಮಾರಕವಲ್ಲ. ನೀವು ಹೊಂದಿರುವ ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ನೀವು ಹಿಂತಿರುಗಬಹುದು. ಆ ಪರಿಭಾಷೆಯಲ್ಲಿ ಅದನ್ನು ಗ್ರಹಿಸಲು ಸುಲಭವಾಗಿದ್ದರೆ ಅದನ್ನು ಬ್ಯಾಕಪ್ ಎಂದು ಕರೆಯಿರಿ. ನೀವು ಈ ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗಬಹುದು, ಮತ್ತು ಬಳಕೆದಾರರು ಇನ್ನೂ ನಿಮ್ಮ ಉತ್ಪನ್ನದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ನೀವು ಸಾಕಷ್ಟು ಬಫರ್ ಸಮಯವನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ನೀವು ಶಾಂತವಾಗಿ, ಆತುರವಿಲ್ಲದೆ, ಇದೆಲ್ಲವನ್ನೂ ತೆಗೆದುಕೊಂಡು ಸ್ಥಳೀಯವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ಸರಿಪಡಿಸಿ, ತದನಂತರ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಬಹುದು. ಇದನ್ನು ಮಾಡಲು ನಿಜವಾಗಿಯೂ ಅರ್ಥವಿದೆ.
ಈಗ ಹಿಂದಿನ ಎರಡು ಅಭ್ಯಾಸಗಳನ್ನು ಹೇಗಾದರೂ ಸಂಯೋಜಿಸಲು ಪ್ರಯತ್ನಿಸೋಣ. ನಾವು ಬಿಡುಗಡೆ ನಿರ್ವಹಣೆ ಎಂಬ ಮೂರನೆಯದನ್ನು ಪಡೆಯುತ್ತೇವೆ.
ನಾವು ಅದರ ಶಾಸ್ತ್ರೀಯ ರೂಪದಲ್ಲಿ ನಿರಂತರ ನಿಯೋಜನೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ನಾವು ರೆಪೊಸಿಟರಿಯಿಂದ ಕೆಲವು ಶಾಖೆಯಿಂದ ಕೋಡ್ ಅನ್ನು ಎಳೆಯಬೇಕು, ಅದನ್ನು ಕಂಪೈಲ್ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ನಿಯೋಜಿಸಬೇಕು ಎಂದು ನಾವು ಹೇಳುತ್ತೇವೆ. ನಮ್ಮಲ್ಲೂ ಅದೇ ವಾತಾವರಣ ಇದ್ದರೆ ಒಳ್ಳೆಯದು. ನಾವು ಹಲವಾರು ಪರಿಸರಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಇದರರ್ಥ ನಾವು ಪ್ರತಿ ಬಾರಿಯೂ ಒಂದೇ ಬದ್ಧತೆಯಿಂದಲೂ ಕೋಡ್ ಅನ್ನು ಎಳೆಯಬೇಕು. ನಾವು ಅದನ್ನು ಪ್ರತಿ ಬಾರಿ ಹೊರತೆಗೆಯುತ್ತೇವೆ, ಪ್ರತಿ ಬಾರಿಯೂ ನಾವು ಅದನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಹೊಸ ಪರಿಸರಕ್ಕೆ ನಿಯೋಜಿಸುತ್ತೇವೆ. ಮೊದಲನೆಯದಾಗಿ, ಇದು ಸಮಯ, ಏಕೆಂದರೆ ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸಲು, ನೀವು ದೊಡ್ಡದನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು 90 ರ ದಶಕದಿಂದ ಬಂದಿದ್ದರೆ, ಅದು ಹಲವಾರು ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು.
ಜೊತೆಗೆ ಇನ್ನೊಂದು ದುಃಖವೂ ಇದೆ. ನೀವು ನಿರ್ಮಿಸಿದಾಗ, ಅದೇ ಯಂತ್ರದಲ್ಲಿ ಸಹ, ನೀವು ಅದೇ ಮೂಲಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೀರಿ, ಈ ಯಂತ್ರವು ಕೊನೆಯ ನಿರ್ಮಾಣದ ಸಮಯದಲ್ಲಿ ಅದೇ ಸ್ಥಿತಿಯಲ್ಲಿದೆ ಎಂದು ನಿಮಗೆ ಇನ್ನೂ ಯಾವುದೇ ಗ್ಯಾರಂಟಿ ಇಲ್ಲ.
ಯಾರಾದರೂ ಬಂದು ನಿಮಗಾಗಿ ಡಾಟ್‌ನೆಟ್ ಅನ್ನು ನವೀಕರಿಸಿದ್ದಾರೆ ಎಂದು ಹೇಳೋಣ ಅಥವಾ ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಯಾರಾದರೂ ಏನನ್ನಾದರೂ ಅಳಿಸಲು ನಿರ್ಧರಿಸಿದ್ದಾರೆ. ಮತ್ತು ಎರಡು ವಾರಗಳ ಹಿಂದೆ ಈ ಕಮಿಟ್‌ನಿಂದ ನಾವು ನಿರ್ಮಾಣವನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂದು ನಿಮಗೆ ಅರಿವಿನ ಅಪಶ್ರುತಿ ಇದೆ, ಆದರೆ ಈಗ ನಾವು ನಿರ್ಮಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಅದೇ ಯಂತ್ರ, ಅದೇ ಬದ್ಧತೆ, ಅದೇ ಕೋಡ್‌ನಂತೆ ತೋರುತ್ತದೆ, ಆದರೆ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ . ನೀವು ಇದನ್ನು ದೀರ್ಘಕಾಲ ವ್ಯವಹರಿಸುತ್ತೀರಿ ಮತ್ತು ನೀವು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೀರಿ ಎಂಬುದು ಸತ್ಯವಲ್ಲ. ಕನಿಷ್ಠ, ನೀವು ನಿಮ್ಮ ನರಗಳನ್ನು ಬಹಳಷ್ಟು ಹಾಳುಮಾಡುತ್ತೀರಿ.
ಆದ್ದರಿಂದ, ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ರೆಪೊಸಿಟರಿ ಅಥವಾ ಗ್ಯಾಲರಿ ಅಥವಾ ಲೈಬ್ರರಿ ಎಂಬ ಹೆಚ್ಚುವರಿ ಅಮೂರ್ತತೆಯನ್ನು ಪರಿಚಯಿಸಲು ಬಿಡುಗಡೆ ನಿರ್ವಹಣೆ ಅಭ್ಯಾಸವು ಸೂಚಿಸುತ್ತದೆ. ನೀವು ಏನು ಬೇಕಾದರೂ ಕರೆಯಬಹುದು.
ಮುಖ್ಯ ಆಲೋಚನೆಯೆಂದರೆ, ನಾವು ಅಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ಬದ್ಧತೆಯನ್ನು ಹೊಂದಿದ ತಕ್ಷಣ, ನಾವು ನಮ್ಮ ವಿಭಿನ್ನ ಪರಿಸರಗಳಿಗೆ ನಿಯೋಜಿಸಲು ಸಿದ್ಧವಾಗಿರುವ ಶಾಖೆಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನಾವು ಈ ಕಮಿಟ್‌ನಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನಮಗೆ ಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ನಾವು ಪ್ಯಾಕ್ ಮಾಡುತ್ತೇವೆ. zip ಆರ್ಕೈವ್‌ನಲ್ಲಿ ಮತ್ತು ಅದನ್ನು ಕೆಲವು ವಿಶ್ವಾಸಾರ್ಹ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಉಳಿಸಿ. ಮತ್ತು ಈ ಸಂಗ್ರಹಣೆಯಿಂದ ನಾವು ಈ ಜಿಪ್ ಆರ್ಕೈವ್ ಅನ್ನು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಪಡೆಯಬಹುದು.
ನಂತರ ನಾವು ಅದನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ದೇವ್ ಪರಿಸರಕ್ಕೆ ನಿಯೋಜಿಸುತ್ತೇವೆ. ನಾವು ಅಲ್ಲಿ ಓಡುತ್ತೇವೆ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದ್ದರೆ, ನಾವು ವೇದಿಕೆಗೆ ನಿಯೋಜಿಸುತ್ತೇವೆ. ಎಲ್ಲವೂ ಸರಿಯಾಗಿದ್ದರೆ, ನಾವು ಅದೇ ಆರ್ಕೈವ್ ಅನ್ನು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸುತ್ತೇವೆ, ಅದೇ ಬೈನರಿಗಳು, ನಿಖರವಾಗಿ ಒಮ್ಮೆ ಸಂಕಲಿಸಲಾಗಿದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಈ ರೀತಿಯ ಗ್ಯಾಲರಿಯನ್ನು ಹೊಂದಿರುವಾಗ, ನಾವು ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ರೋಲ್‌ಬ್ಯಾಕ್ ಕುರಿತು ಮಾತನಾಡುವಾಗ ಕೊನೆಯ ಸ್ಲೈಡ್‌ನಲ್ಲಿ ನಾವು ಪರಿಹರಿಸಿದ ಅಪಾಯಗಳನ್ನು ಪರಿಹರಿಸಲು ಇದು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ಏನನ್ನಾದರೂ ತಪ್ಪಾಗಿ ನಿಯೋಜಿಸಿದ್ದರೆ, ನೀವು ಯಾವಾಗಲೂ ಈ ಗ್ಯಾಲರಿಯಿಂದ ಯಾವುದೇ ಹಿಂದಿನ ಆವೃತ್ತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅದೇ ರೀತಿಯಲ್ಲಿ ಈ ಪರಿಸರಕ್ಕೆ ನಿಯೋಜಿಸಬೇಡಿ. ಏನಾದರೂ ತಪ್ಪಾದಲ್ಲಿ ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಸುಲಭವಾಗಿ ಹಿಂತಿರುಗಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
ಇನ್ನೊಂದು ದೊಡ್ಡ ಅಭ್ಯಾಸವಿದೆ. ನಾವು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗಿಸಿದಾಗ, ನಮಗೆ ಹಿಂದಿನ ಆವೃತ್ತಿಯ ಮೂಲಸೌಕರ್ಯವೂ ಬೇಕು ಎಂದು ನೀವು ಮತ್ತು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ.
ನಾವು ವರ್ಚುವಲ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕುರಿತು ಮಾತನಾಡುವಾಗ, ಇದು ನಿರ್ವಾಹಕರು ಸ್ಥಾಪಿಸಿದ ವಿಷಯ ಎಂದು ಹಲವರು ಭಾವಿಸುತ್ತಾರೆ. ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಬಯಸುವ ಹೊಸ ಸರ್ವರ್ ಅನ್ನು ಪಡೆಯಲು ನಿಮಗೆ ಅಗತ್ಯವಿದ್ದರೆ, ನೀವು ನಿರ್ವಾಹಕರು ಅಥವಾ ಡೆವೊಪ್‌ಗಳಿಗೆ ಟಿಕೆಟ್ ಬರೆಯಬೇಕು. ಇದಕ್ಕಾಗಿ Devops 3 ವಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತು 3 ವಾರಗಳ ನಂತರ ನಾವು ನಿಮಗಾಗಿ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೇವೆ ಎಂದು ಅವರು ನಿಮಗೆ ತಿಳಿಸುತ್ತಾರೆ, ಒಂದು ಕೋರ್, ಎರಡು ಗಿಗಾಬೈಟ್ RAM ಮತ್ತು ಡಾಟ್‌ನೆಟ್ ಇಲ್ಲದೆ ವಿಂಡೋಸ್ ಸರ್ವರ್. ನೀವು ಹೇಳುತ್ತೀರಿ: "ಆದರೆ ನನಗೆ ಡಾಟ್‌ನೆಟ್ ಬೇಕಿತ್ತು." ಅವರು: "ಸರಿ, 3 ವಾರಗಳಲ್ಲಿ ಹಿಂತಿರುಗಿ."
ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್ ಅಭ್ಯಾಸಗಳಂತೆ ಬಳಸುವ ಮೂಲಕ, ನಿಮ್ಮ ವರ್ಚುವಲ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ನೀವು ಇನ್ನೊಂದು ಸಂಪನ್ಮೂಲವಾಗಿ ಪರಿಗಣಿಸಬಹುದು ಎಂಬುದು ಇದರ ಉದ್ದೇಶವಾಗಿದೆ.
ಬಹುಶಃ, ನಿಮ್ಮಲ್ಲಿ ಯಾರಾದರೂ ಡಾಟ್‌ನೆಟ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದರೆ, ಎಂಟಿಟಿ ಫ್ರೇಮ್‌ವರ್ಕ್ ಎಂಬ ಲೈಬ್ರರಿಯ ಬಗ್ಗೆ ನೀವು ಕೇಳಿರಬಹುದು. ಮತ್ತು ಮೈಕ್ರೋಸಾಫ್ಟ್ ಸಕ್ರಿಯವಾಗಿ ತಳ್ಳುತ್ತಿರುವ ವಿಧಾನಗಳಲ್ಲಿ ಎಂಟಿಟಿ ಫ್ರೇಮ್‌ವರ್ಕ್ ಒಂದಾಗಿದೆ ಎಂದು ನೀವು ಕೇಳಿರಬಹುದು. ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು, ಇದು ಕೋಡ್ ಫಸ್ಟ್ ಎಂಬ ವಿಧಾನವಾಗಿದೆ. ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಹೇಗೆ ಕಾಣಬೇಕೆಂದು ನೀವು ಕೋಡ್‌ನಲ್ಲಿ ವಿವರಿಸಿದಾಗ ಇದು. ತದನಂತರ ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಿ. ಇದು ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಯಾವ ಕೋಷ್ಟಕಗಳು ಇವೆ ಮತ್ತು ಯಾವ ಕೋಷ್ಟಕಗಳು ಇಲ್ಲ ಎಂಬುದನ್ನು ಅದು ಸ್ವತಃ ನಿರ್ಧರಿಸುತ್ತದೆ ಮತ್ತು ನಿಮಗೆ ಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ರಚಿಸುತ್ತದೆ.
ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ ನೀವು ಅದೇ ರೀತಿ ಮಾಡಬಹುದು. ಪ್ರಾಜೆಕ್ಟ್‌ಗಾಗಿ ನಿಮಗೆ ಡೇಟಾಬೇಸ್ ಅಗತ್ಯವಿದೆಯೇ ಅಥವಾ ಪ್ರಾಜೆಕ್ಟ್‌ಗಾಗಿ ನಿಮಗೆ ವಿಂಡೋಸ್ ಸರ್ವರ್ ಅಗತ್ಯವಿದೆಯೇ ಎಂಬುದರ ನಡುವೆ ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲ. ಇದು ಕೇವಲ ಒಂದು ಸಂಪನ್ಮೂಲವಾಗಿದೆ. ಮತ್ತು ನೀವು ಈ ಸಂಪನ್ಮೂಲದ ರಚನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದು, ಈ ಸಂಪನ್ಮೂಲದ ಸಂರಚನೆಯನ್ನು ನೀವು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದು. ಅಂತೆಯೇ, ಪ್ರತಿ ಬಾರಿ ನೀವು ಕೆಲವು ಹೊಸ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಬಯಸಿದಾಗ, ಕೆಲವು ಹೊಸ ವಿಧಾನವನ್ನು, ನೀವು devops ಗೆ ಟಿಕೆಟ್ ಬರೆಯುವ ಅಗತ್ಯವಿಲ್ಲ, ನೀವು ಸಿದ್ಧ ಟೆಂಪ್ಲೇಟ್‌ಗಳಿಂದ, ರೆಡಿಮೇಡ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಂದ ನಿಮಗಾಗಿ ಪ್ರತ್ಯೇಕ ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿಯೋಜಿಸಬಹುದು ಮತ್ತು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ನಿಮ್ಮ ಎಲ್ಲಾ ಪ್ರಯೋಗಗಳಿವೆ. ನೀವು ಇದನ್ನು ಅಳಿಸಬಹುದು, ಕೆಲವು ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯಬಹುದು ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಮತ್ತಷ್ಟು ವರದಿ ಮಾಡಬಹುದು.
ಮುಂದಿನ ಅಭ್ಯಾಸ, ಇದು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಮುಖ್ಯವಾಗಿದೆ, ಆದರೆ ಕೆಲವೇ ಜನರು ಬಳಸುತ್ತಾರೆ, ಇದು ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆ ಮಾನಿಟರಿಂಗ್ ಆಗಿದೆ.
ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆ ಮಾನಿಟರಿಂಗ್ ಬಗ್ಗೆ ನಾನು ಒಂದೇ ಒಂದು ವಿಷಯವನ್ನು ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ಈ ಅಭ್ಯಾಸದ ಬಗ್ಗೆ ಹೆಚ್ಚು ಮುಖ್ಯವಾದುದು ಏನು? ಇದು ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆ ಮಾನಿಟರಿಂಗ್ ಅಪಾರ್ಟ್ಮೆಂಟ್ ಅನ್ನು ದುರಸ್ತಿ ಮಾಡುವಂತೆಯೇ ಇರುತ್ತದೆ. ಇದು ಅಂತಿಮ ಸ್ಥಿತಿಯಲ್ಲ, ಇದು ಒಂದು ಪ್ರಕ್ರಿಯೆ. ನೀವು ಇದನ್ನು ನಿಯಮಿತವಾಗಿ ಮಾಡಬೇಕಾಗಿದೆ.
ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ, ಪ್ರತಿಯೊಂದು ನಿರ್ಮಾಣದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಕೈಗೊಳ್ಳುವುದು ಒಳ್ಳೆಯದು, ಆದರೂ, ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಇದು ಯಾವಾಗಲೂ ಸಾಧ್ಯವಿಲ್ಲ. ಆದರೆ, ಕನಿಷ್ಠ, ಪ್ರತಿ ಬಿಡುಗಡೆಗೆ ಇದನ್ನು ಕೈಗೊಳ್ಳಬೇಕಾಗಿದೆ.
ಇದು ಏಕೆ ಮುಖ್ಯ? ಏಕೆಂದರೆ ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕುಸಿತವನ್ನು ಅನುಭವಿಸಿದರೆ, ಏಕೆ ಎಂದು ನೀವು ಸ್ಪಷ್ಟವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ನಿಮ್ಮ ತಂಡವು ಎರಡು ವಾರಗಳ ಸ್ಪ್ರಿಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಕನಿಷ್ಠ ಎರಡು ವಾರಗಳಿಗೊಮ್ಮೆ ನೀವು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕೆಲವು ಪ್ರತ್ಯೇಕ ಸರ್ವರ್‌ಗೆ ನಿಯೋಜಿಸಬೇಕು, ಅಲ್ಲಿ ನೀವು ಸ್ಪಷ್ಟವಾಗಿ ಸ್ಥಿರವಾದ ಪ್ರೊಸೆಸರ್, RAM, ಡಿಸ್ಕ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಅದೇ ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಗಳನ್ನು ರನ್ ಮಾಡಿ . ನೀವು ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಹಿಂದಿನ ಸ್ಪ್ರಿಂಟ್‌ನಿಂದ ಇದು ಹೇಗೆ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೋಡಿ.
ಮತ್ತು ಡ್ರಾಡೌನ್ ಎಲ್ಲೋ ತೀವ್ರವಾಗಿ ಕುಸಿದಿದೆ ಎಂದು ನೀವು ಕಂಡುಕೊಂಡರೆ, ಇದು ಕಳೆದ ಎರಡು ವಾರಗಳಲ್ಲಿ ನಡೆದ ಬದಲಾವಣೆಗಳಿಂದಾಗಿ ಎಂದು ಅರ್ಥ. ಸಮಸ್ಯೆಯನ್ನು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಗುರುತಿಸಲು ಮತ್ತು ಸರಿಪಡಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಮತ್ತೊಮ್ಮೆ, ಇವುಗಳು ಸರಿಸುಮಾರು ಅದೇ ಮೆಟ್ರಿಕ್‌ಗಳಾಗಿವೆ, ಅದರ ಮೂಲಕ ನೀವು ಅದನ್ನು ಎಷ್ಟು ಯಶಸ್ವಿಯಾಗಿ ಮಾಡಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಅಳೆಯಬಹುದು.
ನಾವು ಹೊಂದಿರುವ ಮುಂದಿನ ಅಭ್ಯಾಸವೆಂದರೆ ಕಾನ್ಫಿಗರೇಶನ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಅಭ್ಯಾಸ. ಇದನ್ನು ಗಂಭೀರವಾಗಿ ಪರಿಗಣಿಸುವವರು ಬಹಳ ಕಡಿಮೆ. ಆದರೆ ನನ್ನನ್ನು ನಂಬಿರಿ, ಇದು ನಿಜವಾಗಿಯೂ ತುಂಬಾ ಗಂಭೀರವಾದ ವಿಷಯವಾಗಿದೆ.
ಇತ್ತೀಚೆಗೆ ಒಂದು ತಮಾಷೆಯ ಕಥೆ ಇತ್ತು. ಹುಡುಗರು ನನ್ನ ಬಳಿಗೆ ಬಂದು ಹೇಳಿದರು: "ನಮ್ಮ ಅರ್ಜಿಯ ಭದ್ರತಾ ಲೆಕ್ಕಪರಿಶೋಧನೆ ನಡೆಸಲು ನಮಗೆ ಸಹಾಯ ಮಾಡಿ." ನಾವು ದೀರ್ಘಕಾಲದವರೆಗೆ ಕೋಡ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ನೋಡಿದ್ದೇವೆ, ಅವರು ಅಪ್ಲಿಕೇಶನ್ ಬಗ್ಗೆ ಹೇಳಿದರು, ರೇಖಾಚಿತ್ರಗಳನ್ನು ಚಿತ್ರಿಸಿದರು. ಮತ್ತು ಪ್ಲಸ್ ಅಥವಾ ಮೈನಸ್ ಎಲ್ಲವೂ ತಾರ್ಕಿಕ, ಅರ್ಥವಾಗುವ, ಸುರಕ್ಷಿತ, ಆದರೆ ಒಂದು ಇತ್ತು ಆದರೆ! ಅವರು ತಮ್ಮ ಮೂಲ ನಿಯಂತ್ರಣದಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರು, ಐಪಿ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಉತ್ಪಾದನೆಯಿಂದ, ಈ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸಲು ಲಾಗಿನ್‌ಗಳು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ಸೇರಿದಂತೆ ಇತ್ಯಾದಿ.
ಮತ್ತು ನಾನು ಹೇಳುತ್ತೇನೆ: “ಹುಡುಗರೇ, ಸರಿ, ನೀವು ನಿಮ್ಮ ಉತ್ಪಾದನಾ ಪರಿಸರವನ್ನು ಫೈರ್‌ವಾಲ್‌ನೊಂದಿಗೆ ಮುಚ್ಚಿದ್ದೀರಿ, ಆದರೆ ನೀವು ಉತ್ಪಾದನಾ ಡೇಟಾಬೇಸ್ಗಾಗಿ ಲಾಗಿನ್ ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮೂಲ ನಿಯಂತ್ರಣದಲ್ಲಿಯೇ ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಯಾವುದೇ ಡೆವಲಪರ್ ಅದನ್ನು ಓದಬಹುದು ಎಂಬುದು ಈಗಾಗಲೇ ದೊಡ್ಡ ಭದ್ರತಾ ಅಪಾಯವಾಗಿದೆ. . ಮತ್ತು ಕೋಡ್ ದೃಷ್ಟಿಕೋನದಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಎಷ್ಟು ಸುರಕ್ಷಿತವಾಗಿದ್ದರೂ, ನೀವು ಅದನ್ನು ಮೂಲ ನಿಯಂತ್ರಣದಲ್ಲಿ ಬಿಟ್ಟರೆ, ನೀವು ಎಲ್ಲಿಯೂ ಯಾವುದೇ ಆಡಿಟ್ ಅನ್ನು ರವಾನಿಸುವುದಿಲ್ಲ. ನಾನು ಅದೇ ಮಾತನಾಡುತ್ತಿರುವುದು.
ಸಂರಚನಾ ನಿರ್ವಹಣೆ. ನಾವು ವಿಭಿನ್ನ ಪರಿಸರದಲ್ಲಿ ವಿಭಿನ್ನ ಸಂರಚನೆಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಉದಾಹರಣೆಗೆ, ನಾವು QA, ಡೆಮೊ, ಉತ್ಪಾದನಾ ಪರಿಸರ ಇತ್ಯಾದಿಗಳಿಗಾಗಿ ಡೇಟಾಬೇಸ್‌ಗಳಿಗಾಗಿ ವಿಭಿನ್ನ ಲಾಗಿನ್‌ಗಳು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಹೊಂದಿರಬಹುದು.
ಈ ಸಂರಚನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿಯೂ ಮಾಡಬಹುದು. ಇದು ಯಾವಾಗಲೂ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿರಬೇಕು. ಏಕೆ? ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಮ್ಮೆ ನಿರ್ಮಿಸಿದ ಕಾರಣ, ಮತ್ತು ನಂತರ ನೀವು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಐಪಿ ಅಥವಾ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಐಪಿ ಮೂಲಕ SQL ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕ ಹೊಂದಿದ್ದೀರಾ ಎಂದು ಅಪ್ಲಿಕೇಶನ್ ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ, ಅದು ಒಂದೇ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು. ಆದ್ದರಿಂದ, ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನಿಮ್ಮಲ್ಲಿ ಒಬ್ಬರು ಇನ್ನೂ ಕೋಡ್‌ನಲ್ಲಿ ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡುತ್ತಿದ್ದರೆ, ನಾನು ನಿಮ್ಮನ್ನು ಹುಡುಕುತ್ತೇನೆ ಮತ್ತು ನನ್ನೊಂದಿಗೆ ಅದೇ ಯೋಜನೆಯಲ್ಲಿ ನಿಮ್ಮನ್ನು ಕಂಡುಕೊಂಡರೆ ನಿಮ್ಮನ್ನು ಶಿಕ್ಷಿಸುತ್ತೇನೆ ಎಂದು ನೆನಪಿಡಿ. ಇದನ್ನು ಯಾವಾಗಲೂ ಪ್ರತ್ಯೇಕ ಸಂರಚನೆಯಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, web.config ನಲ್ಲಿ.
ಮತ್ತು ಈ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಈಗಾಗಲೇ ಪ್ರತ್ಯೇಕವಾಗಿ ನಿರ್ವಹಿಸಲಾಗಿದೆ, ಅಂದರೆ ಡೆವಲಪರ್ ಮತ್ತು ನಿರ್ವಾಹಕರು ಒಂದೇ ಕೋಣೆಯಲ್ಲಿ ಬಂದು ಕುಳಿತುಕೊಳ್ಳುವ ಕ್ಷಣ ಇದು. ಮತ್ತು ಡೆವಲಪರ್ ಹೀಗೆ ಹೇಳಬಹುದು: “ನೋಡಿ, ನನ್ನ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬೈನರಿಗಳು ಇಲ್ಲಿವೆ. ಅವರು ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಅಪ್ಲಿಕೇಶನ್ ಕೆಲಸ ಮಾಡಲು ಡೇಟಾಬೇಸ್ ಅಗತ್ಯವಿದೆ. ಇಲ್ಲಿ ಬೈನರಿಗಳ ಪಕ್ಕದಲ್ಲಿ ಫೈಲ್ ಇದೆ. ಈ ಫೈಲ್‌ನಲ್ಲಿ, ಈ ಕ್ಷೇತ್ರವು ಲಾಗಿನ್‌ಗೆ ಕಾರಣವಾಗಿದೆ, ಇದು ಪಾಸ್‌ವರ್ಡ್‌ಗಾಗಿ, ಇದು ಐಪಿಗೆ. ಅದನ್ನು ಎಲ್ಲಿಯಾದರೂ ನಿಯೋಜಿಸಿ." ಮತ್ತು ನಿರ್ವಾಹಕರಿಗೆ ಇದು ಸರಳ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಈ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಅವನು ಅದನ್ನು ನಿಜವಾಗಿಯೂ ಎಲ್ಲಿ ಬೇಕಾದರೂ ನಿಯೋಜಿಸಬಹುದು.
ಮತ್ತು ನಾನು ಮಾತನಾಡಲು ಬಯಸುವ ಕೊನೆಯ ಅಭ್ಯಾಸವು ಮೋಡಗಳಿಗೆ ತುಂಬಾ ಸಂಬಂಧಿಸಿದ ಅಭ್ಯಾಸವಾಗಿದೆ. ಮತ್ತು ನೀವು ಮೋಡದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದರೆ ಅದು ಗರಿಷ್ಠ ಪರಿಣಾಮವನ್ನು ತರುತ್ತದೆ. ಇದು ನಿಮ್ಮ ಪರಿಸರವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತೆಗೆದುಹಾಕುವುದು.
ನಾನು ಕೆಲಸ ಮಾಡುವ ತಂಡಗಳಿಂದ ಈ ಸಮ್ಮೇಳನದಲ್ಲಿ ಹಲವಾರು ಜನರಿದ್ದಾರೆ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ. ಮತ್ತು ನಾನು ಕೆಲಸ ಮಾಡುವ ಎಲ್ಲಾ ತಂಡಗಳೊಂದಿಗೆ, ನಾವು ಈ ಅಭ್ಯಾಸವನ್ನು ಬಳಸುತ್ತೇವೆ.
ಏಕೆ? ಸಹಜವಾಗಿ, ಪ್ರತಿ ಡೆವಲಪರ್ 24/7 ಕೆಲಸ ಮಾಡುವ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಹೊಂದಿದ್ದರೆ ಅದು ಉತ್ತಮವಾಗಿರುತ್ತದೆ. ಆದರೆ ಬಹುಶಃ ಇದು ನಿಮಗೆ ಸುದ್ದಿಯಾಗಿರಬಹುದು, ಬಹುಶಃ ನೀವು ಗಮನ ಹರಿಸಲಿಲ್ಲ, ಆದರೆ ಡೆವಲಪರ್ ಸ್ವತಃ 24/7 ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಡೆವಲಪರ್ ಸಾಮಾನ್ಯವಾಗಿ ದಿನಕ್ಕೆ 8 ಗಂಟೆಗಳ ಕಾಲ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಅವನು ಬೇಗನೆ ಕೆಲಸಕ್ಕೆ ಬಂದರೂ, ಅವನು ಜಿಮ್‌ಗೆ ಹೋಗುವಾಗ ದೊಡ್ಡ ಊಟವನ್ನು ಮಾಡುತ್ತಾನೆ. ಡೆವಲಪರ್ ನಿಜವಾಗಿ ಈ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುವಾಗ ದಿನಕ್ಕೆ 12 ಗಂಟೆಗಳಿರಲಿ. ನಮ್ಮ ಶಾಸನದ ಪ್ರಕಾರ, ನಾವು ವಾರದಲ್ಲಿ 5 ರಲ್ಲಿ 7 ದಿನಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದನ್ನು ಕೆಲಸದ ದಿನಗಳು ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
ಅಂತೆಯೇ, ವಾರದ ದಿನಗಳಲ್ಲಿ ಈ ಯಂತ್ರವು 24 ಗಂಟೆಗಳ ಕಾಲ ಕೆಲಸ ಮಾಡಬಾರದು, ಆದರೆ ಕೇವಲ 12, ಮತ್ತು ವಾರಾಂತ್ಯದಲ್ಲಿ ಈ ಯಂತ್ರವು ಕೆಲಸ ಮಾಡಬಾರದು. ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಇಲ್ಲಿ ಹೇಳಲು ಮುಖ್ಯವಾದುದು ಏನು? ಈ ಮೂಲಭೂತ ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ ಈ ಸರಳ ಅಭ್ಯಾಸವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೂಲಕ, ಈ ಪರಿಸರವನ್ನು ನಿರ್ವಹಿಸುವ ವೆಚ್ಚವನ್ನು 70% ರಷ್ಟು ಕಡಿಮೆ ಮಾಡಲು ಇದು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಅಂದರೆ ನೀವು ನಿಮ್ಮ ದೇವ್, ಕ್ಯೂಎ, ಡೆಮೊ, ಪರಿಸರದ ಬೆಲೆಯನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು 3 ರಿಂದ ಭಾಗಿಸಿದಿರಿ.
ಉಳಿದ ಹಣವನ್ನು ಏನು ಮಾಡಬೇಕು ಎಂಬುದು ಪ್ರಶ್ನೆ. ಉದಾಹರಣೆಗೆ, ಡೆವಲಪರ್ಗಳು ಈಗಾಗಲೇ ಖರೀದಿಸದಿದ್ದರೆ ReSharper ಅನ್ನು ಖರೀದಿಸಬೇಕು. ಅಥವಾ ಕಾಕ್ಟೈಲ್ ಪಾರ್ಟಿ ಮಾಡಿ. ನೀವು ಈ ಹಿಂದೆ ದೇವ್ ಮತ್ತು ಕ್ಯೂಎ ಎರಡೂ ಮೇಯಿಸಿದ ಒಂದು ಪರಿಸರವನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಅದು ಅಷ್ಟೆ, ಈಗ ನೀವು 3 ವಿಭಿನ್ನವಾದವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಬಹುದು ಮತ್ತು ಜನರು ಪರಸ್ಪರ ಹಸ್ತಕ್ಷೇಪ ಮಾಡುವುದಿಲ್ಲ.
ನಿರಂತರ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮಾಪನದೊಂದಿಗೆ ಸ್ಲೈಡ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಯೋಜನೆಯಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಾವು 1 ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ನಾವು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೇಗೆ ಹೋಲಿಸಬಹುದು, ಎರಡು ತಿಂಗಳ ನಂತರ ಒಂದು ಮಿಲಿಯನ್ ಇವೆ? ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಳೆಯುವುದು ಏಕೆ ಮತ್ತು ಏನು ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೇಗೆ?
ಇದು ಒಳ್ಳೆಯ ಪ್ರಶ್ನೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ನೀವು ಯಾವಾಗಲೂ ಅದೇ ಸಂಪನ್ಮೂಲಗಳ ಮೇಲೆ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಳೆಯಬೇಕು. ಅಂದರೆ, ನೀವು ಹೊಸ ಕೋಡ್ ಅನ್ನು ಹೊರತರುತ್ತೀರಿ, ನೀವು ಹೊಸ ಕೋಡ್‌ನಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಳೆಯುತ್ತೀರಿ. ಉದಾಹರಣೆಗೆ, ನೀವು ವಿಭಿನ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸನ್ನಿವೇಶಗಳನ್ನು ಪರೀಕ್ಷಿಸಬೇಕಾಗಿದೆ, 1 ಬಳಕೆದಾರರಿರುವ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಗಾತ್ರವು 000 ಗಿಗಾಬೈಟ್‌ಗಳಾಗಿರುವ ಬೆಳಕಿನ ಲೋಡ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸಲು ನೀವು ಬಯಸುತ್ತೀರಿ ಎಂದು ಹೇಳೋಣ. ನೀವು ಅದನ್ನು ಅಳತೆ ಮಾಡಿ ಮತ್ತು ಸಂಖ್ಯೆಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೀರಿ. ಮುಂದೆ ನಾವು ಇನ್ನೊಂದು ಸನ್ನಿವೇಶವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, 5 ಬಳಕೆದಾರರು, ಡೇಟಾಬೇಸ್ ಗಾತ್ರ 5 ಟೆರಾಬೈಟ್. ನಾವು ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ನೆನಪಿಸಿಕೊಂಡಿದ್ದೇವೆ.
ಇಲ್ಲಿ ಯಾವುದು ಮುಖ್ಯ? ಇಲ್ಲಿ ಪ್ರಮುಖ ವಿಷಯವೆಂದರೆ ಸನ್ನಿವೇಶ, ಡೇಟಾದ ಪರಿಮಾಣ, ಏಕಕಾಲಿಕ ಬಳಕೆದಾರರ ಸಂಖ್ಯೆ ಇತ್ಯಾದಿಗಳನ್ನು ಅವಲಂಬಿಸಿ, ನೀವು ಕೆಲವು ಮಿತಿಗಳಿಗೆ ಓಡಬಹುದು. ಉದಾಹರಣೆಗೆ, ನೆಟ್‌ವರ್ಕ್ ಕಾರ್ಡ್‌ನ ಮಿತಿಗೆ ಅಥವಾ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ನ ಮಿತಿಗೆ ಅಥವಾ ಪ್ರೊಸೆಸರ್ ಸಾಮರ್ಥ್ಯಗಳ ಮಿತಿಗೆ. ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ಮುಖ್ಯವಾಗಿದೆ. ವಿಭಿನ್ನ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ನೀವು ಕೆಲವು ಮಿತಿಗಳಿಗೆ ಓಡುತ್ತೀರಿ. ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ಹೊಡೆದಾಗ ನೀವು ಸಂಖ್ಯೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
ವಿಶೇಷ ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಳೆಯುವ ಬಗ್ಗೆ ನಾವು ಮಾತನಾಡುತ್ತಿದ್ದೇವೆಯೇ? ಅಂದರೆ, ಇದು ಉತ್ಪಾದನೆಯಲ್ಲವೇ?
ಹೌದು, ಇದು ಉತ್ಪಾದನೆಯಲ್ಲ, ಇದು ಪರೀಕ್ಷಾ ಪರಿಸರವಾಗಿದೆ, ಇದು ಯಾವಾಗಲೂ ಒಂದೇ ಆಗಿರುತ್ತದೆ ಆದ್ದರಿಂದ ನೀವು ಅದನ್ನು ಹಿಂದಿನ ಅಳತೆಗಳೊಂದಿಗೆ ಹೋಲಿಸಬಹುದು.
ಅರ್ಥವಾಯಿತು ಧನ್ಯವಾದಗಳು!
ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳಿಲ್ಲದಿದ್ದರೆ, ನಾವು ಮುಗಿಸಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಧನ್ಯವಾದ!
ಮೂಲ: www.habr.com