ಕೋಡ್‌ನಂತೆ ಮೂಲಸೌಕರ್ಯ: XP ಬಳಸಿಕೊಂಡು ಸಮಸ್ಯೆಗಳನ್ನು ನಿವಾರಿಸುವುದು ಹೇಗೆ

ಹಲೋ, ಹಬ್ರ್! ಈ ಹಿಂದೆ, ನಾನು ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ಜೀವನದ ಬಗ್ಗೆ ಕೋಡ್ ಮಾದರಿಯಾಗಿ ದೂರು ನೀಡಿದ್ದೇನೆ ಮತ್ತು ಪ್ರಸ್ತುತ ಪರಿಸ್ಥಿತಿಯನ್ನು ಪರಿಹರಿಸಲು ಏನನ್ನೂ ನೀಡಲಿಲ್ಲ. ಹತಾಶೆಯ ಪ್ರಪಾತದಿಂದ ಪಾರಾಗಲು ಮತ್ತು ಪರಿಸ್ಥಿತಿಯನ್ನು ಸರಿಯಾದ ದಿಕ್ಕಿನಲ್ಲಿ ನಡೆಸಲು ಯಾವ ವಿಧಾನಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತವೆ ಎಂಬುದನ್ನು ಇಂದು ನಾನು ನಿಮಗೆ ಹೇಳಲು ಹಿಂತಿರುಗಿದ್ದೇನೆ.

ಹಿಂದಿನ ಲೇಖನದಲ್ಲಿ "ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ: ಮೊದಲ ಪರಿಚಯ" ನಾನು ಈ ಪ್ರದೇಶದ ಬಗ್ಗೆ ನನ್ನ ಅನಿಸಿಕೆಗಳನ್ನು ಹಂಚಿಕೊಂಡಿದ್ದೇನೆ, ಈ ಪ್ರದೇಶದಲ್ಲಿನ ಪ್ರಸ್ತುತ ಪರಿಸ್ಥಿತಿಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸಲು ಪ್ರಯತ್ನಿಸಿದೆ ಮತ್ತು ಎಲ್ಲಾ ಡೆವಲಪರ್‌ಗಳಿಗೆ ತಿಳಿದಿರುವ ಪ್ರಮಾಣಿತ ಅಭ್ಯಾಸಗಳು ಸಹಾಯ ಮಾಡಬಹುದೆಂದು ಸೂಚಿಸಿದೆ. ಜೀವನದ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ದೂರುಗಳಿವೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಪ್ರಸ್ತುತ ಪರಿಸ್ಥಿತಿಯಿಂದ ಹೊರಬರಲು ಯಾವುದೇ ಪ್ರಸ್ತಾಪಗಳಿಲ್ಲ.

ನಾವು ಯಾರು, ನಾವು ಎಲ್ಲಿದ್ದೇವೆ ಮತ್ತು ನಮಗೆ ಯಾವ ಸಮಸ್ಯೆಗಳಿವೆ

ನಾವು ಪ್ರಸ್ತುತ Sre ಆನ್‌ಬೋರ್ಡಿಂಗ್ ತಂಡದಲ್ಲಿದ್ದೇವೆ, ಇದು ಆರು ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಮತ್ತು ಮೂರು ಮೂಲಸೌಕರ್ಯ ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ನಾವೆಲ್ಲರೂ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್ (IaC) ಎಂದು ಬರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ. ನಾವು ಮೂಲತಃ ಕೋಡ್ ಅನ್ನು ಹೇಗೆ ಬರೆಯುವುದು ಮತ್ತು "ಸರಾಸರಿಗಿಂತ" ಡೆವಲಪರ್‌ಗಳ ಇತಿಹಾಸವನ್ನು ಹೇಗೆ ಬರೆಯುವುದು ಎಂದು ತಿಳಿದಿರುವುದರಿಂದ ನಾವು ಇದನ್ನು ಮಾಡುತ್ತೇವೆ.

• ನಮಗೆ ಹಲವಾರು ಅನುಕೂಲಗಳಿವೆ: ನಿರ್ದಿಷ್ಟ ಹಿನ್ನೆಲೆ, ಅಭ್ಯಾಸಗಳ ಜ್ಞಾನ, ಕೋಡ್ ಬರೆಯುವ ಸಾಮರ್ಥ್ಯ, ಹೊಸ ವಿಷಯಗಳನ್ನು ಕಲಿಯುವ ಬಯಕೆ.
• ಮತ್ತು ಕುಗ್ಗುವ ಭಾಗವಿದೆ, ಇದು ಮೈನಸ್ ಆಗಿದೆ: ಮೂಲಸೌಕರ್ಯ ಯಂತ್ರಾಂಶದ ಬಗ್ಗೆ ಜ್ಞಾನದ ಕೊರತೆ.

ನಮ್ಮ IaC ನಲ್ಲಿ ನಾವು ಬಳಸುವ ತಂತ್ರಜ್ಞಾನದ ಸ್ಟಾಕ್.

• ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸಲು ಟೆರಾಫಾರ್ಮ್.
• ಚಿತ್ರಗಳನ್ನು ಜೋಡಿಸಲು ಪ್ಯಾಕರ್. ಇವು ವಿಂಡೋಸ್, ಸೆಂಟೋಸ್ 7 ಚಿತ್ರಗಳು.
• Jsonnet drone.io ನಲ್ಲಿ ಶಕ್ತಿಯುತವಾದ ನಿರ್ಮಾಣವನ್ನು ಮಾಡಲು, ಹಾಗೆಯೇ ಪ್ಯಾಕರ್ json ಮತ್ತು ನಮ್ಮ ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸಲು.
• ಅಜುರೆ.
• ಚಿತ್ರಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವಾಗ ಅನ್ಸಿಬಲ್.
• ಸಹಾಯಕ ಸೇವೆಗಳು ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಒದಗಿಸುವುದಕ್ಕಾಗಿ ಪೈಥಾನ್.
• ಮತ್ತು ತಂಡದ ಸದಸ್ಯರ ನಡುವೆ ಹಂಚಿಕೊಳ್ಳಲಾದ ಪ್ಲಗಿನ್‌ಗಳೊಂದಿಗೆ VSCode ನಲ್ಲಿ ಇದೆಲ್ಲವೂ.

ನನ್ನಿಂದ ತೀರ್ಮಾನ ಕೊನೆಯ ಲೇಖನ ಹೀಗಿತ್ತು: ನಾನು (ಮೊದಲನೆಯದಾಗಿ ನನ್ನಲ್ಲಿ) ಆಶಾವಾದವನ್ನು ಹುಟ್ಟುಹಾಕಲು ಪ್ರಯತ್ನಿಸಿದೆ, ಈ ಪ್ರದೇಶದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ತೊಂದರೆಗಳು ಮತ್ತು ಸಂಕೀರ್ಣತೆಗಳನ್ನು ಎದುರಿಸಲು ನಮಗೆ ತಿಳಿದಿರುವ ವಿಧಾನಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳನ್ನು ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ ಎಂದು ನಾನು ಹೇಳಲು ಬಯಸುತ್ತೇನೆ.

ನಾವು ಪ್ರಸ್ತುತ ಈ ಕೆಳಗಿನ IaC ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ಹೋರಾಡುತ್ತಿದ್ದೇವೆ:

• ಕೋಡ್ ಅಭಿವೃದ್ಧಿಗಾಗಿ ಉಪಕರಣಗಳು ಮತ್ತು ಸಾಧನಗಳ ಅಪೂರ್ಣತೆ.
• ನಿಧಾನ ನಿಯೋಜನೆ. ಮೂಲಸೌಕರ್ಯವು ನೈಜ ಪ್ರಪಂಚದ ಭಾಗವಾಗಿದೆ ಮತ್ತು ಅದು ನಿಧಾನವಾಗಿರಬಹುದು.
• ವಿಧಾನಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳ ಕೊರತೆ.
• ನಾವು ಹೊಸಬರು ಮತ್ತು ಹೆಚ್ಚು ತಿಳಿದಿಲ್ಲ.

ಪಾರುಗಾಣಿಕಾಕ್ಕೆ ಎಕ್ಸ್ಟ್ರೀಮ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ (XP).

