ನಾವು ಒಮ್ಮೆ ಒಂದು ಸೌಲಭ್ಯದಲ್ಲಿ ಗ್ರಾಹಕರಿಗೆ ಎಲೆಕ್ಟ್ರಾನಿಕ್ ಡಾಕ್ಯುಮೆಂಟ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪೂರೈಸಿದ್ದೇವೆ. ತದನಂತರ ಇನ್ನೊಂದು ವಸ್ತುವಿಗೆ. ಮತ್ತು ಇನ್ನೂ ಒಂದು. ಮತ್ತು ನಾಲ್ಕನೇ, ಮತ್ತು ಐದನೇ. ನಾವು 10 ವಿತರಿಸಿದ ವಸ್ತುಗಳನ್ನು ತಲುಪುವಷ್ಟು ದೂರ ಸಾಗಿದೆವು. ಇದು ಶಕ್ತಿಯುತವಾಗಿ ಹೊರಹೊಮ್ಮಿತು... ವಿಶೇಷವಾಗಿ ನಾವು ಬದಲಾವಣೆಗಳನ್ನು ತಲುಪಿಸುವಾಗ. ಉತ್ಪಾದನಾ ಸರ್ಕ್ಯೂಟ್‌ಗೆ ವಿತರಣೆಯ ಭಾಗವಾಗಿ, ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆಯ 5 ಸನ್ನಿವೇಶಗಳಿಗೆ ಅಂತಿಮವಾಗಿ 10 ಗಂಟೆಗಳು ಮತ್ತು 6-7 ಉದ್ಯೋಗಿಗಳು ಬೇಕಾಗಿದ್ದಾರೆ. ಅಂತಹ ವೆಚ್ಚಗಳು ನಮಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ವಿರಳವಾಗಿ ವಿತರಣೆಗಳನ್ನು ಮಾಡಲು ಒತ್ತಾಯಿಸಿದವು. ಮೂರು ವರ್ಷಗಳ ಕಾರ್ಯಾಚರಣೆಯ ನಂತರ, ನಾವು ಅದನ್ನು ನಿಲ್ಲಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಮತ್ತು DevOps ನ ಪಿಂಚ್‌ನೊಂದಿಗೆ ಯೋಜನೆಯನ್ನು ಮಸಾಲೆ ಮಾಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ಈಗ ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳು 3 ಗಂಟೆಗಳಲ್ಲಿ ನಡೆಯುತ್ತದೆ, ಮತ್ತು 3 ಜನರು ಅದರಲ್ಲಿ ಭಾಗವಹಿಸುತ್ತಾರೆ: ಎಂಜಿನಿಯರ್ ಮತ್ತು ಇಬ್ಬರು ಪರೀಕ್ಷಕರು. ಸುಧಾರಣೆಗಳನ್ನು ಸಂಖ್ಯೆಯಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಕ್ತಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚು-ಪ್ರೀತಿಯ TTM ನಲ್ಲಿ ಕಡಿತಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ನಮ್ಮ ಅನುಭವದಲ್ಲಿ, ಅದರ ಬಗ್ಗೆ ತಿಳಿದಿರುವವರಿಗಿಂತ DevOps ನಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯಬಹುದಾದ ಹೆಚ್ಚಿನ ಗ್ರಾಹಕರು ಇದ್ದಾರೆ. ಆದ್ದರಿಂದ, DevOps ಅನ್ನು ಜನರಿಗೆ ಹತ್ತಿರ ತರಲು, ನಾವು ಸರಳ ಕನ್ಸ್ಟ್ರಕ್ಟರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ, ಅದನ್ನು ನಾವು ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಮಾತನಾಡುತ್ತೇವೆ.
ಈಗ ನಿಮಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಹೇಳೋಣ. ಒಂದು ಶಕ್ತಿ ಕಂಪನಿಯು 10 ದೊಡ್ಡ ಸೌಲಭ್ಯಗಳಲ್ಲಿ ತಾಂತ್ರಿಕ ದಾಖಲೆ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿಯೋಜಿಸುತ್ತಿದೆ. DevOps ಇಲ್ಲದೆ ಈ ಪ್ರಮಾಣದ ಯೋಜನೆಗಳನ್ನು ನ್ಯಾವಿಗೇಟ್ ಮಾಡುವುದು ಸುಲಭವಲ್ಲ, ಏಕೆಂದರೆ ಹಸ್ತಚಾಲಿತ ಕಾರ್ಮಿಕರ ಹೆಚ್ಚಿನ ಪಾಲು ಕೆಲಸವನ್ನು ಬಹಳ ವಿಳಂಬಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಗುಣಮಟ್ಟವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ - ಎಲ್ಲಾ ಹಸ್ತಚಾಲಿತ ಕೆಲಸಗಳು ದೋಷಗಳಿಂದ ತುಂಬಿವೆ. ಮತ್ತೊಂದೆಡೆ, ಕೇವಲ ಒಂದು ಅನುಸ್ಥಾಪನೆಯು ಇರುವ ಯೋಜನೆಗಳು ಇವೆ, ಆದರೆ ಎಲ್ಲವೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ, ನಿರಂತರವಾಗಿ ಮತ್ತು ವೈಫಲ್ಯವಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ - ಉದಾಹರಣೆಗೆ, ದೊಡ್ಡ ಏಕಶಿಲೆಯ ಸಂಸ್ಥೆಗಳಲ್ಲಿ ಅದೇ ಡಾಕ್ಯುಮೆಂಟ್ ಹರಿವಿನ ವ್ಯವಸ್ಥೆಗಳು. ಇಲ್ಲದಿದ್ದರೆ, ಯಾರಾದರೂ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮಾಡುತ್ತಾರೆ, ನಿಯೋಜನೆ ಸೂಚನೆಗಳ ಬಗ್ಗೆ ಮರೆತುಬಿಡಿ - ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ ಮತ್ತು ಎಲ್ಲವೂ ಕುಸಿಯುತ್ತವೆ.
ಸಾಮಾನ್ಯವಾಗಿ ನಾವು ಗ್ರಾಹಕರೊಂದಿಗೆ ಒಪ್ಪಂದದ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಮ್ಮ ಆಸಕ್ತಿಗಳು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಭಿನ್ನವಾಗಿರುತ್ತವೆ. ಗ್ರಾಹಕರು ಯೋಜನೆಯನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಬಜೆಟ್ ಮತ್ತು ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳಲ್ಲಿ ನೋಡುತ್ತಾರೆ. ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳಲ್ಲಿ ಸೇರಿಸದ ವಿವಿಧ DevOps ಅಭ್ಯಾಸಗಳ ಪ್ರಯೋಜನಗಳನ್ನು ಅವನಿಗೆ ವಿವರಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಹೆಚ್ಚುವರಿ ವ್ಯಾಪಾರ ಮೌಲ್ಯದೊಂದಿಗೆ ತ್ವರಿತ ಬಿಡುಗಡೆಗಳಲ್ಲಿ ಅಥವಾ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸುವಲ್ಲಿ ಅವನು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ ಏನು?
ಅಯ್ಯೋ, ಪೂರ್ವ-ಅನುಮೋದಿತ ವೆಚ್ಚದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಈ ಆಸಕ್ತಿಯು ಯಾವಾಗಲೂ ಕಂಡುಬರುವುದಿಲ್ಲ. ನಮ್ಮ ಆಚರಣೆಯಲ್ಲಿ, ನಿರ್ಲಜ್ಜ ಮತ್ತು ಅಸಡ್ಡೆ ಗುತ್ತಿಗೆದಾರನ ಅಭಿವೃದ್ಧಿಯನ್ನು ನಾವು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ಸಂದರ್ಭವಿತ್ತು. ಇದು ಭಯಾನಕವಾಗಿದೆ: ಯಾವುದೇ ನವೀಕೃತ ಮೂಲ ಕೋಡ್‌ಗಳು ಇರಲಿಲ್ಲ, ವಿಭಿನ್ನ ಸ್ಥಾಪನೆಗಳಲ್ಲಿ ಒಂದೇ ಸಿಸ್ಟಮ್‌ನ ಕೋಡ್ ಬೇಸ್ ವಿಭಿನ್ನವಾಗಿತ್ತು, ದಸ್ತಾವೇಜನ್ನು ಭಾಗಶಃ ಗೈರುಹಾಜವಾಗಿತ್ತು ಮತ್ತು ಭಾಗಶಃ ಭಯಾನಕ ಗುಣಮಟ್ಟದ್ದಾಗಿದೆ. ಸಹಜವಾಗಿ, ಗ್ರಾಹಕರು ಮೂಲ ಕೋಡ್, ಜೋಡಣೆ, ಬಿಡುಗಡೆಗಳು ಇತ್ಯಾದಿಗಳ ಮೇಲೆ ನಿಯಂತ್ರಣವನ್ನು ಹೊಂದಿರಲಿಲ್ಲ.
ಇಲ್ಲಿಯವರೆಗೆ, DevOps ಬಗ್ಗೆ ಎಲ್ಲರಿಗೂ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ನಾವು ಅದರ ಅನುಕೂಲಗಳ ಬಗ್ಗೆ, ನಿಜವಾದ ಸಂಪನ್ಮೂಲ ಉಳಿತಾಯದ ಬಗ್ಗೆ ಮಾತನಾಡಿದ ತಕ್ಷಣ, ಎಲ್ಲಾ ಗ್ರಾಹಕರ ಕಣ್ಣುಗಳು ಬೆಳಗುತ್ತವೆ. ಆದ್ದರಿಂದ DevOps ಅನ್ನು ಒಳಗೊಂಡಿರುವ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯು ಕಾಲಾನಂತರದಲ್ಲಿ ಹೆಚ್ಚುತ್ತಿದೆ. ಇಲ್ಲಿ, ಗ್ರಾಹಕರೊಂದಿಗೆ ಒಂದೇ ಭಾಷೆಯನ್ನು ಸುಲಭವಾಗಿ ಮಾತನಾಡಲು, ಸೂಕ್ತವಾದ ಅಭಿವೃದ್ಧಿ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಸಹಾಯ ಮಾಡುವ ವ್ಯಾಪಾರ ಸಮಸ್ಯೆಗಳು ಮತ್ತು DevOps ಅಭ್ಯಾಸಗಳನ್ನು ನಾವು ತ್ವರಿತವಾಗಿ ಸಂಪರ್ಕಿಸುವ ಅಗತ್ಯವಿದೆ.
ಆದ್ದರಿಂದ, ನಾವು ಒಂದೆಡೆ ಸಮಸ್ಯೆಗಳ ಗುಂಪನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಮತ್ತೊಂದೆಡೆ ನಾವು DevOps ಜ್ಞಾನ, ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಸಾಧನಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅನುಭವವನ್ನು ಎಲ್ಲರೊಂದಿಗೆ ಏಕೆ ಹಂಚಿಕೊಳ್ಳಬಾರದು?
DevOps ಕನ್ಸ್ಟ್ರಕ್ಟರ್ ಅನ್ನು ರಚಿಸಲಾಗುತ್ತಿದೆ
ಅಗೈಲ್ ತನ್ನದೇ ಆದ ಪ್ರಣಾಳಿಕೆಯನ್ನು ಹೊಂದಿದೆ. ITIL ತನ್ನದೇ ಆದ ವಿಧಾನವನ್ನು ಹೊಂದಿದೆ. DevOps ಕಡಿಮೆ ಅದೃಷ್ಟ ಹೊಂದಿದೆ - ಇದು ಇನ್ನೂ ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಮತ್ತು ಮಾನದಂಡಗಳನ್ನು ಪಡೆದುಕೊಂಡಿಲ್ಲ. ಆದರೂ ಅವುಗಳ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಅಭ್ಯಾಸಗಳ ಮೌಲ್ಯಮಾಪನದ ಆಧಾರದ ಮೇಲೆ ಕಂಪನಿಗಳ ಮುಕ್ತಾಯವನ್ನು ನಿರ್ಧರಿಸಿ.
ಅದೃಷ್ಟವಶಾತ್, 2014 ರಲ್ಲಿ ಪ್ರಸಿದ್ಧ ಕಂಪನಿ ಗಾರ್ಟ್ನರ್ ಮತ್ತು ಪ್ರಮುಖ DevOps ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಸಂಬಂಧಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿದ್ದಾರೆ. ಇದರ ಆಧಾರದ ಮೇಲೆ, ನಾನು ಇನ್ಫೋಗ್ರಾಫಿಕ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದ್ದೇನೆ:
ನಾವು ಅದನ್ನು ನಮ್ಮ ಆಧಾರವಾಗಿ ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ . ಪ್ರತಿಯೊಂದು ನಾಲ್ಕು ಕ್ಷೇತ್ರಗಳು ಪರಿಕರಗಳ ಗುಂಪನ್ನು ಹೊಂದಿವೆ - ನಾವು ಅವುಗಳನ್ನು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ, ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾದವುಗಳನ್ನು ಗುರುತಿಸಿದ್ದೇವೆ, ಏಕೀಕರಣ ಬಿಂದುಗಳು ಮತ್ತು ಸೂಕ್ತವಾದ ಆಪ್ಟಿಮೈಸೇಶನ್ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಗುರುತಿಸಿದ್ದೇವೆ. ಒಟ್ಟಾರೆಯಾಗಿ ಅದು ಬದಲಾಯಿತು 36 ಅಭ್ಯಾಸಗಳು ಮತ್ತು 115 ಪರಿಕರಗಳು, ಅದರಲ್ಲಿ ಕಾಲು ಭಾಗವು ಮುಕ್ತ ಮೂಲ ಅಥವಾ ಉಚಿತ ಸಾಫ್ಟ್‌ವೇರ್ ಆಗಿದೆ. ಮುಂದೆ, ನಾವು ಪ್ರತಿ ಪ್ರದೇಶದಲ್ಲಿ ಏನು ಸಾಧಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಮಾತನಾಡುತ್ತೇವೆ ಮತ್ತು ಉದಾಹರಣೆಯಾಗಿ, ತಾಂತ್ರಿಕ ದಾಖಲೆ ನಿರ್ವಹಣೆಯನ್ನು ರಚಿಸಲು ಯೋಜನೆಯಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಮಾತನಾಡುತ್ತೇವೆ, ಅದರೊಂದಿಗೆ ನಾವು ಪೋಸ್ಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.
ಪ್ರಕ್ರಿಯೆಗಳು
ಕುಖ್ಯಾತ EDMS ಯೋಜನೆಯಲ್ಲಿ, ತಾಂತ್ರಿಕ ದಾಖಲಾತಿ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಪ್ರತಿ 10 ವಸ್ತುಗಳಲ್ಲೂ ಅದೇ ಯೋಜನೆಯ ಪ್ರಕಾರ ನಿಯೋಜಿಸಲಾಗಿದೆ. ಅನುಸ್ಥಾಪನೆಯು 4 ಸರ್ವರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ: ಡೇಟಾಬೇಸ್ ಸರ್ವರ್, ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್, ಪೂರ್ಣ-ಪಠ್ಯ ಸೂಚಿಕೆ ಮತ್ತು ವಿಷಯ ನಿರ್ವಹಣೆ. ಅನುಸ್ಥಾಪನೆಯಲ್ಲಿ, ಅವು ಒಂದೇ ನೋಡ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಸೌಲಭ್ಯಗಳಲ್ಲಿ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿವೆ. ಎಲ್ಲಾ ವಸ್ತುಗಳು ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಸ್ವಲ್ಪ ಭಿನ್ನವಾಗಿರುತ್ತವೆ, ಆದರೆ ಇದು ಜಾಗತಿಕ ಸಂವಹನಕ್ಕೆ ಅಡ್ಡಿಯಾಗುವುದಿಲ್ಲ.
ಮೊದಲಿಗೆ, DevOps ಅಭ್ಯಾಸಗಳ ಪ್ರಕಾರ, ನಾವು ಸ್ಥಳೀಯವಾಗಿ ಮೂಲಸೌಕರ್ಯವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿದ್ದೇವೆ, ನಂತರ ನಾವು ವಿತರಣೆಯನ್ನು ಪರೀಕ್ಷಾ ಸರ್ಕ್ಯೂಟ್‌ಗೆ ಮತ್ತು ನಂತರ ಗ್ರಾಹಕರ ಉತ್ಪನ್ನಕ್ಕೆ ತಂದಿದ್ದೇವೆ. ಪ್ರತಿಯೊಂದು ಪ್ರಕ್ರಿಯೆಯು ಹಂತ ಹಂತವಾಗಿ ಕೆಲಸ ಮಾಡಲ್ಪಟ್ಟಿದೆ. ಪರಿಸರ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮೂಲ ಕೋಡ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಿವಾರಿಸಲಾಗಿದೆ, ಸ್ವಯಂಚಾಲಿತ ನವೀಕರಣಕ್ಕಾಗಿ ವಿತರಣಾ ಕಿಟ್ ಅನ್ನು ಸಂಕಲಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ. ಸಂರಚನಾ ಬದಲಾವಣೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಎಂಜಿನಿಯರ್‌ಗಳು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಗೆ ಸೂಕ್ತವಾದ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ - ಮತ್ತು ನಂತರ ಸ್ವಯಂಚಾಲಿತ ನವೀಕರಣವು ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ನಡೆಯುತ್ತದೆ.
ಈ ವಿಧಾನಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸಲಾಗಿದೆ. ಹಿಂದೆ, ಪ್ರಾಜೆಕ್ಟ್ ಸ್ಟ್ಯಾಂಡ್‌ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನವೀಕರಿಸುವುದನ್ನು ಹೊರತುಪಡಿಸಿ ಏನನ್ನೂ ಮಾಡದ ಪರೀಕ್ಷಕರನ್ನು ಹೊಂದಿತ್ತು. ಈಗ ಅವರು ಬರುತ್ತಾರೆ, ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ನೋಡಿ ಮತ್ತು ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾದ ಕೆಲಸಗಳನ್ನು ಮಾಡಿ. ಪ್ರತಿಯೊಂದು ಅಪ್‌ಡೇಟ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ - ಮೇಲ್ಮೈ ಮಟ್ಟದಿಂದ ವ್ಯಾಪಾರ ಸನ್ನಿವೇಶದ ಯಾಂತ್ರೀಕೃತಗೊಂಡವರೆಗೆ. ಟೆಸ್ಟ್‌ರೈಲ್‌ನಲ್ಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರತ್ಯೇಕ ವರದಿಗಳಾಗಿ ಪೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ.
ಸಂಸ್ಕೃತಿ
ಪರೀಕ್ಷಾ ವಿನ್ಯಾಸದ ಉದಾಹರಣೆಯ ಮೂಲಕ ನಿರಂತರ ಪ್ರಯೋಗವನ್ನು ಉತ್ತಮವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ. ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ವ್ಯವಸ್ಥೆಯನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಸೃಜನಶೀಲ ಕೆಲಸ. ಪರೀಕ್ಷಾ ಯೋಜನೆಯನ್ನು ಬರೆಯುವಾಗ, ಸರಿಯಾಗಿ ಪರೀಕ್ಷಿಸುವುದು ಹೇಗೆ ಮತ್ತು ಯಾವ ಶಾಖೆಗಳನ್ನು ಅನುಸರಿಸಬೇಕು ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಮತ್ತು ಚೆಕ್‌ಗಳ ಸೂಕ್ತ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ಧರಿಸಲು ಸಮಯ ಮತ್ತು ಬಜೆಟ್ ನಡುವಿನ ಸಮತೋಲನವನ್ನು ಸಹ ಕಂಡುಕೊಳ್ಳಿ. ಅಗತ್ಯವಿರುವ ಪರೀಕ್ಷೆಗಳನ್ನು ನಿಖರವಾಗಿ ಆಯ್ಕೆ ಮಾಡುವುದು ಮುಖ್ಯ, ಬಳಕೆದಾರರು ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ ಎಂಬುದರ ಕುರಿತು ಯೋಚಿಸಿ, ಪರಿಸರ ಮತ್ತು ಸಂಭವನೀಯ ಬಾಹ್ಯ ಅಂಶಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ. ನಿರಂತರ ಪ್ರಯೋಗವಿಲ್ಲದೆ ಮಾಡುವುದು ಅಸಾಧ್ಯ.
ಈಗ ಪರಸ್ಪರ ಸಂಸ್ಕೃತಿಯ ಬಗ್ಗೆ. ಹಿಂದೆ, ಎರಡು ಎದುರಾಳಿ ಬದಿಗಳಿದ್ದವು - ಎಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳು. ಅಭಿವರ್ಧಕರು ಹೇಳಿದರು: "ಅದನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಲಾಗುವುದು ಎಂದು ನಾವು ಹೆದರುವುದಿಲ್ಲ. ನೀವು ಇಂಜಿನಿಯರ್‌ಗಳು, ನೀವು ಬುದ್ಧಿವಂತರು, ಅದು ವೈಫಲ್ಯಗಳಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.. ಎಂಜಿನಿಯರ್‌ಗಳು ಉತ್ತರಿಸಿದರು: “ನೀವು ಡೆವಲಪರ್‌ಗಳು ತುಂಬಾ ಅಸಡ್ಡೆ ಹೊಂದಿದ್ದೀರಿ. ಹೆಚ್ಚು ಜಾಗರೂಕರಾಗಿರಿ ಮತ್ತು ನಿಮ್ಮ ಬಿಡುಗಡೆಗಳನ್ನು ನಾವು ಕಡಿಮೆ ಬಾರಿ ಪ್ಲೇ ಮಾಡುತ್ತೇವೆ. ಏಕೆಂದರೆ ಪ್ರತಿ ಬಾರಿ ನೀವು ನಮಗೆ ಸೋರಿಕೆಯ ಕೋಡ್ ಅನ್ನು ನೀಡಿದಾಗ, ಹೇಗೆ ಸಂವಹನ ನಡೆಸಬೇಕು ಎಂಬುದು ನಮಗೆ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.. ಇದು DevOps ದೃಷ್ಟಿಕೋನದಿಂದ ವಿಭಿನ್ನವಾಗಿ ರಚಿಸಲಾದ ಸಾಂಸ್ಕೃತಿಕ ಸಂವಾದದ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಇಲ್ಲಿ, ಇಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳಿಬ್ಬರೂ ಒಂದೇ ತಂಡದ ಭಾಗವಾಗಿದ್ದಾರೆ, ಅದು ನಿರಂತರವಾಗಿ ಬದಲಾಗುವುದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹ ಸಾಫ್ಟ್‌ವೇರ್.
ಒಂದೇ ತಂಡದೊಳಗೆ, ತಜ್ಞರು ಪರಸ್ಪರ ಸಹಾಯ ಮಾಡಲು ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಮೊದಲಿನಂತೆ? ಉದಾಹರಣೆಗೆ, ಸುಮಾರು 50 ಪುಟಗಳ ಕೆಲವು ದಪ್ಪ ನಿಯೋಜನೆ ಸೂಚನೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತಿದೆ. ಎಂಜಿನಿಯರ್ ಅದನ್ನು ಓದಿದರು, ಏನೋ ಅರ್ಥವಾಗಲಿಲ್ಲ, ಶಪಿಸಿದರು ಮತ್ತು ಕಾಮೆಂಟ್ ಮಾಡಲು ಡೆವಲಪರ್‌ಗೆ ಬೆಳಿಗ್ಗೆ ಮೂರು ಗಂಟೆಗೆ ಕೇಳಿದರು. ಡೆವಲಪರ್ ಕಾಮೆಂಟ್ ಮಾಡಿದ್ದಾರೆ ಮತ್ತು ಶಪಿಸಿದರು - ಕೊನೆಯಲ್ಲಿ, ಯಾರೂ ಸಂತೋಷವಾಗಿರಲಿಲ್ಲ. ಜೊತೆಗೆ, ನೈಸರ್ಗಿಕವಾಗಿ, ಕೆಲವು ತಪ್ಪುಗಳು ಇದ್ದವು, ಏಕೆಂದರೆ ನೀವು ಸೂಚನೆಗಳಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ಈಗ ಎಂಜಿನಿಯರ್, ಡೆವಲಪರ್ ಜೊತೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಸಾಫ್ಟ್‌ವೇರ್ ಮೂಲಸೌಕರ್ಯದ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆಗಾಗಿ ಸ್ಕ್ರಿಪ್ಟ್ ಬರೆಯುತ್ತಿದ್ದಾರೆ. ಮತ್ತು ಅವರು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಒಂದೇ ಭಾಷೆಯಲ್ಲಿ ಪರಸ್ಪರ ಮಾತನಾಡುತ್ತಾರೆ.
ಜನರು
ನವೀಕರಣದ ವ್ಯಾಪ್ತಿಯಿಂದ ತಂಡದ ಗಾತ್ರವನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ವಿತರಣೆಯ ರಚನೆಯ ಸಮಯದಲ್ಲಿ ತಂಡವನ್ನು ನೇಮಿಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ; ಇದು ಸಾಮಾನ್ಯ ಯೋಜನಾ ತಂಡದಿಂದ ಆಸಕ್ತಿ ಹೊಂದಿರುವವರನ್ನು ಒಳಗೊಂಡಿದೆ. ನಂತರ ಪ್ರತಿ ಹಂತಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗಿರುವವರೊಂದಿಗೆ ನವೀಕರಣ ಯೋಜನೆಯನ್ನು ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅದು ಮುಂದುವರೆದಂತೆ ತಂಡವು ವರದಿ ಮಾಡುತ್ತದೆ. ಎಲ್ಲಾ ತಂಡದ ಸದಸ್ಯರು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾಗಿದೆ. ತಂಡದ ಭಾಗವಾಗಿ, ನಾವು ಬ್ಯಾಕಪ್ ಡೆವಲಪರ್ ಅನ್ನು ಸಹ ಹೊಂದಿದ್ದೇವೆ, ಆದರೆ ಅವರು ಎಂದಿಗೂ ಸಂಪರ್ಕಿಸಬೇಕಾಗಿಲ್ಲ.
ತಂತ್ರಜ್ಞಾನದ
ತಂತ್ರಜ್ಞಾನ ರೇಖಾಚಿತ್ರದಲ್ಲಿ, ಕೆಲವು ಅಂಶಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡಲಾಗಿದೆ, ಆದರೆ ಅವುಗಳ ಕೆಳಗೆ ತಂತ್ರಜ್ಞಾನಗಳ ಗುಂಪೇ ಇದೆ - ನೀವು ಅವರ ವಿವರಣೆಗಳೊಂದಿಗೆ ಸಂಪೂರ್ಣ ಪುಸ್ತಕವನ್ನು ಪ್ರಕಟಿಸಬಹುದು. ಆದ್ದರಿಂದ ನಾವು ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕವನ್ನು ಹೈಲೈಟ್ ಮಾಡುತ್ತೇವೆ.
ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ
ಈಗ, ಬಹುಶಃ, ಈ ಪರಿಕಲ್ಪನೆಯು ಯಾರಿಗೂ ಆಶ್ಚರ್ಯವಾಗುವುದಿಲ್ಲ, ಆದರೆ ಹಿಂದೆ ಮೂಲಸೌಕರ್ಯಗಳ ವಿವರಣೆಗಳು ಅಪೇಕ್ಷಿತವಾಗಿರುವುದನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿವೆ. , ಪರೀಕ್ಷಾ ಪರಿಸರಗಳು ಅನನ್ಯವಾಗಿದ್ದವು, ಅವುಗಳು ಪಾಲಿಸಲ್ಪಟ್ಟವು ಮತ್ತು ಪಾಲಿಸಲ್ಪಟ್ಟವು, ಧೂಳಿನ ಕಣಗಳು ಅವುಗಳನ್ನು ಹಾರಿಸಲಾಯಿತು.
ಇಂದು ಯಾರೂ ಪ್ರಯೋಗ ಮಾಡಲು ಹೆದರುವುದಿಲ್ಲ. ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ಮೂಲ ಚಿತ್ರಗಳಿವೆ, ಪರಿಸರವನ್ನು ನಿಯೋಜಿಸಲು ಸಿದ್ಧ-ಸಿದ್ಧ ಸನ್ನಿವೇಶಗಳಿವೆ. ಎಲ್ಲಾ ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ತ್ವರಿತವಾಗಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ. ಹಿಂದೆ, ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸ್ಟ್ಯಾಂಡ್‌ಗೆ ತಲುಪಿಸಲು ಅಗತ್ಯವಾದಾಗ, ಕಾನ್ಫಿಗರೇಶನ್ ಅಂತರವು ಕಾಣಿಸಿಕೊಂಡಿತು. ಈಗ ನೀವು ಮೂಲ ಕೋಡ್‌ಗೆ ಒಂದು ಸಾಲನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ.
ಮೂಲಸೌಕರ್ಯ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮತ್ತು ಪೈಪ್‌ಲೈನ್‌ಗಳ ಜೊತೆಗೆ, ದಸ್ತಾವೇಜನ್ನು ಕೋಡ್ ವಿಧಾನವಾಗಿ ದಸ್ತಾವೇಜನ್ನು ಸಹ ಬಳಸಲಾಗುತ್ತದೆ. ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಯೋಜನೆಗೆ ಹೊಸ ಜನರನ್ನು ಸಂಪರ್ಕಿಸಲು ಸುಲಭವಾಗಿದೆ, ವಿವರಿಸಿದ ಕಾರ್ಯಗಳ ಆಧಾರದ ಮೇಲೆ ಅವರನ್ನು ಸಿಸ್ಟಮ್ಗೆ ಪರಿಚಯಿಸಿ, ಉದಾಹರಣೆಗೆ, ಪರೀಕ್ಷಾ ಯೋಜನೆಯಲ್ಲಿ, ಮತ್ತು ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಿ.
ನಿರಂತರ ವಿತರಣೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ
DevOps ಕುರಿತು, ನಿರಂತರ ವಿತರಣೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾವು ಪರಿಕರಗಳನ್ನು ಹೇಗೆ ಆರಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಮಾತನಾಡಿದ್ದೇವೆ. ಆಗಾಗ್ಗೆ ಯಾವುದನ್ನೂ ಪುನಃ ಬರೆಯುವ ಅಗತ್ಯವಿಲ್ಲ - ಹಿಂದೆ ಬರೆದ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬಳಸುವುದು, ಘಟಕಗಳ ನಡುವೆ ಏಕೀಕರಣವನ್ನು ಸರಿಯಾಗಿ ನಿರ್ಮಿಸುವುದು ಮತ್ತು ಸಾಮಾನ್ಯ ನಿರ್ವಹಣಾ ಕನ್ಸೋಲ್ ಅನ್ನು ರಚಿಸುವುದು ಸಾಕು. ಮತ್ತು ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಒಂದು ಬಟನ್ ಅಥವಾ ವೇಳಾಪಟ್ಟಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರಾರಂಭಿಸಬಹುದು.
ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಪರಿಕಲ್ಪನೆಗಳಿವೆ, ನಿರಂತರ ವಿತರಣೆ ಮತ್ತು ನಿರಂತರ ನಿಯೋಜನೆ. ಎರಡನ್ನೂ "ನಿರಂತರ ವಿತರಣೆ" ಎಂದು ಅನುವಾದಿಸಬಹುದು, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಅವುಗಳ ನಡುವೆ ಸ್ವಲ್ಪ ವ್ಯತ್ಯಾಸವಿದೆ. ವಿತರಿಸಿದ ಇಂಧನ ಕಂಪನಿಯ ತಾಂತ್ರಿಕ ದಾಖಲೆಯ ಹರಿವಿಗಾಗಿ ನಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ, ವಿತರಣೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ - ಉತ್ಪಾದನೆಗೆ ಅನುಸ್ಥಾಪನೆಯು ಆಜ್ಞೆಯ ಮೇಲೆ ಸಂಭವಿಸಿದಾಗ. ನಿಯೋಜನೆಯಲ್ಲಿ, ಅನುಸ್ಥಾಪನೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ. ಈ ಯೋಜನೆಯಲ್ಲಿ ನಿರಂತರ ವಿತರಣೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಮಾರ್ಪಟ್ಟಿದೆ DevOps ನ ಕೇಂದ್ರ ಭಾಗ.
ಸಾಮಾನ್ಯವಾಗಿ, ಕೆಲವು ನಿಯತಾಂಕಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮೂಲಕ, DevOps ಅಭ್ಯಾಸಗಳು ಏಕೆ ಉಪಯುಕ್ತವಾಗಿವೆ ಎಂಬುದನ್ನು ನೀವು ಸ್ಪಷ್ಟವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು. ಮತ್ತು ಸಂಖ್ಯೆಗಳನ್ನು ನಿಜವಾಗಿಯೂ ಪ್ರೀತಿಸುವ ನಿರ್ವಹಣೆಗೆ ಇದನ್ನು ತಿಳಿಸಿ. ಒಟ್ಟು ಉಡಾವಣೆಗಳ ಸಂಖ್ಯೆ, ಸ್ಕ್ರಿಪ್ಟ್ ಹಂತಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯ, ಯಶಸ್ವಿ ಉಡಾವಣೆಗಳ ಪಾಲು - ಇವೆಲ್ಲವೂ ಮಾರುಕಟ್ಟೆಗೆ ಪ್ರತಿಯೊಬ್ಬರ ನೆಚ್ಚಿನ ಸಮಯವನ್ನು ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಅಂದರೆ, ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಗೆ ಬದ್ಧತೆಯಿಂದ ಆವೃತ್ತಿಯ ಬಿಡುಗಡೆಯ ಸಮಯ ಉತ್ಪಾದನಾ ಪರಿಸರ. ಅಗತ್ಯ ಪರಿಕರಗಳ ಅನುಷ್ಠಾನದೊಂದಿಗೆ, ಎಂಜಿನಿಯರ್‌ಗಳು ಮೇಲ್ ಮೂಲಕ ಮೌಲ್ಯಯುತ ಸೂಚಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ಯೋಜನಾ ವ್ಯವಸ್ಥಾಪಕರು ಅವುಗಳನ್ನು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ನೋಡುತ್ತಾರೆ. ಈ ರೀತಿಯಾಗಿ ನೀವು ಹೊಸ ಉಪಕರಣಗಳ ಪ್ರಯೋಜನಗಳನ್ನು ತಕ್ಷಣವೇ ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು. ಮತ್ತು DevOps ವಿನ್ಯಾಸಕವನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ನೀವು ಅವುಗಳನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು.
ಯಾರಿಗೆ ನಮ್ಮ ಅವಶ್ಯಕತೆ ಇರುತ್ತದೆ ?
ನಾವು ನಟಿಸುವುದು ಬೇಡ: ಆರಂಭದಲ್ಲಿ, ಅವರು ನಮಗೆ ಉಪಯುಕ್ತರಾದರು. ನಾವು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ನೀವು ಗ್ರಾಹಕರೊಂದಿಗೆ ಅದೇ ಭಾಷೆಯನ್ನು ಮಾತನಾಡಬೇಕು ಮತ್ತು DevOps ಡಿಸೈನರ್ ಸಹಾಯದಿಂದ ನಾವು ಅಂತಹ ಸಂಭಾಷಣೆಗೆ ಆಧಾರವನ್ನು ತ್ವರಿತವಾಗಿ ಸ್ಕೆಚ್ ಮಾಡಬಹುದು. ವ್ಯಾಪಾರ ತಜ್ಞರು ತಮಗೆ ಬೇಕಾದುದನ್ನು ಸ್ವತಃ ನಿರ್ಣಯಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಹೀಗಾಗಿ ವೇಗವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಾರೆ. ಡಿಸೈನರ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ವಿವರವಾಗಿ ಮಾಡಲು ನಾವು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ, ವಿವರಣೆಗಳ ಗುಂಪನ್ನು ಸೇರಿಸುತ್ತೇವೆ ಇದರಿಂದ ಯಾವುದೇ ಬಳಕೆದಾರನು ತಾನು ಆಯ್ಕೆಮಾಡುತ್ತಿರುವುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾನೆ.
ವಿನ್ಯಾಸಕಾರರ ಸ್ವರೂಪವು ಕಟ್ಟಡ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಕಂಪನಿಯ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬೆಳವಣಿಗೆಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಸಂಯೋಜಿಸುವ ಮತ್ತು ಸರಳವಾಗಿ ಅಂತರವನ್ನು ತುಂಬುವ ಪರಿಹಾರಗಳನ್ನು ಮಾತ್ರ ನೀವು ಆರಿಸಿದರೆ ಎಲ್ಲವನ್ನೂ ಕೆಡವಲು ಮತ್ತು ಅದನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ.
ಬಹುಶಃ ನಿಮ್ಮ ಅಭಿವೃದ್ಧಿ ಈಗಾಗಲೇ ಉನ್ನತ ಮಟ್ಟಕ್ಕೆ ಸಾಗಿದೆ ಮತ್ತು ನಮ್ಮ ಸಾಧನವು ತುಂಬಾ "ಕ್ಯಾಪ್ಟನ್" ಎಂದು ತೋರುತ್ತದೆ. ಆದರೆ ಇದು ನಮಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ ಮತ್ತು ಇದು ಕೆಲವು ಓದುಗರಿಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ಭಾವಿಸುತ್ತೇವೆ. ನಾವು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇವೆ ಡಿಸೈನರ್‌ಗೆ - ಏನಾದರೂ ಇದ್ದರೆ, ಆರಂಭಿಕ ಡೇಟಾವನ್ನು ನಮೂದಿಸಿದ ತಕ್ಷಣ ನೀವು ರೇಖಾಚಿತ್ರವನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ. ನಿಮ್ಮ ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ಸೇರ್ಪಡೆಗಳಿಗೆ ನಾವು ಕೃತಜ್ಞರಾಗಿರುತ್ತೇವೆ.
ಮೂಲ: www.habr.com