ಎಲ್ಲಾ ಡೆವಲಪರ್‌ಗಳು ಎಕ್ಸ್‌ಟ್ರೀಮ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ (XP) ಮತ್ತು ಅದರ ಹಿಂದೆ ನಿಂತಿರುವ ಅಭ್ಯಾಸಗಳೊಂದಿಗೆ ಪರಿಚಿತರಾಗಿದ್ದಾರೆ. ನಮ್ಮಲ್ಲಿ ಹಲವರು ಈ ವಿಧಾನದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದಾರೆ ಮತ್ತು ಅದು ಯಶಸ್ವಿಯಾಗಿದೆ. ಹಾಗಾದರೆ ಮೂಲಸೌಕರ್ಯ ಸವಾಲುಗಳನ್ನು ಜಯಿಸಲು ಅಲ್ಲಿ ಹಾಕಿರುವ ತತ್ವಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳನ್ನು ಏಕೆ ಬಳಸಬಾರದು? ನಾವು ಈ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ.

ನಿಮ್ಮ ಉದ್ಯಮಕ್ಕೆ XP ವಿಧಾನದ ಅನ್ವಯಿಸುವಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆXP ಸೂಕ್ತವಾದ ಪರಿಸರದ ವಿವರಣೆ ಇಲ್ಲಿದೆ ಮತ್ತು ಅದು ನಮಗೆ ಹೇಗೆ ಸಂಬಂಧಿಸಿದೆ:

1. ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಬದಲಾಗುತ್ತಿರುವ ಸಾಫ್ಟ್‌ವೇರ್ ಅವಶ್ಯಕತೆಗಳು. ಅಂತಿಮ ಗುರಿ ಏನೆಂಬುದು ನಮಗೆ ಸ್ಪಷ್ಟವಾಗಿತ್ತು. ಆದರೆ ವಿವರಗಳು ಬದಲಾಗಬಹುದು. ನಾವು ಟ್ಯಾಕ್ಸಿ ಎಲ್ಲಿ ಬೇಕು ಎಂದು ನಾವೇ ನಿರ್ಧರಿಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ ಅವಶ್ಯಕತೆಗಳು ನಿಯತಕಾಲಿಕವಾಗಿ ಬದಲಾಗುತ್ತವೆ (ಮುಖ್ಯವಾಗಿ ನಾವೇ). ನಾವು SRE ತಂಡವನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಅದು ಸ್ವಯಂಚಾಲನವನ್ನು ಸ್ವತಃ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸ್ವತಃ ಅಗತ್ಯತೆಗಳು ಮತ್ತು ಕೆಲಸದ ವ್ಯಾಪ್ತಿಯನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ, ಆಗ ಈ ಹಂತವು ಚೆನ್ನಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ.

2. ಹೊಸ ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸಿಕೊಂಡು ನಿಗದಿತ ಸಮಯದ ಯೋಜನೆಗಳಿಂದ ಉಂಟಾಗುವ ಅಪಾಯಗಳು. ನಮಗೆ ತಿಳಿದಿಲ್ಲದ ಕೆಲವು ವಿಷಯಗಳನ್ನು ಬಳಸುವಾಗ ನಾವು ಅಪಾಯಗಳನ್ನು ಎದುರಿಸಬಹುದು. ಮತ್ತು ಇದು 100% ನಮ್ಮ ಪ್ರಕರಣವಾಗಿದೆ. ನಮ್ಮ ಸಂಪೂರ್ಣ ಯೋಜನೆಯು ನಮಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಚಯವಿಲ್ಲದ ತಂತ್ರಜ್ಞಾನಗಳ ಬಳಕೆಯಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ನಿರಂತರ ಸಮಸ್ಯೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ... ಮೂಲಸೌಕರ್ಯ ಕ್ಷೇತ್ರದಲ್ಲಿ ಸಾರ್ವಕಾಲಿಕ ಅನೇಕ ಹೊಸ ತಂತ್ರಜ್ಞಾನಗಳು ಹೊರಹೊಮ್ಮುತ್ತಿವೆ.

3,4 ಸಣ್ಣ, ಸಹ-ಸ್ಥಳೀಯ ವಿಸ್ತೃತ ಅಭಿವೃದ್ಧಿ ತಂಡ. ನೀವು ಬಳಸುತ್ತಿರುವ ಸ್ವಯಂಚಾಲಿತ ತಂತ್ರಜ್ಞಾನವು ಘಟಕ ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕ ಪರೀಕ್ಷೆಗಳಿಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಎರಡು ಅಂಶಗಳು ನಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ. ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಸಂಘಟಿತ ತಂಡವಲ್ಲ, ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ನಮ್ಮಲ್ಲಿ ಒಂಬತ್ತು ಮಂದಿ ಇದ್ದಾರೆ, ಅದನ್ನು ದೊಡ್ಡ ತಂಡವೆಂದು ಪರಿಗಣಿಸಬಹುದು. ಆದಾಗ್ಯೂ, "ದೊಡ್ಡ" ತಂಡದ ಕೆಲವು ವ್ಯಾಖ್ಯಾನಗಳ ಪ್ರಕಾರ, ಬಹಳಷ್ಟು 14+ ಜನರು.

ಕೆಲವು XP ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಅವು ಪ್ರತಿಕ್ರಿಯೆಯ ವೇಗ ಮತ್ತು ಗುಣಮಟ್ಟವನ್ನು ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.

XP ಪ್ರತಿಕ್ರಿಯೆ ಲೂಪ್ ತತ್ವ

ನನ್ನ ತಿಳುವಳಿಕೆಯಲ್ಲಿ, ಪ್ರತಿಕ್ರಿಯೆಯು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರವಾಗಿದೆ, ನಾನು ಸರಿಯಾದ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿದ್ದೇನೆ, ನಾವು ಅಲ್ಲಿಗೆ ಹೋಗುತ್ತಿದ್ದೇವೆಯೇ? ಇದಕ್ಕಾಗಿ XP ಒಂದು ದೈವಿಕ ಯೋಜನೆಯನ್ನು ಹೊಂದಿದೆ: ಸಮಯ ಪ್ರತಿಕ್ರಿಯೆ ಲೂಪ್. ಕುತೂಹಲಕಾರಿ ಸಂಗತಿಯೆಂದರೆ, ನಾವು ಕಡಿಮೆಯಿರುವಂತೆ, ಅಗತ್ಯವಿರುವ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲು ನಾವು ಓಎಸ್ ಅನ್ನು ವೇಗವಾಗಿ ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಇದು ಚರ್ಚೆಗೆ ಸಾಕಷ್ಟು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವಾಗಿದೆ, ನಮ್ಮ ಐಟಿ ಉದ್ಯಮದಲ್ಲಿ ಓಎಸ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಪಡೆಯಲು ಸಾಧ್ಯವಿದೆ. ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಆರು ತಿಂಗಳವರೆಗೆ ಮಾಡುವುದು ಎಷ್ಟು ನೋವಿನಿಂದ ಕೂಡಿದೆ ಎಂದು ಊಹಿಸಿ ಮತ್ತು ನಂತರವೇ ಪ್ರಾರಂಭದಲ್ಲಿ ತಪ್ಪಾಗಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ. ವಿನ್ಯಾಸದಲ್ಲಿ ಮತ್ತು ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಗಳ ಯಾವುದೇ ನಿರ್ಮಾಣದಲ್ಲಿ ಇದು ಸಂಭವಿಸುತ್ತದೆ.

ನಮ್ಮ IaC ವಿಷಯದಲ್ಲಿ, ಪ್ರತಿಕ್ರಿಯೆ ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಮೇಲಿನ ರೇಖಾಚಿತ್ರಕ್ಕೆ ನಾನು ತಕ್ಷಣ ಸಣ್ಣ ಹೊಂದಾಣಿಕೆಯನ್ನು ಮಾಡುತ್ತೇನೆ: ಬಿಡುಗಡೆಯ ಯೋಜನೆಯು ಮಾಸಿಕ ಚಕ್ರವನ್ನು ಹೊಂದಿಲ್ಲ, ಆದರೆ ದಿನಕ್ಕೆ ಹಲವಾರು ಬಾರಿ ಸಂಭವಿಸುತ್ತದೆ. ಈ OS ಸೈಕಲ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಕೆಲವು ಅಭ್ಯಾಸಗಳಿವೆ, ಅದನ್ನು ನಾವು ಹೆಚ್ಚು ವಿವರವಾಗಿ ನೋಡುತ್ತೇವೆ.

ಪ್ರಮುಖ: ಮೇಲೆ ಹೇಳಲಾದ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯು ಪರಿಹಾರವಾಗಿದೆ. XP ಅಭ್ಯಾಸಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಿದರೆ, ಅದು ನಿಮ್ಮನ್ನು ಹತಾಶೆಯ ಪ್ರಪಾತದಿಂದ ಹೊರಗೆಳೆಯಬಹುದು.

ಹತಾಶೆಯ ಪ್ರಪಾತದಿಂದ ನಿಮ್ಮನ್ನು ಹೇಗೆ ಎಳೆಯುವುದು: ಮೂರು ಅಭ್ಯಾಸಗಳು

ಪರೀಕ್ಷೆಗಳು

XP ಪ್ರತಿಕ್ರಿಯೆ ಲೂಪ್‌ನಲ್ಲಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಎರಡು ಬಾರಿ ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ. ಇದು ಕೇವಲ ಹಾಗೆ ಅಲ್ಲ. ಸಂಪೂರ್ಣ ಎಕ್ಸ್‌ಟ್ರೀಮ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ತಂತ್ರಕ್ಕೆ ಅವು ಬಹಳ ಮುಖ್ಯ.

ನೀವು ಘಟಕ ಮತ್ತು ಸ್ವೀಕಾರ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಭಾವಿಸಲಾಗಿದೆ. ಕೆಲವರು ನಿಮಗೆ ಕೆಲವು ನಿಮಿಷಗಳಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆ ನೀಡುತ್ತಾರೆ, ಇತರರು ಕೆಲವೇ ದಿನಗಳಲ್ಲಿ, ಆದ್ದರಿಂದ ಅವರು ಬರೆಯಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಕಡಿಮೆ ಬಾರಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ.

ಕ್ಲಾಸಿಕ್ ಟೆಸ್ಟಿಂಗ್ ಪಿರಮಿಡ್ ಇದೆ, ಇದು ಹೆಚ್ಚಿನ ಪರೀಕ್ಷೆಗಳು ಇರಬೇಕೆಂದು ತೋರಿಸುತ್ತದೆ.

IaC ಯೋಜನೆಯಲ್ಲಿ ಈ ಚೌಕಟ್ಟು ನಮಗೆ ಹೇಗೆ ಅನ್ವಯಿಸುತ್ತದೆ? ವಾಸ್ತವವಾಗಿ... ಇಲ್ಲವೇ ಇಲ್ಲ.

• ಘಟಕ ಪರೀಕ್ಷೆಗಳು, ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಇರಬೇಕು ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಹೆಚ್ಚು ಇರುವಂತಿಲ್ಲ. ಅಥವಾ ಅವರು ಪರೋಕ್ಷವಾಗಿ ಏನನ್ನಾದರೂ ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದಾರೆ. ವಾಸ್ತವವಾಗಿ, ನಾವು ಅವುಗಳನ್ನು ಬರೆಯುವುದಿಲ್ಲ ಎಂದು ಹೇಳಬಹುದು. ಆದರೆ ನಾವು ಮಾಡಲು ಸಾಧ್ಯವಾದ ಅಂತಹ ಪರೀಕ್ಷೆಗಳಿಗೆ ಕೆಲವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಇಲ್ಲಿವೆ:
  1. jsonnet ಕೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ. ಇದು, ಉದಾಹರಣೆಗೆ, ನಮ್ಮ ಡ್ರೋನ್ ಅಸೆಂಬ್ಲಿ ಪೈಪ್‌ಲೈನ್, ಇದು ಸಾಕಷ್ಟು ಜಟಿಲವಾಗಿದೆ. jsonnet ಕೋಡ್ ಪರೀಕ್ಷೆಗಳಿಂದ ಚೆನ್ನಾಗಿ ಆವರಿಸಲ್ಪಟ್ಟಿದೆ.
     ನಾವು ಇದನ್ನು ಬಳಸುತ್ತೇವೆ Jsonnet ಗಾಗಿ ಘಟಕ ಪರೀಕ್ಷಾ ಚೌಕಟ್ಟು.
  2. ಸಂಪನ್ಮೂಲವು ಪ್ರಾರಂಭವಾದಾಗ ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಗಾಗಿ ಪರೀಕ್ಷೆಗಳು. ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಪೈಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಪರೀಕ್ಷೆಗಳನ್ನು ಅವುಗಳ ಮೇಲೆ ಬರೆಯಬಹುದು.
• ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ಸಂಭಾವ್ಯವಾಗಿ ಸಾಧ್ಯವಿದೆ, ಆದರೆ ನಾವು ಅದನ್ನು ಮಾಡುವುದಿಲ್ಲ. ಮೂಲಕ ಸಂಪನ್ಮೂಲ ಸಂರಚನಾ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಸಂರಚಿಸಲು ಸಹ ಸಾಧ್ಯವಿದೆ tflint. ಆದಾಗ್ಯೂ, ಅಲ್ಲಿನ ಚೆಕ್‌ಗಳು ಟೆರಾಫಾರ್ಮ್‌ಗೆ ತುಂಬಾ ಮೂಲಭೂತವಾಗಿವೆ, ಆದರೆ ಅನೇಕ ಪರೀಕ್ಷಾ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು AWS ಗಾಗಿ ಬರೆಯಲಾಗಿದೆ. ಮತ್ತು ನಾವು ಅಜೂರ್‌ನಲ್ಲಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಇದು ಮತ್ತೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ.
• ಕಾಂಪೊನೆಂಟ್ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳು: ನೀವು ಅವುಗಳನ್ನು ಹೇಗೆ ವರ್ಗೀಕರಿಸುತ್ತೀರಿ ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ಎಲ್ಲಿ ಇರಿಸುತ್ತೀರಿ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಆದರೆ ಅವರು ಮೂಲತಃ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ.

  ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳು ಈ ರೀತಿ ಕಾಣುತ್ತವೆ.

  
  
  ಡ್ರೋನ್ CI ನಲ್ಲಿ ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸುವಾಗ ಇದು ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಅವುಗಳನ್ನು ತಲುಪಲು, ಪ್ಯಾಕರ್ ಚಿತ್ರವು ರೂಪುಗೊಳ್ಳಲು ನೀವು 30 ನಿಮಿಷ ಕಾಯಬೇಕು, ನಂತರ ಅವುಗಳು ಹಾದುಹೋಗಲು ಇನ್ನೊಂದು 15 ನಿಮಿಷ ಕಾಯಬೇಕು. ಆದರೆ ಅವು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ!

  ಚಿತ್ರ ಪರಿಶೀಲನೆ ಅಲ್ಗಾರಿದಮ್

  1. ಪ್ಯಾಕರ್ ಮೊದಲು ಚಿತ್ರವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸಿದ್ಧಪಡಿಸಬೇಕು.
  2. ಪರೀಕ್ಷೆಯ ಪಕ್ಕದಲ್ಲಿ ಸ್ಥಳೀಯ ರಾಜ್ಯದೊಂದಿಗೆ ಟೆರಾಫಾರ್ಮ್ ಇದೆ, ಅದನ್ನು ನಾವು ಈ ಚಿತ್ರವನ್ನು ನಿಯೋಜಿಸಲು ಬಳಸುತ್ತೇವೆ.
  3. ತೆರೆದುಕೊಳ್ಳುವಾಗ, ಚಿತ್ರದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸುಲಭವಾಗುವಂತೆ ಹತ್ತಿರದಲ್ಲಿರುವ ಸಣ್ಣ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
  4. ಚಿತ್ರದಿಂದ VM ಅನ್ನು ನಿಯೋಜಿಸಿದ ನಂತರ, ಪರಿಶೀಲನೆಗಳು ಪ್ರಾರಂಭವಾಗಬಹುದು. ಮೂಲಭೂತವಾಗಿ, ತಪಾಸಣೆಗಳನ್ನು ಕಾರಿನ ಮೂಲಕ ನಡೆಸಲಾಗುತ್ತದೆ. ಪ್ರಾರಂಭದಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಡೀಮನ್‌ಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಇದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಇದನ್ನು ಮಾಡಲು, ssh ಅಥವಾ winrm ಮೂಲಕ ನಾವು ಹೊಸದಾಗಿ ಬೆಳೆದ ಯಂತ್ರಕ್ಕೆ ಲಾಗ್ ಇನ್ ಆಗುತ್ತೇವೆ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಅಥವಾ ಸೇವೆಗಳು ಅಪ್ ಆಗಿವೆಯೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.

• ಟೆರಾಫಾರ್ಮ್‌ಗಾಗಿ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿನ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಪರಿಸ್ಥಿತಿಯು ಹೋಲುತ್ತದೆ. ಅಂತಹ ಪರೀಕ್ಷೆಗಳ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ವಿವರಿಸುವ ಚಿಕ್ಕ ಕೋಷ್ಟಕ ಇಲ್ಲಿದೆ.

  
  
  ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆ ಸುಮಾರು 40 ನಿಮಿಷಗಳು. ಎಲ್ಲವೂ ಬಹಳ ಸಮಯದವರೆಗೆ ನಡೆಯುತ್ತದೆ. ಇದನ್ನು ಹಿಂಜರಿತಕ್ಕೆ ಬಳಸಬಹುದು, ಆದರೆ ಹೊಸ ಅಭಿವೃದ್ಧಿಗೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಅವಾಸ್ತವಿಕವಾಗಿದೆ. ಇದಕ್ಕಾಗಿ ನೀವು ತುಂಬಾ ಸಿದ್ಧರಾಗಿದ್ದರೆ, ಚಾಲನೆಯಲ್ಲಿರುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ತಯಾರಿಸಿ, ನಂತರ ನೀವು ಅದನ್ನು 10 ನಿಮಿಷಗಳಿಗೆ ಕಡಿಮೆ ಮಾಡಬಹುದು. ಆದರೆ ಇವು ಇನ್ನೂ 5 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 100 ತುಣುಕುಗಳನ್ನು ಮಾಡುವ ಘಟಕ ಪರೀಕ್ಷೆಗಳಲ್ಲ.

ಚಿತ್ರಗಳು ಅಥವಾ ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಜೋಡಿಸುವಾಗ ಯುನಿಟ್ ಪರೀಕ್ಷೆಗಳ ಅನುಪಸ್ಥಿತಿಯು ಕೆಲಸವನ್ನು REST ಮೂಲಕ ಅಥವಾ ಪೈಥಾನ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಮೂಲಕ ಸರಳವಾಗಿ ಚಲಾಯಿಸಬಹುದಾದ ಪ್ರತ್ಯೇಕ ಸೇವೆಗಳಿಗೆ ವರ್ಗಾಯಿಸಲು ಪ್ರೋತ್ಸಾಹಿಸುತ್ತದೆ.

ಉದಾಹರಣೆಗೆ, ವರ್ಚುವಲ್ ಯಂತ್ರವು ಪ್ರಾರಂಭವಾದಾಗ, ಅದು ಸೇವೆಯಲ್ಲಿ ಸ್ವತಃ ನೋಂದಾಯಿಸುತ್ತದೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು ಸ್ಕೇಲ್ಎಫ್ಟಿ, ಮತ್ತು ವರ್ಚುವಲ್ ಯಂತ್ರವು ನಾಶವಾದಾಗ, ಅದು ಸ್ವತಃ ಅಳಿಸಲ್ಪಟ್ಟಿದೆ.

ನಾವು ScaleFT ಅನ್ನು ಸೇವೆಯಾಗಿ ಹೊಂದಿರುವುದರಿಂದ, API ಮೂಲಕ ನಾವು ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಒತ್ತಾಯಿಸುತ್ತೇವೆ. ಅಲ್ಲಿ ನೀವು ಎಳೆದುಕೊಂಡು ಹೇಳಬಹುದಾದ ಒಂದು ಹೊದಿಕೆಯನ್ನು ಬರೆಯಲಾಗಿತ್ತು: "ಒಳಗೆ ಹೋಗಿ ಇದನ್ನು ಮತ್ತು ಅದನ್ನು ಅಳಿಸಿ." ಇದು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಪ್ರವೇಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.

ಇದಕ್ಕಾಗಿ ನಾವು ಈಗಾಗಲೇ ಸಾಮಾನ್ಯ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಬಹುದು, ಏಕೆಂದರೆ ಇದು ಸಾಮಾನ್ಯ ಸಾಫ್ಟ್‌ವೇರ್‌ನಿಂದ ಭಿನ್ನವಾಗಿಲ್ಲ: ಕೆಲವು ರೀತಿಯ ಅಪಿಹಾವನ್ನು ಅಪಹಾಸ್ಯ ಮಾಡಲಾಗಿದೆ, ನೀವು ಅದನ್ನು ಎಳೆಯಿರಿ ಮತ್ತು ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡಿ.

ಪರೀಕ್ಷೆಗಳ ಫಲಿತಾಂಶಗಳು: ಒಂದು ನಿಮಿಷದಲ್ಲಿ OS ಅನ್ನು ನೀಡಬೇಕಾದ ಘಟಕ ಪರೀಕ್ಷೆಯು ಅದನ್ನು ನೀಡುವುದಿಲ್ಲ. ಮತ್ತು ಪಿರಮಿಡ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಪರೀಕ್ಷೆಯ ವಿಧಗಳು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತವೆ, ಆದರೆ ಸಮಸ್ಯೆಗಳ ಭಾಗವನ್ನು ಮಾತ್ರ ಒಳಗೊಳ್ಳುತ್ತವೆ.

ಜೋಡಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್

ಪರೀಕ್ಷೆಗಳು, ಸಹಜವಾಗಿ, ಒಳ್ಳೆಯದು. ನೀವು ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಬರೆಯಬಹುದು, ಅವು ವಿಭಿನ್ನ ಪ್ರಕಾರಗಳಾಗಿರಬಹುದು. ಅವರು ತಮ್ಮ ಮಟ್ಟದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ನಮಗೆ ಪ್ರತಿಕ್ರಿಯೆ ನೀಡುತ್ತಾರೆ. ಆದರೆ ಅತ್ಯಂತ ವೇಗವಾದ OS ಅನ್ನು ನೀಡುವ ಕೆಟ್ಟ ಘಟಕ ಪರೀಕ್ಷೆಗಳ ಸಮಸ್ಯೆಯು ಉಳಿದಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾನು ಇನ್ನೂ ವೇಗದ ಓಎಸ್ ಅನ್ನು ಬಯಸುತ್ತೇನೆ ಅದು ಕೆಲಸ ಮಾಡಲು ಸುಲಭ ಮತ್ತು ಆಹ್ಲಾದಕರವಾಗಿರುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ ಪರಿಹಾರದ ಗುಣಮಟ್ಟವನ್ನು ನಮೂದಿಸಬಾರದು. ಅದೃಷ್ಟವಶಾತ್, ಯುನಿಟ್ ಪರೀಕ್ಷೆಗಳಿಗಿಂತಲೂ ವೇಗವಾದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಒದಗಿಸುವ ತಂತ್ರಗಳಿವೆ. ಇದು ಜೋಡಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಆಗಿದೆ.

ಕೋಡ್ ಬರೆಯುವಾಗ, ನೀವು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಅದರ ಗುಣಮಟ್ಟದ ಬಗ್ಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತೀರಿ. ಹೌದು, ನೀವು ಎಲ್ಲವನ್ನೂ ವೈಶಿಷ್ಟ್ಯದ ಶಾಖೆಯಲ್ಲಿ ಬರೆಯಬಹುದು (ಯಾರಿಗೂ ಏನನ್ನೂ ಮುರಿಯದಂತೆ), ಗಿಥಬ್‌ನಲ್ಲಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ಮಾಡಿ, ಯಾರ ಅಭಿಪ್ರಾಯವನ್ನು ಹೊಂದಿರುವವರಿಗೆ ಅದನ್ನು ನಿಯೋಜಿಸಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯಿರಿ.

ಆದರೆ ನೀವು ಬಹಳ ಸಮಯ ಕಾಯಬಹುದು. ಜನರೆಲ್ಲರೂ ಕಾರ್ಯನಿರತರಾಗಿದ್ದಾರೆ ಮತ್ತು ಉತ್ತರವು ಒಂದು ಇದ್ದರೂ ಸಹ ಅತ್ಯುನ್ನತ ಗುಣಮಟ್ಟವನ್ನು ಹೊಂದಿರದಿರಬಹುದು. ಉತ್ತರವು ತಕ್ಷಣವೇ ಬಂದಿತು ಎಂದು ಭಾವಿಸೋಣ, ವಿಮರ್ಶಕನು ಸಂಪೂರ್ಣ ಕಲ್ಪನೆಯನ್ನು ತಕ್ಷಣವೇ ಅರ್ಥಮಾಡಿಕೊಂಡನು, ಆದರೆ ಉತ್ತರವು ಇನ್ನೂ ತಡವಾಗಿ ಬರುತ್ತದೆ. ಇದು ಮುಂಚೆಯೇ ಇರಬೇಕೆಂದು ನಾನು ಬಯಸುತ್ತೇನೆ. ಈ ಜೋಡಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಗುರಿಯನ್ನು ಹೊಂದಿದೆ - ಈಗಿನಿಂದಲೇ, ಬರೆಯುವ ಸಮಯದಲ್ಲಿ.

ಜೋಡಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಶೈಲಿಗಳು ಮತ್ತು IaC ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಲ್ಲಿ ಅವುಗಳ ಅನ್ವಯಿಕತೆಯನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ:

1. ಕ್ಲಾಸಿಕ್, ಅನುಭವಿ+ಅನುಭವಿ, ಟೈಮರ್ ಮೂಲಕ ಶಿಫ್ಟ್. ಎರಡು ಪಾತ್ರಗಳು - ಚಾಲಕ ಮತ್ತು ನ್ಯಾವಿಗೇಟರ್. ಇಬ್ಬರು ವ್ಯಕ್ತಿಗಳು. ಅವರು ಒಂದೇ ಕೋಡ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಪೂರ್ವನಿರ್ಧರಿತ ಅವಧಿಯ ನಂತರ ಪಾತ್ರಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತಾರೆ.

ಶೈಲಿಯೊಂದಿಗೆ ನಮ್ಮ ಸಮಸ್ಯೆಗಳ ಹೊಂದಾಣಿಕೆಯನ್ನು ಪರಿಗಣಿಸೋಣ:

• ಸಮಸ್ಯೆ: ಕೋಡ್ ಅಭಿವೃದ್ಧಿಗಾಗಿ ಉಪಕರಣಗಳು ಮತ್ತು ಸಾಧನಗಳ ಅಪೂರ್ಣತೆ.
  ಋಣಾತ್ಮಕ ಪರಿಣಾಮ: ಇದು ಅಭಿವೃದ್ಧಿ ಹೊಂದಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ನಾವು ನಿಧಾನಗೊಳಿಸುತ್ತೇವೆ, ಕೆಲಸದ ವೇಗ / ಲಯ ಕಳೆದುಹೋಗುತ್ತದೆ.
  ನಾವು ಹೇಗೆ ಹೋರಾಡುತ್ತೇವೆ: ನಾವು ವಿಭಿನ್ನ ಸಾಧನವನ್ನು ಬಳಸುತ್ತೇವೆ, ಸಾಮಾನ್ಯ IDE ಮತ್ತು ಶಾರ್ಟ್‌ಕಟ್‌ಗಳನ್ನು ಕಲಿಯುತ್ತೇವೆ.
• ಸಮಸ್ಯೆ: ನಿಧಾನ ನಿಯೋಜನೆ.
  ಋಣಾತ್ಮಕ ಪರಿಣಾಮ: ಕೋಡ್‌ನ ಕೆಲಸದ ತುಣುಕನ್ನು ರಚಿಸಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಕಾಯುವಾಗ ನಮಗೆ ಬೇಸರವಾಗುತ್ತದೆ, ಕಾಯುವಾಗ ನಮ್ಮ ಕೈಗಳು ಬೇರೆ ಏನಾದರೂ ಮಾಡಲು ಚಾಚುತ್ತವೆ.
  ನಾವು ಹೇಗೆ ಹೋರಾಡುತ್ತೇವೆ: ನಾವು ಅದನ್ನು ಜಯಿಸಲಿಲ್ಲ.
• ಸಮಸ್ಯೆ: ವಿಧಾನಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳ ಕೊರತೆ.
  ಋಣಾತ್ಮಕ ಪರಿಣಾಮ: ಅದನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡುವುದು ಮತ್ತು ಕಳಪೆಯಾಗಿ ಮಾಡುವುದು ಹೇಗೆ ಎಂಬುದರ ಬಗ್ಗೆ ಯಾವುದೇ ಜ್ಞಾನವಿಲ್ಲ. ಪ್ರತಿಕ್ರಿಯೆಯ ಸ್ವೀಕೃತಿಯನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ.
  ನಾವು ಹೇಗೆ ಹೋರಾಡುತ್ತೇವೆ: ಜೋಡಿ ಕೆಲಸದಲ್ಲಿ ಅಭಿಪ್ರಾಯಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳ ಪರಸ್ಪರ ವಿನಿಮಯವು ಬಹುತೇಕ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

IaC ನಲ್ಲಿ ಈ ಶೈಲಿಯನ್ನು ಬಳಸುವ ಮುಖ್ಯ ಸಮಸ್ಯೆ ಕೆಲಸದ ಅಸಮ ವೇಗವಾಗಿದೆ. ಸಾಂಪ್ರದಾಯಿಕ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ, ನೀವು ಏಕರೂಪದ ಚಲನೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ. ನೀವು ಐದು ನಿಮಿಷಗಳನ್ನು ಕಳೆಯಬಹುದು ಮತ್ತು ಎನ್ ಬರೆಯಬಹುದು. 10 ನಿಮಿಷಗಳನ್ನು ಕಳೆಯಿರಿ ಮತ್ತು 2N, 15 ನಿಮಿಷಗಳು - 3N ಬರೆಯಿರಿ. ಇಲ್ಲಿ ನೀವು ಐದು ನಿಮಿಷಗಳನ್ನು ಕಳೆಯಬಹುದು ಮತ್ತು N ಎಂದು ಬರೆಯಬಹುದು, ತದನಂತರ ಇನ್ನೊಂದು 30 ನಿಮಿಷಗಳನ್ನು ಕಳೆಯಬಹುದು ಮತ್ತು N ನ ಹತ್ತನೇ ಭಾಗವನ್ನು ಬರೆಯಬಹುದು. ಇಲ್ಲಿ ನಿಮಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ, ನೀವು ಸಿಲುಕಿಕೊಂಡಿದ್ದೀರಿ, ಮೂರ್ಖರಾಗಿದ್ದೀರಿ. ತನಿಖೆಯು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಿಂದ ಗಮನವನ್ನು ಸೆಳೆಯುತ್ತದೆ.

ತೀರ್ಮಾನ: ಅದರ ಶುದ್ಧ ರೂಪದಲ್ಲಿ ಅದು ನಮಗೆ ಸೂಕ್ತವಲ್ಲ.

2. ಪಿಂಗ್-ಪಾಂಗ್. ಈ ವಿಧಾನವು ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಬ್ಬರು ಅದರ ಅನುಷ್ಠಾನವನ್ನು ಮಾಡುತ್ತಾರೆ. ಯುನಿಟ್ ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಎಲ್ಲವೂ ಜಟಿಲವಾಗಿದೆ ಎಂಬ ಅಂಶವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ನೀವು ಏಕೀಕರಣ ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯಬೇಕು, ಅದು ಪ್ರೋಗ್ರಾಂಗೆ ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಪಿಂಗ್-ಪಾಂಗ್ನ ಎಲ್ಲಾ ಸುಲಭತೆ ದೂರ ಹೋಗುತ್ತದೆ.

ಪರೀಕ್ಷಾ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು ಮತ್ತು ಅದಕ್ಕೆ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾವು ಜವಾಬ್ದಾರಿಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ ಎಂದು ನಾನು ಹೇಳಬಲ್ಲೆ. ಒಬ್ಬ ಭಾಗವಹಿಸುವವರು ಸ್ಕ್ರಿಪ್ಟ್‌ನೊಂದಿಗೆ ಬಂದರು, ಕೆಲಸದ ಈ ಭಾಗದಲ್ಲಿ ಅವರು ಜವಾಬ್ದಾರರಾಗಿದ್ದರು, ಅವರು ಕೊನೆಯ ಪದವನ್ನು ಹೊಂದಿದ್ದರು. ಮತ್ತು ಇನ್ನೊಬ್ಬರು ಅನುಷ್ಠಾನಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗಿದ್ದರು. ಇದು ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ. ಈ ವಿಧಾನದಿಂದ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಗುಣಮಟ್ಟ ಹೆಚ್ಚಾಗುತ್ತದೆ.

ತೀರ್ಮಾನ: ಅಯ್ಯೋ, ಕೆಲಸದ ವೇಗವು IaC ನಲ್ಲಿ ಜೋಡಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಅಭ್ಯಾಸವಾಗಿ ಪಿಂಗ್-ಪಾಂಗ್ ಅನ್ನು ಬಳಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ.

3.ಸ್ಟ್ರಾಂಗ್ ಸ್ಟೈಲ್. ಕಷ್ಟ ಅಭ್ಯಾಸ. ಒಬ್ಬ ಭಾಗವಹಿಸುವವರು ಡೈರೆಕ್ಟಿವ್ ನ್ಯಾವಿಗೇಟರ್ ಆಗುತ್ತಾರೆ ಮತ್ತು ಎರಡನೆಯವರು ಮರಣದಂಡನೆ ಚಾಲಕನ ಪಾತ್ರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ ಎಂಬುದು ಕಲ್ಪನೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಹಕ್ಕು ನ್ಯಾವಿಗೇಟರ್ನೊಂದಿಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರುತ್ತದೆ. ಡ್ರೈವರ್ ಮಾತ್ರ ಮುದ್ರಿಸುತ್ತದೆ ಮತ್ತು ಪದದೊಂದಿಗೆ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದರ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಬಹುದು. ಪಾತ್ರಗಳು ದೀರ್ಘಕಾಲದವರೆಗೆ ಬದಲಾಗುವುದಿಲ್ಲ.

ಕಲಿಕೆಗೆ ಒಳ್ಳೆಯದು, ಆದರೆ ಬಲವಾದ ಮೃದು ಕೌಶಲ್ಯಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. ಇಲ್ಲಿಯೇ ನಾವು ಎಡವಿದ್ದೇವೆ. ತಂತ್ರವು ಕಷ್ಟಕರವಾಗಿತ್ತು. ಮತ್ತು ಇದು ಮೂಲಸೌಕರ್ಯಗಳ ಬಗ್ಗೆಯೂ ಅಲ್ಲ.

ತೀರ್ಮಾನ: ಇದನ್ನು ಸಮರ್ಥವಾಗಿ ಬಳಸಬಹುದು, ನಾವು ಪ್ರಯತ್ನವನ್ನು ಬಿಡುವುದಿಲ್ಲ.

4. ಮೊಬಿಂಗ್, ಸ್ವರ್ಮಿಂಗ್ ಮತ್ತು ಎಲ್ಲಾ ತಿಳಿದಿರುವ ಆದರೆ ಪಟ್ಟಿ ಮಾಡದ ಶೈಲಿಗಳು ನಾವು ಅದನ್ನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಅದನ್ನು ಪ್ರಯತ್ನಿಸಲಿಲ್ಲ ಮತ್ತು ನಮ್ಮ ಕೆಲಸದ ಸಂದರ್ಭದಲ್ಲಿ ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಅಸಾಧ್ಯ.

ಜೋಡಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಅನ್ನು ಬಳಸುವ ಸಾಮಾನ್ಯ ಫಲಿತಾಂಶಗಳು:

• ನಾವು ಕೆಲಸದ ಅಸಮ ವೇಗವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇದು ಗೊಂದಲಮಯವಾಗಿದೆ.
• ನಾವು ಸಾಕಷ್ಟು ಉತ್ತಮ ಮೃದು ಕೌಶಲ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ವಿಷಯದ ಪ್ರದೇಶವು ನಮ್ಮ ಈ ನ್ಯೂನತೆಗಳನ್ನು ನಿವಾರಿಸಲು ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.
• ದೀರ್ಘ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಉಪಕರಣಗಳೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳು ಜೋಡಿಯಾಗಿ ಅಭಿವೃದ್ಧಿಯನ್ನು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ.

5. ಇದರ ಹೊರತಾಗಿಯೂ, ಯಶಸ್ಸುಗಳು ಇದ್ದವು. ನಾವು ನಮ್ಮದೇ ಆದ "ಒಮ್ಮುಖ - ಡೈವರ್ಜೆನ್ಸ್" ವಿಧಾನವನ್ನು ತಂದಿದ್ದೇವೆ. ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ.

ನಾವು ಕೆಲವು ದಿನಗಳವರೆಗೆ (ಒಂದು ವಾರಕ್ಕಿಂತ ಕಡಿಮೆ) ಶಾಶ್ವತ ಪಾಲುದಾರರನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಒಟ್ಟಿಗೆ ಒಂದು ಕೆಲಸವನ್ನು ಮಾಡುತ್ತೇವೆ. ನಾವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಒಟ್ಟಿಗೆ ಕುಳಿತುಕೊಳ್ಳುತ್ತೇವೆ: ಒಬ್ಬರು ಬರೆಯುತ್ತಾರೆ, ಇನ್ನೊಬ್ಬರು ಕುಳಿತು ಬೆಂಬಲ ತಂಡವನ್ನು ವೀಕ್ಷಿಸುತ್ತಾರೆ. ನಂತರ ನಾವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಚದುರಿಹೋಗುತ್ತೇವೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಕೆಲವು ಸ್ವತಂತ್ರ ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತಾರೆ, ನಂತರ ನಾವು ಮತ್ತೆ ಒಟ್ಟಿಗೆ ಬರುತ್ತೇವೆ, ಬೇಗನೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತೇವೆ, ಒಟ್ಟಿಗೆ ಏನಾದರೂ ಮಾಡಿ ಮತ್ತು ಮತ್ತೆ ಚದುರಿಹೋಗುತ್ತೇವೆ.

ಯೋಜನೆ ಮತ್ತು ಸಂವಹನ

ಓಎಸ್ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಅಭ್ಯಾಸಗಳ ಕೊನೆಯ ಬ್ಲಾಕ್ ಕಾರ್ಯಗಳೊಂದಿಗೆ ಕೆಲಸದ ಸಂಘಟನೆಯಾಗಿದೆ. ಇದು ಜೋಡಿ ಕೆಲಸದ ಹೊರಗಿನ ಅನುಭವದ ವಿನಿಮಯವನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ. ಮೂರು ಅಭ್ಯಾಸಗಳನ್ನು ನೋಡೋಣ:

1. ಗುರಿ ಮರದ ಮೂಲಕ ಉದ್ದೇಶಗಳು. ಭವಿಷ್ಯದಲ್ಲಿ ಅಂತ್ಯವಿಲ್ಲದೆ ಹೋಗುವ ಮರದ ಮೂಲಕ ನಾವು ಯೋಜನೆಯ ಒಟ್ಟಾರೆ ನಿರ್ವಹಣೆಯನ್ನು ಆಯೋಜಿಸಿದ್ದೇವೆ. ತಾಂತ್ರಿಕವಾಗಿ, ಟ್ರ್ಯಾಕಿಂಗ್ ಅನ್ನು ಮಿರೊದಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ. ಒಂದು ಕಾರ್ಯವಿದೆ - ಇದು ಮಧ್ಯಂತರ ಗುರಿಯಾಗಿದೆ. ಅದರಿಂದ ಸಣ್ಣ ಗುರಿಗಳು ಅಥವಾ ಕಾರ್ಯಗಳ ಗುಂಪುಗಳು ಹೋಗುತ್ತವೆ. ಕಾರ್ಯಗಳು ಅವರಿಂದಲೇ ಬರುತ್ತವೆ. ಈ ಮಂಡಳಿಯಲ್ಲಿ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ.

ಈ ಯೋಜನೆಯು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಹ ನೀಡುತ್ತದೆ, ಇದು ನಾವು ರ್ಯಾಲಿಗಳಲ್ಲಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದಾಗ ದಿನಕ್ಕೆ ಒಮ್ಮೆ ಸಂಭವಿಸುತ್ತದೆ. ಎಲ್ಲರ ಮುಂದೆ ಒಂದು ಸಾಮಾನ್ಯ ಯೋಜನೆಯನ್ನು ಹೊಂದಿರುವುದು, ಆದರೆ ರಚನಾತ್ಮಕ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ತೆರೆದಿರುವುದು, ಏನಾಗುತ್ತಿದೆ ಮತ್ತು ನಾವು ಎಷ್ಟು ಪ್ರಗತಿ ಸಾಧಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಬಗ್ಗೆ ಎಲ್ಲರಿಗೂ ತಿಳಿದಿರುವಂತೆ ಮಾಡುತ್ತದೆ.

ಕಾರ್ಯಗಳ ದೃಷ್ಟಿಗೋಚರ ದೃಷ್ಟಿಯ ಪ್ರಯೋಜನಗಳು:

• ಕಾರಣತ್ವ. ಪ್ರತಿಯೊಂದು ಕಾರ್ಯವು ಕೆಲವು ಜಾಗತಿಕ ಗುರಿಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಕಾರ್ಯಗಳನ್ನು ಸಣ್ಣ ಗುರಿಗಳಾಗಿ ವರ್ಗೀಕರಿಸಲಾಗಿದೆ. ಮೂಲಸೌಕರ್ಯ ಡೊಮೇನ್ ಸ್ವತಃ ಸಾಕಷ್ಟು ತಾಂತ್ರಿಕವಾಗಿದೆ. ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಪರಿಣಾಮವು ಯಾವಾಗಲೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, ಮತ್ತೊಂದು nginx ಗೆ ವಲಸೆ ಹೋಗುವಾಗ ರನ್‌ಬುಕ್ ಬರೆಯುವುದು ವ್ಯವಹಾರದ ಮೇಲೆ ಬೀರುತ್ತದೆ. ಟಾರ್ಗೆಟ್ ಕಾರ್ಡ್ ಹತ್ತಿರದಲ್ಲಿರುವುದು ಅದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ.
  
  ಕಾರಣವು ಸಮಸ್ಯೆಗಳ ಪ್ರಮುಖ ಆಸ್ತಿಯಾಗಿದೆ. ಇದು ನೇರವಾಗಿ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: "ನಾನು ಸರಿಯಾದ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿದ್ದೇನೆಯೇ?"
• ಸಮಾನಾಂತರತೆ. ನಮ್ಮಲ್ಲಿ ಒಂಬತ್ತು ಮಂದಿ ಇದ್ದಾರೆ ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರನ್ನು ಒಂದೇ ಕಾರ್ಯದಲ್ಲಿ ಎಸೆಯುವುದು ದೈಹಿಕವಾಗಿ ಅಸಾಧ್ಯ. ಒಂದು ಪ್ರದೇಶದಿಂದ ಕಾರ್ಯಗಳು ಯಾವಾಗಲೂ ಸಾಕಾಗುವುದಿಲ್ಲ. ಸಣ್ಣ ಕೆಲಸದ ಗುಂಪುಗಳ ನಡುವೆ ಕೆಲಸವನ್ನು ಸಮಾನಾಂತರಗೊಳಿಸಲು ನಾವು ಒತ್ತಾಯಿಸಲ್ಪಟ್ಟಿದ್ದೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಗುಂಪುಗಳು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ತಮ್ಮ ಕಾರ್ಯದಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳುತ್ತವೆ, ಅವರು ಬೇರೆಯವರಿಂದ ಬಲಪಡಿಸಬಹುದು. ಕೆಲವೊಮ್ಮೆ ಜನರು ಈ ಕೆಲಸದ ಗುಂಪಿನಿಂದ ದೂರ ಹೋಗುತ್ತಾರೆ. ಯಾರಾದರೂ ರಜೆಯ ಮೇಲೆ ಹೋಗುತ್ತಾರೆ, ಯಾರಾದರೂ DevOps conf ಗಾಗಿ ವರದಿ ಮಾಡುತ್ತಾರೆ, ಯಾರಾದರೂ Habr ನಲ್ಲಿ ಲೇಖನವನ್ನು ಬರೆಯುತ್ತಾರೆ. ಯಾವ ಗುರಿಗಳು ಮತ್ತು ಕಾರ್ಯಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯವಾಗುತ್ತದೆ.

2. ಬೆಳಿಗ್ಗೆ ಸಭೆಗಳ ಬದಲಿ ನಿರೂಪಕರು. ಸ್ಟ್ಯಾಂಡ್-ಅಪ್‌ಗಳಲ್ಲಿ ನಮಗೆ ಈ ಸಮಸ್ಯೆ ಇದೆ - ಜನರು ಸಮಾನಾಂತರವಾಗಿ ಅನೇಕ ಕಾರ್ಯಗಳನ್ನು ಮಾಡುತ್ತಾರೆ. ಕೆಲವೊಮ್ಮೆ ಕಾರ್ಯಗಳು ಸಡಿಲವಾಗಿ ಸಂಪರ್ಕಗೊಂಡಿರುತ್ತವೆ ಮತ್ತು ಯಾರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದರ ಬಗ್ಗೆ ಯಾವುದೇ ತಿಳುವಳಿಕೆ ಇರುವುದಿಲ್ಲ. ಮತ್ತು ತಂಡದ ಇನ್ನೊಬ್ಬ ಸದಸ್ಯರ ಅಭಿಪ್ರಾಯವು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ. ಇದು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಹಾದಿಯನ್ನು ಬದಲಾಯಿಸಬಹುದಾದ ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯಾಗಿದೆ. ಸಹಜವಾಗಿ, ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮೊಂದಿಗೆ ಯಾರಾದರೂ ಇದ್ದಾರೆ, ಆದರೆ ಸಲಹೆ ಮತ್ತು ಸಲಹೆಗಳು ಯಾವಾಗಲೂ ಉಪಯುಕ್ತವಾಗಿವೆ.

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

3. ಆಂತರಿಕ ಡೆಮೊ. ಜೋಡಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಿಂದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಲ್ಲಿ ಸಹಾಯ, ಸಮಸ್ಯೆಯ ಮರದ ಮೇಲೆ ದೃಶ್ಯೀಕರಣ ಮತ್ತು ಬೆಳಿಗ್ಗೆ ಸ್ಕ್ರಮ್ ಸಭೆಗಳಲ್ಲಿ ಸಹಾಯ ಮಾಡುವುದು ಒಳ್ಳೆಯದು, ಆದರೆ ಸೂಕ್ತವಲ್ಲ. ದಂಪತಿಗಳಾಗಿ, ನಿಮ್ಮ ಜ್ಞಾನದಿಂದ ಮಾತ್ರ ನೀವು ಸೀಮಿತವಾಗಿರುತ್ತೀರಿ. ಟಾಸ್ಕ್ ಟ್ರೀ ಜಾಗತಿಕವಾಗಿ ಯಾರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಮತ್ತು ಬೆಳಗಿನ ಸಭೆಯಲ್ಲಿ ಪ್ರೆಸೆಂಟರ್ ಮತ್ತು ಸಹೋದ್ಯೋಗಿಗಳು ನಿಮ್ಮ ಸಮಸ್ಯೆಗಳಿಗೆ ಆಳವಾಗಿ ಧುಮುಕುವುದಿಲ್ಲ. ಅವರು ಖಂಡಿತವಾಗಿಯೂ ಏನನ್ನಾದರೂ ಕಳೆದುಕೊಳ್ಳಬಹುದು.

ಒಬ್ಬರಿಗೊಬ್ಬರು ಮಾಡಿದ ಕೆಲಸವನ್ನು ಪ್ರದರ್ಶಿಸಿ ನಂತರ ಚರ್ಚಿಸುವುದರಲ್ಲಿ ಪರಿಹಾರ ಕಂಡುಬಂದಿದೆ. ನಾವು ವಾರಕ್ಕೊಮ್ಮೆ ಒಂದು ಗಂಟೆಗೆ ಭೇಟಿಯಾಗುತ್ತೇವೆ ಮತ್ತು ಕಳೆದ ವಾರದಲ್ಲಿ ನಾವು ಮಾಡಿದ ಕಾರ್ಯಗಳಿಗೆ ಪರಿಹಾರಗಳ ವಿವರಗಳನ್ನು ತೋರಿಸುತ್ತೇವೆ.

ಪ್ರದರ್ಶನದ ಸಮಯದಲ್ಲಿ, ಕಾರ್ಯದ ವಿವರಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದು ಅವಶ್ಯಕ ಮತ್ತು ಅದರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪ್ರದರ್ಶಿಸಲು ಮರೆಯದಿರಿ.

ಪರಿಶೀಲನಾಪಟ್ಟಿಯನ್ನು ಬಳಸಿಕೊಂಡು ವರದಿಯನ್ನು ನಡೆಸಬಹುದು.1. ಸಂದರ್ಭವನ್ನು ನಮೂದಿಸಿ. ಕಾರ್ಯ ಎಲ್ಲಿಂದ ಬಂತು, ಅದು ಏಕೆ ಅಗತ್ಯವಾಗಿತ್ತು?

2. ಸಮಸ್ಯೆಯನ್ನು ಮೊದಲು ಹೇಗೆ ಪರಿಹರಿಸಲಾಯಿತು? ಉದಾಹರಣೆಗೆ, ಬೃಹತ್ ಮೌಸ್ ಕ್ಲಿಕ್ ಮಾಡುವ ಅಗತ್ಯವಿದೆ, ಅಥವಾ ಏನನ್ನೂ ಮಾಡಲು ಅಸಾಧ್ಯವಾಗಿತ್ತು.

3. ನಾವು ಅದನ್ನು ಹೇಗೆ ಸುಧಾರಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ: "ನೋಡಿ, ಈಗ ಸ್ಕ್ರಿಪ್ಟೋಸಿಕ್ ಇದೆ, ಇಲ್ಲಿ ಓದುವಿಕೆ ಇದೆ."

4. ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸಿ. ಕೆಲವು ಬಳಕೆದಾರರ ಸನ್ನಿವೇಶವನ್ನು ನೇರವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ. ನನಗೆ X ಬೇಕು, ನಾನು Y ಮಾಡುತ್ತೇನೆ, ನಾನು Y (ಅಥವಾ Z) ಅನ್ನು ನೋಡುತ್ತೇನೆ. ಉದಾಹರಣೆಗೆ, ನಾನು NGINX ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೇನೆ, url ಅನ್ನು ಧೂಮಪಾನ ಮಾಡುತ್ತೇನೆ ಮತ್ತು 200 ಸರಿ ಪಡೆಯುತ್ತೇನೆ. ಕ್ರಿಯೆಯು ದೀರ್ಘವಾಗಿದ್ದರೆ, ಅದನ್ನು ಮುಂಚಿತವಾಗಿ ತಯಾರಿಸಿ ಇದರಿಂದ ನೀವು ಅದನ್ನು ನಂತರ ತೋರಿಸಬಹುದು. ಡೆಮೊವು ದುರ್ಬಲವಾಗಿದ್ದರೆ, ಡೆಮೊಗೆ ಒಂದು ಗಂಟೆ ಮೊದಲು ಅದನ್ನು ಮುರಿಯದಿರುವುದು ಒಳ್ಳೆಯದು.

5. ಸಮಸ್ಯೆಯನ್ನು ಎಷ್ಟು ಯಶಸ್ವಿಯಾಗಿ ಪರಿಹರಿಸಲಾಗಿದೆ, ಯಾವ ತೊಂದರೆಗಳು ಉಳಿದಿವೆ, ಏನು ಪೂರ್ಣಗೊಂಡಿಲ್ಲ, ಭವಿಷ್ಯದಲ್ಲಿ ಯಾವ ಸುಧಾರಣೆಗಳು ಸಾಧ್ಯ ಎಂಬುದನ್ನು ವಿವರಿಸಿ. ಉದಾಹರಣೆಗೆ, ಈಗ CLI, ನಂತರ CI ನಲ್ಲಿ ಪೂರ್ಣ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಇರುತ್ತದೆ.

ಪ್ರತಿ ಸ್ಪೀಕರ್ ಅದನ್ನು 5-10 ನಿಮಿಷಗಳವರೆಗೆ ಇಡಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ. ನಿಮ್ಮ ಭಾಷಣವು ನಿಸ್ಸಂಶಯವಾಗಿ ಮಹತ್ವದ್ದಾಗಿದ್ದರೆ ಮತ್ತು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದ್ದರೆ, sre-ಟೇಕ್ ಓವರ್ ಚಾನಲ್‌ನಲ್ಲಿ ಇದನ್ನು ಮುಂಚಿತವಾಗಿ ಸಂಯೋಜಿಸಿ.

ಮುಖಾಮುಖಿ ಭಾಗದ ನಂತರ ಥ್ರೆಡ್ನಲ್ಲಿ ಯಾವಾಗಲೂ ಚರ್ಚೆ ಇರುತ್ತದೆ. ನಮ್ಮ ಕಾರ್ಯಗಳ ಬಗ್ಗೆ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಪ್ರತಿಕ್ರಿಯೆ ಕಾಣಿಸಿಕೊಳ್ಳುವುದು ಇಲ್ಲಿಯೇ.

ಪರಿಣಾಮವಾಗಿ, ಏನಾಗುತ್ತಿದೆ ಎಂಬುದರ ಉಪಯುಕ್ತತೆಯನ್ನು ನಿರ್ಧರಿಸಲು ಸಮೀಕ್ಷೆಯನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ. ಇದು ಭಾಷಣದ ಸಾರ ಮತ್ತು ಕಾರ್ಯದ ಮಹತ್ವದ ಬಗ್ಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿದೆ.

ದೀರ್ಘ ತೀರ್ಮಾನಗಳು ಮತ್ತು ಮುಂದಿನದು

ಲೇಖನದ ಟೋನ್ ಸ್ವಲ್ಪ ನಿರಾಶಾವಾದಿ ಎಂದು ತೋರುತ್ತದೆ. ಇದು ತಪ್ಪು. ಎರಡು ಕಡಿಮೆ ಮಟ್ಟದ ಪ್ರತಿಕ್ರಿಯೆ, ಅವುಗಳೆಂದರೆ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಜೋಡಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್, ಕೆಲಸ. ಸಾಂಪ್ರದಾಯಿಕ ಬೆಳವಣಿಗೆಯಂತೆ ಪರಿಪೂರ್ಣವಲ್ಲ, ಆದರೆ ಅದರಿಂದ ಧನಾತ್ಮಕ ಪರಿಣಾಮವಿದೆ.

ಪರೀಕ್ಷೆಗಳು, ಅವುಗಳ ಪ್ರಸ್ತುತ ರೂಪದಲ್ಲಿ, ಭಾಗಶಃ ಕೋಡ್ ವ್ಯಾಪ್ತಿಯನ್ನು ಮಾತ್ರ ಒದಗಿಸುತ್ತವೆ. ಅನೇಕ ಕಾನ್ಫಿಗರೇಶನ್ ಕಾರ್ಯಗಳು ಪರೀಕ್ಷಿಸದೆ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ಕೋಡ್ ಬರೆಯುವಾಗ ನಿಜವಾದ ಕೆಲಸದ ಮೇಲೆ ಅವರ ಪ್ರಭಾವ ಕಡಿಮೆಯಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳಿಂದ ಒಂದು ಪರಿಣಾಮವಿದೆ, ಮತ್ತು ಅವರು ನಿಮಗೆ ನಿರ್ಭಯವಾಗಿ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ಗಳನ್ನು ಕೈಗೊಳ್ಳಲು ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತಾರೆ. ಇದೊಂದು ದೊಡ್ಡ ಸಾಧನೆ. ಅಲ್ಲದೆ, ಉನ್ನತ ಮಟ್ಟದ ಭಾಷೆಗಳಲ್ಲಿ ಅಭಿವೃದ್ಧಿಯತ್ತ ಗಮನವನ್ನು ಬದಲಾಯಿಸುವುದರೊಂದಿಗೆ (ನಮ್ಮಲ್ಲಿ ಪೈಥಾನ್ ಇದೆ, ಹೋಗಿ), ಸಮಸ್ಯೆ ದೂರವಾಗುತ್ತದೆ. ಮತ್ತು "ಅಂಟು" ಗಾಗಿ ನಿಮಗೆ ಹೆಚ್ಚಿನ ತಪಾಸಣೆ ಅಗತ್ಯವಿಲ್ಲ; ಸಾಮಾನ್ಯ ಏಕೀಕರಣ ಪರಿಶೀಲನೆ ಸಾಕು.

ಜೋಡಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವುದು ನಿರ್ದಿಷ್ಟ ಜನರ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಟಾಸ್ಕ್ ಫ್ಯಾಕ್ಟರ್ ಮತ್ತು ನಮ್ಮ ಸಾಫ್ಟ್ ಸ್ಕಿಲ್ಸ್ ಇದೆ. ಕೆಲವು ಜನರೊಂದಿಗೆ ಇದು ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಇತರರೊಂದಿಗೆ ಇದು ಕೆಟ್ಟದಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಇದರಿಂದ ಖಂಡಿತವಾಗಿಯೂ ಪ್ರಯೋಜನಗಳಿವೆ. ಜೋಡಿ ಕೆಲಸದ ನಿಯಮಗಳನ್ನು ಸಾಕಷ್ಟು ಗಮನಿಸದಿದ್ದರೂ ಸಹ, ಒಟ್ಟಿಗೆ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಅಂಶವು ಫಲಿತಾಂಶದ ಗುಣಮಟ್ಟದ ಮೇಲೆ ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ವೈಯಕ್ತಿಕವಾಗಿ, ನಾನು ಜೋಡಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವುದು ಸುಲಭ ಮತ್ತು ಹೆಚ್ಚು ಆನಂದದಾಯಕವಾಗಿದೆ.

OS ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವ ಉನ್ನತ ಮಟ್ಟದ ವಿಧಾನಗಳು - ಕಾರ್ಯಗಳ ಯೋಜನೆ ಮತ್ತು ಕೆಲಸವು ನಿಖರವಾಗಿ ಪರಿಣಾಮಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ: ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಜ್ಞಾನ ವಿನಿಮಯ ಮತ್ತು ಸುಧಾರಿತ ಅಭಿವೃದ್ಧಿ ಗುಣಮಟ್ಟ.

ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ಸಣ್ಣ ತೀರ್ಮಾನಗಳು

• HR ವೈದ್ಯರು IaC ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ, ಆದರೆ ಕಡಿಮೆ ದಕ್ಷತೆಯೊಂದಿಗೆ.
• ಏನು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬಲಪಡಿಸಿ.
• ನಿಮ್ಮ ಸ್ವಂತ ಪರಿಹಾರ ಕಾರ್ಯವಿಧಾನಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳೊಂದಿಗೆ ಬನ್ನಿ.

ಮೂಲ: www.habr.com