ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಿಗಾಗಿ ಒಂದು ದೃಢವಾದ ನಿರಂತರ ಏಕೀಕರಣ (CI) ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಬಗ್ಗೆ ಆಳವಾದ ಮಾಹಿತಿ. GitHub Actions, GitLab CI, ಮತ್ತು Jenkins ನಂತಹ ಜಾಗತಿಕ ಸಾಧನಗಳೊಂದಿಗೆ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಕಲಿಯಿರಿ.
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಟೆಸ್ಟಿಂಗ್ ಆಟೊಮೇಷನ್: ನಿರಂತರ ಏಕೀಕರಣ (CI) ಸೆಟಪ್‌ಗೆ ಒಂದು ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿ
ಈ ಸನ್ನಿವೇಶವನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ: ನಿಮ್ಮ ಕೆಲಸದ ದಿನದ ಕೊನೆಯಲ್ಲಿದೆ. ನೀವು ಮುಖ್ಯ ಬ್ರಾಂಚ್‌ಗೆ ಒಂದು ಸಣ್ಣ ಬಗ್ ಫಿಕ್ಸ್ ಎಂದು ನಂಬಿ ಕೋಡ್ ಪುಶ್ ಮಾಡಿದ್ದೀರಿ. ಕೆಲವೇ ಕ್ಷಣಗಳಲ್ಲಿ, ಎಚ್ಚರಿಕೆಗಳು ಬರಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಗ್ರಾಹಕರ ಬೆಂಬಲ ಚಾನೆಲ್‌ಗಳು, ಸಂಪೂರ್ಣವಾಗಿ ಸಂಬಂಧವಿಲ್ಲದ ಒಂದು ಪ್ರಮುಖ ಫೀಚರ್ ಮುರಿದುಹೋಗಿದೆ ಎಂಬ ವರದಿಗಳಿಂದ ತುಂಬಿಹೋಗುತ್ತವೆ. ಇದರಿಂದ ಒತ್ತಡದ, ತುರ್ತಾದ ಹಾಟ್‌ಫಿಕ್ಸ್ ಮಾಡುವ ಪರಿಸ್ಥಿತಿ ಉದ್ಭವಿಸುತ್ತದೆ. ಈ ಪರಿಸ್ಥಿತಿಯು, ವಿಶ್ವಾದ್ಯಂತದ ಡೆವಲಪ್‌ಮೆಂಟ್ ತಂಡಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿದೆ, ಮತ್ತು ಇದನ್ನು ತಡೆಯಲೆಂದೇ ಒಂದು ದೃಢವಾದ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ ಮತ್ತು ನಿರಂತರ ಏಕೀಕರಣ (CI) ತಂತ್ರವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.
ಇಂದಿನ ವೇಗದ, ಜಾಗತಿಕ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ಜಗತ್ತಿನಲ್ಲಿ, ವೇಗ ಮತ್ತು ಗುಣಮಟ್ಟ ಪರಸ್ಪರ ಪ್ರತ್ಯೇಕವಲ್ಲ; ಅವು ಪರಸ್ಪರ ಅವಲಂಬಿತವಾಗಿವೆ. ವಿಶ್ವಾಸಾರ್ಹ ಫೀಚರ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ತಲುಪಿಸುವ ಸಾಮರ್ಥ್ಯವು ಒಂದು ಗಮನಾರ್ಹ ಸ್ಪರ್ಧಾತ್ಮಕ ಪ್ರಯೋಜನವಾಗಿದೆ. ಇಲ್ಲಿಯೇ ಸ್ವಯಂಚಾಲಿತ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಪರೀಕ್ಷೆ ಮತ್ತು ನಿರಂತರ ಏಕೀಕರಣ ಪೈಪ್‌ಲೈನ್‌ಗಳ ಸಮ್ಮಿಲನವು ಆಧುನಿಕ, ಉನ್ನತ-ಕಾರ್ಯಕ್ಷಮತೆಯ ಇಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳ ಅಡಿಗಲ್ಲಾಗಿದೆ. ಈ ಮಾರ್ಗದರ್ಶಿಯು ಯಾವುದೇ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಾಗಿ CI ಸೆಟಪ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತು ಉತ್ತಮಗೊಳಿಸಲು ನಿಮ್ಮ ಸಮಗ್ರ ಮಾರ್ಗಸೂಚಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಡೆವಲಪರ್‌ಗಳು, ತಂಡದ ಮುಖಂಡರು ಮತ್ತು DevOps ಇಂಜಿನಿಯರ್‌ಗಳ ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗೆ ಸಹಕಾರಿಯಾಗಿದೆ.
'ಏಕೆ': CI ಯ ಮೂಲ ತತ್ವಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು
ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಸಾಧನಗಳ ಬಗ್ಗೆ ತಿಳಿಯುವ ಮೊದಲು, ನಿರಂತರ ಏಕೀಕರಣದ ಹಿಂದಿನ ತತ್ವವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ. CI ಎಂದರೆ ಕೇವಲ ರಿಮೋಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವುದಲ್ಲ; ಇದು ಒಂದು ಅಭಿವೃದ್ಧಿ ಅಭ್ಯಾಸ ಮತ್ತು ಸಾಂಸ್ಕೃತಿಕ ಬದಲಾವಣೆಯಾಗಿದ್ದು, ತಂಡಗಳು ಹೇಗೆ ಸಹಯೋಗಿಸುತ್ತವೆ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ತಲುಪಿಸುತ್ತವೆ ಎಂಬುದರ ಮೇಲೆ ಆಳವಾದ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ನಿರಂತರ ಏಕೀಕರಣ (CI) ಎಂದರೇನು?
ನಿರಂತರ ಏಕೀಕರಣ ಎಂದರೆ ಎಲ್ಲಾ ಡೆವಲಪರ್‌ಗಳ ಕೆಲಸದ ಕೋಡ್ ಪ್ರತಿಗಳನ್ನು ಆಗಾಗ್ಗೆ ಹಂಚಿಕೆಯಾದ ಮುಖ್ಯ ಶಾಖೆಗೆ (mainline) ವಿಲೀನಗೊಳಿಸುವ ಅಭ್ಯಾಸ—ಸಾಮಾನ್ಯವಾಗಿ ದಿನಕ್ಕೆ ಹಲವಾರು ಬಾರಿ. ಪ್ರತಿ ವಿಲೀನ ಅಥವಾ 'ಏಕೀಕರಣ'ವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬಿಲ್ಡ್ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳ ಸರಣಿಯಿಂದ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ. ಇದರ ಪ್ರಾಥಮಿಕ ಗುರಿ ಏಕೀಕರಣ ದೋಷಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಪತ್ತೆ ಮಾಡುವುದು.
ಇದನ್ನು ಒಬ್ಬ ಜಾಗರೂಕ, ಸ್ವಯಂಚಾಲಿತ ತಂಡದ ಸದಸ್ಯನಂತೆ ಯೋಚಿಸಿ, ಅವರು ಹೊಸ ಕೋಡ್ ಕೊಡುಗೆಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮುರಿಯುವುದಿಲ್ಲ ಎಂದು ನಿರಂತರವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತಾರೆ. ಈ ತಕ್ಷಣದ ಪ್ರತಿಕ್ರಿಯೆ ಲೂಪ್ CI ಯ ಹೃದಯವಾಗಿದೆ ಮತ್ತು ಅದರ ಅತ್ಯಂತ ಶಕ್ತಿಯುತ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ.
CI ಅಳವಡಿಕೆಯ ಪ್ರಮುಖ ಪ್ರಯೋಜನಗಳು
- ಆರಂಭಿಕ ದೋಷ ಪತ್ತೆ ಮತ್ತು ವೇಗದ ಪ್ರತಿಕ್ರಿಯೆ: ಪ್ರತಿ ಬದಲಾವಣೆಯನ್ನು ಪರೀಕ್ಷಿಸುವ ಮೂಲಕ, ನೀವು ದಿನಗಳು ಅಥವಾ ವಾರಗಳ ಬದಲಿಗೆ ನಿಮಿಷಗಳಲ್ಲಿ ದೋಷಗಳನ್ನು ಹಿಡಿಯುತ್ತೀರಿ. ಇದು ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಲು ಬೇಕಾದ ಸಮಯ ಮತ್ತು ವೆಚ್ಚವನ್ನು ತೀವ್ರವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಬದಲಾವಣೆಗಳ ಬಗ್ಗೆ ತಕ್ಷಣದ ಪ್ರತಿಕ್ರಿಯೆ ಪಡೆಯುತ್ತಾರೆ, ಇದು ಅವರಿಗೆ ತ್ವರಿತವಾಗಿ ಮತ್ತು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಕೆಲಸ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
- ಸುಧಾರಿತ ಕೋಡ್ ಗುಣಮಟ್ಟ: CI ಪೈಪ್‌ಲೈನ್ ಒಂದು ಗುಣಮಟ್ಟದ ಗೇಟ್‌ನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಲಿಂಟರ್‌ಗಳೊಂದಿಗೆ ಕೋಡಿಂಗ್ ಮಾನದಂಡಗಳನ್ನು ಜಾರಿಗೊಳಿಸಬಹುದು, ಟೈಪ್ ದೋಷಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು, ಮತ್ತು ಹೊಸ ಕೋಡ್ ಪರೀಕ್ಷೆಗಳಿಂದ ಆವರಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು. ಕಾಲಾನಂತರದಲ್ಲಿ, ಇದು ಸಂಪೂರ್ಣ ಕೋಡ್‌ಬೇಸ್‌ನ ಗುಣಮಟ್ಟ ಮತ್ತು ನಿರ್ವಹಣೆಯನ್ನು ವ್ಯವಸ್ಥಿತವಾಗಿ ಹೆಚ್ಚಿಸುತ್ತದೆ.
- ಕಡಿಮೆ ವಿಲೀನ ಸಂಘರ್ಷಗಳು (Merge Conflicts): ಕೋಡ್‌ನ ಸಣ್ಣ ಬ್ಯಾಚ್‌ಗಳನ್ನು ಆಗಾಗ್ಗೆ ಸಂಯೋಜಿಸುವ ಮೂಲಕ, ಡೆವಲಪರ್‌ಗಳು ದೊಡ್ಡ, ಸಂಕೀರ್ಣ ವಿಲೀನ ಸಂಘರ್ಷಗಳನ್ನು ('merge hell') ಎದುರಿಸುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆ. ಇದು ಗಮನಾರ್ಹ ಸಮಯವನ್ನು ಉಳಿಸುತ್ತದೆ ಮತ್ತು ಹಸ್ತಚಾಲಿತ ವಿಲೀನಗಳ ಸಮಯದಲ್ಲಿ ದೋಷಗಳನ್ನು ಪರಿಚಯಿಸುವ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
- ಹೆಚ್ಚಿದ ಡೆವಲಪರ್ ಉತ್ಪಾದಕತೆ ಮತ್ತು ಆತ್ಮವಿಶ್ವಾಸ: ಆಟೊಮೇಷನ್ ಡೆವಲಪರ್‌ಗಳನ್ನು ಬೇಸರದ, ಹಸ್ತಚಾಲಿತ ಪರೀಕ್ಷೆ ಮತ್ತು ಡಿಪ್ಲಾಯ್‌ಮೆಂಟ್ ಪ್ರಕ್ರಿಯೆಗಳಿಂದ ಮುಕ್ತಗೊಳಿಸುತ್ತದೆ. ಒಂದು ಸಮಗ್ರ ಪರೀಕ್ಷಾ ಸೂಟ್ ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ರಕ್ಷಿಸುತ್ತಿದೆ ಎಂದು ತಿಳಿದಿರುವುದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ರಿಗ್ರೆಶನ್‌ಗಳನ್ನು ಉಂಟುಮಾಡುವ ಭಯವಿಲ್ಲದೆ ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಲು, ನಾವೀನ್ಯತೆ ಮಾಡಲು ಮತ್ತು ಫೀಚರ್‌ಗಳನ್ನು ರವಾನಿಸಲು ಆತ್ಮವಿಶ್ವಾಸವನ್ನು ನೀಡುತ್ತದೆ.
- ಸತ್ಯದ ಏಕೈಕ ಮೂಲ: CI ಸರ್ವರ್ 'ಹಸಿರು' (green) ಅಥವಾ 'ಕೆಂಪು' (red) ಬಿಲ್ಡ್‌ಗೆ ನಿರ್ಣಾಯಕ ಮೂಲವಾಗುತ್ತದೆ. ತಂಡದ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ, ಅವರ ಭೌಗೋಳಿಕ ಸ್ಥಳ ಅಥವಾ ಸಮಯ ವಲಯವನ್ನು ಲೆಕ್ಕಿಸದೆ, ಯಾವುದೇ ಕ್ಷಣದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆರೋಗ್ಯದ ಬಗ್ಗೆ ಸ್ಪಷ್ಟ ಗೋಚರತೆ ಇರುತ್ತದೆ.
'ಏನು': ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಪರೀಕ್ಷೆಯ ಒಂದು ನೋಟ
ಒಂದು ಯಶಸ್ವಿ CI ಪೈಪ್‌ಲೈನ್ ಅದು ನಡೆಸುವ ಪರೀಕ್ಷೆಗಳಷ್ಟೇ ಉತ್ತಮವಾಗಿರುತ್ತದೆ. ನಿಮ್ಮ ಪರೀಕ್ಷೆಗಳನ್ನು ರಚಿಸಲು ಒಂದು ಸಾಮಾನ್ಯ ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ತಂತ್ರವೆಂದರೆ 'ಟೆಸ್ಟಿಂಗ್ ಪಿರಮಿಡ್'. ಇದು ವಿವಿಧ ರೀತಿಯ ಪರೀಕ್ಷೆಗಳ ಆರೋಗ್ಯಕರ ಸಮತೋಲನವನ್ನು ದೃಶ್ಯೀಕರಿಸುತ್ತದೆ.
ಒಂದು ಪಿರಮಿಡ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ:
- ಬೇಸ್ (ಅತಿದೊಡ್ಡ ಪ್ರದೇಶ): ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳು. ಇವು ವೇಗವಾಗಿರುತ್ತವೆ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯಲ್ಲಿರುತ್ತವೆ, ಮತ್ತು ನಿಮ್ಮ ಕೋಡ್‌ನ ಚಿಕ್ಕ ಭಾಗಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತವೆ.
- ಮಧ್ಯ: ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್‌ಗಳು. ಇವು ಬಹು ಘಟಕಗಳು ಒಟ್ಟಿಗೆ ನಿರೀಕ್ಷೆಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತವೆ.
- ಮೇಲ್ಭಾಗ (ಚಿಕ್ಕ ಪ್ರದೇಶ): ಎಂಡ್-ಟು-ಎಂಡ್ (E2E) ಟೆಸ್ಟ್‌ಗಳು. ಇವು ನಿಧಾನವಾಗಿರುತ್ತವೆ, ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಪರೀಕ್ಷೆಗಳಾಗಿದ್ದು, ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್ ಮೂಲಕ ನೈಜ ಬಳಕೆದಾರರ ಪ್ರಯಾಣವನ್ನು ಅನುಕರಿಸುತ್ತವೆ.
ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳು: ಅಡಿಪಾಯ
ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳು ಒಂದೇ ಫಂಕ್ಷನ್, ಮೆಥಡ್, ಅಥವಾ ಕಾಂಪೊನೆಂಟ್ ಮೇಲೆ ಗಮನಹರಿಸುತ್ತವೆ. ಅವು ಅಪ್ಲಿಕೇಶನ್‌ನ ಉಳಿದ ಭಾಗಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟಿರುತ್ತವೆ, ಅವಲಂಬನೆಗಳನ್ನು ಅನುಕರಿಸಲು 'ಮಾಕ್ಸ್' ಅಥವಾ 'ಸ್ಟಬ್ಸ್' ಅನ್ನು ಬಳಸುತ್ತವೆ. ವಿವಿಧ ಇನ್‌ಪುಟ್‌ಗಳನ್ನು ನೀಡಿದಾಗ ಒಂದು ನಿರ್ದಿಷ್ಟ ಲಾಜಿಕ್‌ನ ತುಣುಕು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸುವುದು ಅವುಗಳ ಗುರಿಯಾಗಿದೆ.
- ಉದ್ದೇಶ: ವೈಯಕ್ತಿಕ ಲಾಜಿಕ್ ಘಟಕಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು.
- ವೇಗ: ಅತ್ಯಂತ ವೇಗ (ಪ್ರತಿ ಪರೀಕ್ಷೆಗೆ ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳು).
- ಪ್ರಮುಖ ಪರಿಕರಗಳು:
- Jest: ಅಂತರ್ನಿರ್ಮಿತ ಅಸರ್ಶನ್ ಲೈಬ್ರರಿಗಳು, ಮಾಕಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳು, ಮತ್ತು ಕೋಡ್ ಕವರೇಜ್ ಪರಿಕರಗಳೊಂದಿಗೆ ಜನಪ್ರಿಯ, ಆಲ್-ಇನ್-ಒನ್ ಟೆಸ್ಟಿಂಗ್ ಫ್ರೇಮ್‌ವರ್ಕ್. ಮೆಟಾದಿಂದ ನಿರ್ವಹಿಸಲ್ಪಡುತ್ತದೆ.
- Vitest: Vite ಬಿಲ್ಡ್ ಟೂಲ್‌ನೊಂದಿಗೆ ಮನಬಂದಂತೆ ಕೆಲಸ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಆಧುನಿಕ, ಅತ್ಯಂತ ವೇಗದ ಟೆಸ್ಟಿಂಗ್ ಫ್ರೇಮ್‌ವರ್ಕ್, ಇದು Jest-ಹೊಂದಾಣಿಕೆಯ API ಅನ್ನು ನೀಡುತ್ತದೆ.
- Mocha: ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ಪ್ರೌಢವಾದ ಟೆಸ್ಟಿಂಗ್ ಫ್ರೇಮ್‌ವರ್ಕ್, ಇದು ಪರೀಕ್ಷೆಗಳಿಗೆ ಮೂಲಭೂತ ರಚನೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದನ್ನು ಹೆಚ್ಚಾಗಿ Chai ನಂತಹ ಅಸರ್ಶನ್ ಲೈಬ್ರರಿಯೊಂದಿಗೆ ಜೋಡಿಸಲಾಗುತ್ತದೆ.
ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್‌ಗಳು: ಸಂಪರ್ಕದ ಅಂಗಾಂಶ
ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್‌ಗಳು ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳಿಗಿಂತ ಒಂದು ಹೆಜ್ಜೆ ಮುಂದಿವೆ. ಅವು ಬಹು ಘಟಕಗಳು ಹೇಗೆ ಸಹಯೋಗಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಫ್ರಂಟ್-ಎಂಡ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, ಒಂದು ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್ ಹಲವಾರು ಚೈಲ್ಡ್ ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ರೆಂಡರ್ ಮಾಡಬಹುದು ಮತ್ತು ಬಳಕೆದಾರರು ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ ಅವು ಸರಿಯಾಗಿ ಸಂವಹನ ನಡೆಸುತ್ತವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಬಹುದು.
- ಉದ್ದೇಶ: ಮಾಡ್ಯೂಲ್‌ಗಳು ಅಥವಾ ಕಾಂಪೊನೆಂಟ್‌ಗಳ ನಡುವಿನ ಸಂವಹನವನ್ನು ಪರಿಶೀಲಿಸುವುದು.
- ವೇಗ: ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳಿಗಿಂತ ನಿಧಾನ, ಆದರೆ E2E ಟೆಸ್ಟ್‌ಗಳಿಗಿಂತ ವೇಗ.
- ಪ್ರಮುಖ ಪರಿಕರಗಳು:
- React Testing Library: ಇದೊಂದು ಟೆಸ್ಟ್ ರನ್ನರ್ ಅಲ್ಲ, ಆದರೆ ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ವಿವರಗಳಿಗಿಂತ ಅಪ್ಲಿಕೇಶನ್ ನಡವಳಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಪ್ರೋತ್ಸಾಹಿಸುವ ಉಪಯುಕ್ತತೆಗಳ ಒಂದು ಸೆಟ್. ಇದು Jest ಅಥವಾ Vitest ನಂತಹ ರನ್ನರ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
- Supertest: Node.js HTTP ಸರ್ವರ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಜನಪ್ರಿಯ ಲೈಬ್ರರಿ, ಇದು API ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್‌ಗಳಿಗೆ ಅತ್ಯುತ್ತಮವಾಗಿದೆ.
ಎಂಡ್-ಟು-ಎಂಡ್ (E2E) ಟೆಸ್ಟ್‌ಗಳು: ಬಳಕೆದಾರರ ದೃಷ್ಟಿಕೋನ
E2E ಟೆಸ್ಟ್‌ಗಳು ಸಂಪೂರ್ಣ ಬಳಕೆದಾರರ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಅನುಕರಿಸಲು ನೈಜ ಬ್ರೌಸರ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತವೆ. ಇ-ಕಾಮರ್ಸ್ ಸೈಟ್‌ಗೆ, E2E ಪರೀಕ್ಷೆಯು ಮುಖಪುಟಕ್ಕೆ ಭೇಟಿ ನೀಡುವುದು, ಉತ್ಪನ್ನಕ್ಕಾಗಿ ಹುಡುಕುವುದು, ಅದನ್ನು ಕಾರ್ಟ್‌ಗೆ ಸೇರಿಸುವುದು ಮತ್ತು ಚೆಕ್‌ಔಟ್ ಪುಟಕ್ಕೆ ಮುಂದುವರಿಯುವುದನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. ಈ ಪರೀಕ್ಷೆಗಳು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಒಟ್ಟಾರೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂಬ ಅತ್ಯುನ್ನತ ಮಟ್ಟದ ವಿಶ್ವಾಸವನ್ನು ಒದಗಿಸುತ್ತವೆ.
- ಉದ್ದೇಶ: ಸಂಪೂರ್ಣ ಬಳಕೆದಾರರ ಫ್ಲೋಗಳನ್ನು ಪ್ರಾರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಪರಿಶೀಲಿಸುವುದು.
- ವೇಗ: ಪರೀಕ್ಷೆಯ ಅತ್ಯಂತ ನಿಧಾನ ಮತ್ತು ದುರ್ಬಲ ಪ್ರಕಾರ.
- ಪ್ರಮುಖ ಪರಿಕರಗಳು:
- Cypress: ಅತ್ಯುತ್ತಮ ಡೆವಲಪರ್ ಅನುಭವ, ಸಂವಾದಾತ್ಮಕ ಟೆಸ್ಟ್ ರನ್ನರ್ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಗೆ ಹೆಸರುವಾಸಿಯಾದ ಆಧುನಿಕ, ಆಲ್-ಇನ್-ಒನ್ E2E ಟೆಸ್ಟಿಂಗ್ ಫ್ರೇಮ್‌ವರ್ಕ್.
- Playwright: Microsoft ನಿಂದ ಒಂದು ಶಕ್ತಿಯುತ ಫ್ರೇಮ್‌ವರ್ಕ್, ಇದು ಒಂದೇ API ನೊಂದಿಗೆ ಕ್ರಾಸ್-ಬ್ರೌಸರ್ ಆಟೊಮೇಷನ್ (Chromium, Firefox, WebKit) ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಇದು ಅದರ ವೇಗ ಮತ್ತು ಸುಧಾರಿತ ವೈಶಿಷ್ಟ್ಯಗಳಿಗೆ ಹೆಸರುವಾಸಿಯಾಗಿದೆ.
- Selenium WebDriver: ಬ್ರೌಸರ್ ಆಟೊಮೇಷನ್‌ಗೆ ದೀರ್ಘಕಾಲದ ಮಾನದಂಡ, ಇದು ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಭಾಷೆಗಳು ಮತ್ತು ಬ್ರೌಸರ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಇದು ಗರಿಷ್ಠ ನಮ್ಯತೆಯನ್ನು ನೀಡುತ್ತದೆ ಆದರೆ ಸೆಟಪ್ ಮಾಡಲು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಬಹುದು.
ಸ್ಟ್ಯಾಟಿಕ್ ವಿಶ್ಲೇಷಣೆ: ರಕ್ಷಣೆಯ ಮೊದಲ ಸಾಲು
ಯಾವುದೇ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವ ಮೊದಲು, ಸ್ಟ್ಯಾಟಿಕ್ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳು ಸಾಮಾನ್ಯ ದೋಷಗಳನ್ನು ಹಿಡಿಯಬಹುದು ಮತ್ತು ಕೋಡ್ ಶೈಲಿಯನ್ನು ಜಾರಿಗೊಳಿಸಬಹುದು. ಇವುಗಳು ಯಾವಾಗಲೂ ನಿಮ್ಮ CI ಪೈಪ್‌ಲೈನ್‌ನ ಮೊದಲ ಹಂತವಾಗಿರಬೇಕು.
- ESLint: ನಿಮ್ಮ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕೋಡ್‌ನಲ್ಲಿನ ಸಂಭಾವ್ಯ ದೋಷಗಳಿಂದ ಹಿಡಿದು ಶೈಲಿಯ ಉಲ್ಲಂಘನೆಗಳವರೆಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಹುಡುಕಲು ಮತ್ತು ಸರಿಪಡಿಸಲು ಹೆಚ್ಚು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ಲಿಂಟರ್.
- Prettier: ನಿಮ್ಮ ಇಡೀ ತಂಡದಾದ್ಯಂತ ಸ್ಥಿರವಾದ ಕೋಡ್ ಶೈಲಿಯನ್ನು ಖಚಿತಪಡಿಸುವ ಅಭಿಪ್ರಾಯಯುಕ್ತ ಕೋಡ್ ಫಾರ್ಮ್ಯಾಟರ್, ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಮೇಲಿನ ಚರ್ಚೆಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ.
- TypeScript: ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಸ್ಟ್ಯಾಟಿಕ್ ಟೈಪ್‌ಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ, TypeScript ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಮುಂಚೆಯೇ, ಕಂಪೈಲ್ ಸಮಯದಲ್ಲಿಯೇ ಸಂಪೂರ್ಣ ದೋಷಗಳ ವರ್ಗವನ್ನು ಹಿಡಿಯಬಲ್ಲದು.
'ಹೇಗೆ': ನಿಮ್ಮ CI ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು - ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗದರ್ಶಿ
ಈಗ, ನಾವು ಪ್ರಾಯೋಗಿಕವಾಗಿ ನೋಡೋಣ. ನಾವು ಜಾಗತಿಕವಾಗಿ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಮತ್ತು ಸುಲಭವಾಗಿ ಲಭ್ಯವಿರುವ CI/CD ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಒಂದಾದ GitHub Actions ಬಳಸಿ CI ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದರ ಮೇಲೆ ಗಮನ ಹರಿಸುತ್ತೇವೆ. ಆದಾಗ್ಯೂ, ಇಲ್ಲಿನ ಪರಿಕಲ್ಪನೆಗಳು GitLab CI/CD ಅಥವಾ Jenkins ನಂತಹ ಇತರ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ನೇರವಾಗಿ ಅನ್ವಯವಾಗುತ್ತವೆ.
ಪೂರ್ವಾಪೇಕ್ಷಿತಗಳು
- ಒಂದು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಪ್ರಾಜೆಕ್ಟ್ (Node.js, React, Vue, ಇತ್ಯಾದಿ).
- ಒಂದು ಟೆಸ್ಟಿಂಗ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿರಬೇಕು (ನಾವು ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳಿಗೆ Jest ಮತ್ತು E2E ಟೆಸ್ಟ್‌ಗಳಿಗೆ Cypress ಅನ್ನು ಬಳಸುತ್ತೇವೆ).
- ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು GitHub ನಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಿರಬೇಕು.
- ನಿಮ್ಮ `package.json` ಫೈಲ್‌ನಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿರಬೇಕು.
ಒಂದು ವಿಶಿಷ್ಟ `package.json` ಫೈಲ್‌ನಲ್ಲಿ ಈ ರೀತಿಯ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಇರಬಹುದು:
ಉದಾಹರಣೆ `package.json` ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು:
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build",
"lint": "eslint .",
"test": "jest",
"test:ci": "jest --ci --coverage",
"cypress:open": "cypress open",
"cypress:run": "cypress run"
}
ಹಂತ 1: ನಿಮ್ಮ ಮೊದಲ GitHub Actions ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದು
GitHub Actions ಅನ್ನು ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯ `.github/workflows/` ಡೈರೆಕ್ಟರಿಯಲ್ಲಿರುವ YAML ಫೈಲ್‌ಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗುತ್ತದೆ. ನಾವು `ci.yml` ಎಂಬ ಫೈಲ್ ಅನ್ನು ರಚಿಸೋಣ.
ಫೈಲ್: `.github/workflows/ci.yml`
ಈ ವರ್ಕ್‌ಫ್ಲೋ ನಮ್ಮ ಲಿಂಟರ್‌ಗಳು ಮತ್ತು ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳನ್ನು `main` ಬ್ರಾಂಚ್‌ಗೆ ಪ್ರತಿ ಪುಶ್ ಮಾಡಿದಾಗ ಮತ್ತು `main` ಅನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡ ಪ್ರತಿ ಪುಲ್ ವಿನಂತಿಯ ಮೇಲೆ ರನ್ ಮಾಡುತ್ತದೆ.
# ಇದು ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋಗೆ ಒಂದು ಹೆಸರು
name: JavaScript CI
# ಈ ವಿಭಾಗವು ವರ್ಕ್‌ಫ್ಲೋ ಯಾವಾಗ ರನ್ ಆಗುತ್ತದೆ ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
# ಈ ವಿಭಾಗವು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾದ ಜಾಬ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ
jobs:
# ನಾವು 'test' ಹೆಸರಿನ ಒಂದು ಜಾಬ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೇವೆ
test:
# ಜಾಬ್ ಅನ್ನು ರನ್ ಮಾಡಲು ಬೇಕಾದ ವರ್ಚುವಲ್ ಮಷೀನ್‌ನ ಪ್ರಕಾರ
runs-on: ubuntu-latest
# ಸ್ಟೆಪ್ಸ್ ಎಂದರೆ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾದ ಕಾರ್ಯಗಳ ಅನುಕ್ರಮ
steps:
# ಹಂತ 1: ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯ ಕೋಡ್ ಅನ್ನು ಚೆಕ್ ಔಟ್ ಮಾಡಿ
- name: Checkout code
uses: actions/checkout@v4
# ಹಂತ 2: Node.js ನ ಸರಿಯಾದ ಆವೃತ್ತಿಯನ್ನು ಸ್ಥಾಪಿಸಿ
- name: Use Node.js 20.x
uses: actions/setup-node@v4
with:
node-version: '20.x'
cache: 'npm' # ಇದು npm ಡಿಪೆಂಡೆನ್ಸಿಗಳ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ
# ಹಂತ 3: ಪ್ರಾಜೆಕ್ಟ್ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿ
- name: Install dependencies
run: npm ci
# ಹಂತ 4: ಕೋಡ್ ಶೈಲಿಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಲಿಂಟರ್ ಅನ್ನು ರನ್ ಮಾಡಿ
- name: Run linter
run: npm run lint
# ಹಂತ 5: ಯೂನಿಟ್ ಮತ್ತು ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್‌ಗಳನ್ನು ರನ್ ಮಾಡಿ
- name: Run unit tests
run: npm run test:ci
ಒಮ್ಮೆ ನೀವು ಈ ಫೈಲ್ ಅನ್ನು ಕಮಿಟ್ ಮಾಡಿ GitHub ಗೆ ಪುಶ್ ಮಾಡಿದರೆ, ನಿಮ್ಮ CI ಪೈಪ್‌ಲೈನ್ ಲೈವ್ ಆಗುತ್ತದೆ! ಅದು ರನ್ ಆಗುವುದನ್ನು ನೋಡಲು ನಿಮ್ಮ GitHub ರೆಪೊಸಿಟರಿಯಲ್ಲಿ 'Actions' ಟ್ಯಾಬ್‌ಗೆ ನ್ಯಾವಿಗೇಟ್ ಮಾಡಿ.
ಹಂತ 2: ಸೈಪ್ರೆಸ್‌ನೊಂದಿಗೆ ಎಂಡ್-ಟು-ಎಂಡ್ ಟೆಸ್ಟ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸುವುದು
E2E ಟೆಸ್ಟ್‌ಗಳು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿವೆ. ಅವುಗಳಿಗೆ ಚಾಲನೆಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಮತ್ತು ಬ್ರೌಸರ್ ಅಗತ್ಯವಿದೆ. ಇದನ್ನು ನಿರ್ವಹಿಸಲು ನಾವು ನಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ವಿಸ್ತರಿಸಬಹುದು. E2E ಟೆಸ್ಟ್‌ಗಳಿಗಾಗಿ ನಾವು ಪ್ರತ್ಯೇಕ ಜಾಬ್ ಅನ್ನು ರಚಿಸೋಣ, ಇದರಿಂದ ಅವು ನಮ್ಮ ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳೊಂದಿಗೆ ಸಮಾನಾಂತರವಾಗಿ ರನ್ ಆಗಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಇದು ಒಟ್ಟಾರೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ.
ನಾವು ಅಧಿಕೃತ `cypress-io/github-action` ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಇದು ಅನೇಕ ಸೆಟಪ್ ಹಂತಗಳನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ.
ಅಪ್‌ಡೇಟ್ ಮಾಡಿದ ಫೈಲ್: `.github/workflows/ci.yml`
name: JavaScript CI
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
jobs:
# ಯೂನಿಟ್ ಟೆಸ್ಟ್ ಜಾಬ್ ಹಾಗೆಯೇ ಇರುತ್ತದೆ
unit-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20.x'
cache: 'npm'
- run: npm ci
- run: npm run lint
- run: npm run test:ci
# ನಾವು E2E ಟೆಸ್ಟ್‌ಗಳಿಗಾಗಿ ಹೊಸ, ಸಮಾನಾಂತರ ಜಾಬ್ ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ
e2e-tests:
runs-on: ubuntu-latest
# ಯೂನಿಟ್-ಟೆಸ್ಟ್ಸ್ ಜಾಬ್ ಯಶಸ್ವಿಯಾದರೆ ಮಾತ್ರ ಈ ಜಾಬ್ ರನ್ ಆಗಬೇಕು
needs: unit-tests
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20.x'
cache: 'npm'
- name: Install dependencies
run: npm ci
# ಅಧಿಕೃತ ಸೈಪ್ರೆಸ್ ಆಕ್ಷನ್ ಬಳಸಿ
- name: Cypress run
uses: cypress-io/github-action@v6
with:
# E2E ಟೆಸ್ಟ್‌ಗಳನ್ನು ನಡೆಸುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಿಲ್ಡ್ ಮಾಡಬೇಕು
build: npm run build
# ಸ್ಥಳೀಯ ಸರ್ವರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಬೇಕಾದ ಕಮಾಂಡ್
start: npm start
# ಪರೀಕ್ಷೆಗಳಿಗಾಗಿ ಬಳಸಬೇಕಾದ ಬ್ರೌಸರ್
browser: chrome
# ಈ URL ನಲ್ಲಿ ಸರ್ವರ್ ಸಿದ್ಧವಾಗುವವರೆಗೆ ಕಾಯಿರಿ
wait-on: 'http://localhost:3000'
ಈ ಸೆಟಪ್ ಎರಡು ಜಾಬ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ. `e2e-tests` ಜಾಬ್‌ಗೆ `unit-tests` ಜಾಬ್ `needs` ಆಗಿರುವುದರಿಂದ, ಮೊದಲ ಜಾಬ್ ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಂಡ ನಂತರವೇ ಅದು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಇದು ಅನುಕ್ರಮ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ, ನಿಧಾನವಾದ, ಹೆಚ್ಚು ದುಬಾರಿಯಾದ E2E ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವ ಮೊದಲು ಮೂಲಭೂತ ಕೋಡ್ ಗುಣಮಟ್ಟವನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಪರ್ಯಾಯ CI/CD ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು: ಒಂದು ಜಾಗತಿಕ ದೃಷ್ಟಿಕೋನ
GitHub Actions ಒಂದು ಅತ್ಯುತ್ತಮ ಆಯ್ಕೆಯಾಗಿದ್ದರೂ, ಜಗತ್ತಿನಾದ್ಯಂತ ಅನೇಕ ಸಂಸ್ಥೆಗಳು ಇತರ ಶಕ್ತಿಯುತ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಮೂಲಭೂತ ಪರಿಕಲ್ಪನೆಗಳು ಸಾರ್ವತ್ರಿಕವಾಗಿವೆ.
GitLab CI/CD
GitLab ಒಂದು ಆಳವಾಗಿ ಸಂಯೋಜಿತ ಮತ್ತು ಶಕ್ತಿಯುತವಾದ CI/CD ಪರಿಹಾರವನ್ನು ಹೊಂದಿದೆ. ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯ ಮೂಲದಲ್ಲಿ `.gitlab-ci.yml` ಫೈಲ್ ಮೂಲಕ ಕಾನ್ಫಿಗರೇಶನ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಒಂದು ಸರಳೀಕೃತ `.gitlab-ci.yml` ಉದಾಹರಣೆ:
image: node:20
cache:
paths:
- node_modules/
stages:
- setup
- test
install_dependencies:
stage: setup
script:
- npm ci
run_unit_tests:
stage: test
script:
- npm run test:ci
run_linter:
stage: test
script:
- npm run lint
Jenkins
Jenkins ಒಂದು ಹೆಚ್ಚು ವಿಸ್ತರಿಸಬಲ್ಲ, ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಆಟೊಮೇಷನ್ ಸರ್ವರ್ ಆಗಿದೆ. ಗರಿಷ್ಠ ನಿಯಂತ್ರಣ ಮತ್ತು ಕಸ್ಟಮೈಸೇಶನ್ ಅಗತ್ಯವಿರುವ ಎಂಟರ್‌ಪ್ರೈಸ್ ಪರಿಸರದಲ್ಲಿ ಇದು ಜನಪ್ರಿಯ ಆಯ್ಕೆಯಾಗಿದೆ. Jenkins ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ `Jenkinsfile` ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗುತ್ತದೆ.
ಒಂದು ಸರಳೀಕೃತ ಡಿಕ್ಲರೇಟಿವ್ `Jenkinsfile` ಉದಾಹರಣೆ:
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'npm ci'
}
}
stage('Test') {
steps {
sh 'npm run lint'
sh 'npm run test:ci'
}
}
}
}
ಸುಧಾರಿತ CI ತಂತ್ರಗಳು ಮತ್ತು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು
ಒಮ್ಮೆ ನೀವು ಮೂಲಭೂತ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ರನ್ ಮಾಡಿದ ನಂತರ, ನೀವು ಅದನ್ನು ವೇಗ ಮತ್ತು ದಕ್ಷತೆಗಾಗಿ ಉತ್ತಮಗೊಳಿಸಬಹುದು, ಇದು ವಿಶೇಷವಾಗಿ ದೊಡ್ಡ, ವಿತರಿಸಿದ ತಂಡಗಳಿಗೆ ಮುಖ್ಯವಾಗಿದೆ.
ಸಮಾನಾಂತರೀಕರಣ ಮತ್ತು ಕ್ಯಾಶಿಂಗ್
ಸಮಾನಾಂತರೀಕರಣ (Parallelization): ದೊಡ್ಡ ಟೆಸ್ಟ್ ಸೂಟ್‌ಗಳಿಗೆ, ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ಚಲಾಯಿಸಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಹೆಚ್ಚಿನ E2E ಪರೀಕ್ಷಾ ಸಾಧನಗಳು ಮತ್ತು ಕೆಲವು ಯೂನಿಟ್ ಟೆಸ್ಟ್ ರನ್ನರ್‌ಗಳು ಸಮಾನಾಂತರೀಕರಣವನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ. ಇದು ನಿಮ್ಮ ಟೆಸ್ಟ್ ಸೂಟ್ ಅನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಚಲಿಸುವ ಅನೇಕ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಲ್ಲಿ ವಿಭಜಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. Cypress Dashboard ನಂತಹ ಸೇವೆಗಳು ಅಥವಾ CI ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿನ ಅಂತರ್ನಿರ್ಮಿತ ವೈಶಿಷ್ಟ್ಯಗಳು ಇದನ್ನು ನಿರ್ವಹಿಸಬಹುದು, ಒಟ್ಟು ಪರೀಕ್ಷಾ ಸಮಯವನ್ನು ತೀವ್ರವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
ಕ್ಯಾಶಿಂಗ್ (Caching): ಪ್ರತಿ CI ರನ್‌ನಲ್ಲಿ `node_modules` ಅನ್ನು ಮರು-ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುವುದು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಎಲ್ಲಾ ಪ್ರಮುಖ CI ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಈ ಅವಲಂಬನೆಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡಲು ಒಂದು ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ಒದಗಿಸುತ್ತವೆ. ನಮ್ಮ GitHub Actions ಉದಾಹರಣೆಯಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ (`cache: 'npm'`), ಮೊದಲ ರನ್ ನಿಧಾನವಾಗಿರುತ್ತದೆ, ಆದರೆ ನಂತರದ ರನ್‌ಗಳು ಗಮನಾರ್ಹವಾಗಿ ವೇಗವಾಗಿರುತ್ತವೆ ಏಕೆಂದರೆ ಅವುಗಳು ಎಲ್ಲವನ್ನೂ ಮತ್ತೆ ಡೌನ್‌ಲೋಡ್ ಮಾಡುವ ಬದಲು ಕ್ಯಾಶ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದು.
ಕೋಡ್ ಕವರೇಜ್ ವರದಿ ಮಾಡುವಿಕೆ
ಕೋಡ್ ಕವರೇಜ್ ನಿಮ್ಮ ಕೋಡ್‌ನ ಎಷ್ಟು ಶೇಕಡಾವಾರು ಭಾಗವು ನಿಮ್ಮ ಪರೀಕ್ಷೆಗಳಿಂದ ಕಾರ್ಯಗತಗೊಂಡಿದೆ ಎಂಬುದನ್ನು ಅಳೆಯುತ್ತದೆ. 100% ಕವರೇಜ್ ಯಾವಾಗಲೂ ಪ್ರಾಯೋಗಿಕ ಅಥವಾ ಉಪಯುಕ್ತ ಗುರಿಯಲ್ಲದಿದ್ದರೂ, ಈ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಪರೀಕ್ಷಿಸದ ಭಾಗಗಳನ್ನು ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. Jest ನಂತಹ ಪರಿಕರಗಳು ಕವರೇಜ್ ವರದಿಗಳನ್ನು ರಚಿಸಬಹುದು. ಕಾಲಾನಂತರದಲ್ಲಿ ಕವರೇಜ್ ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಮತ್ತು ಕವರೇಜ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಿತಿಗಿಂತ ಕಡಿಮೆಯಾದರೆ ಬಿಲ್ಡ್ ಅನ್ನು ವಿಫಲಗೊಳಿಸಲು ನೀವು Codecov ಅಥವಾ Coveralls ನಂತಹ ಸೇವೆಗಳನ್ನು ನಿಮ್ಮ CI ಪೈಪ್‌ಲೈನ್‌ಗೆ ಸಂಯೋಜಿಸಬಹುದು.
Codecov ಗೆ ಕವರೇಜ್ ಅಪ್‌ಲೋಡ್ ಮಾಡಲು ಒಂದು ಉದಾಹರಣೆ ಹಂತ:
- name: Upload coverage to Codecov
uses: codecov/codecov-action@v4
with:
token: ${{ secrets.CODECOV_TOKEN }}
ರಹಸ್ಯಗಳು ಮತ್ತು ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ API ಕೀಗಳು, ಡೇಟಾಬೇಸ್ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳು, ಅಥವಾ ಇತರ ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಯ ಅಗತ್ಯವಿರುತ್ತದೆ, ವಿಶೇಷವಾಗಿ E2E ಪರೀಕ್ಷೆಗಳಿಗೆ. ಇವುಗಳನ್ನು ಎಂದಿಗೂ ನೇರವಾಗಿ ನಿಮ್ಮ ಕೋಡ್‌ಗೆ ಕಮಿಟ್ ಮಾಡಬೇಡಿ. ಪ್ರತಿಯೊಂದು CI ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ರಹಸ್ಯಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಸಂಗ್ರಹಿಸಲು ಒಂದು ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ.
- GitHub Actions ನಲ್ಲಿ, ನೀವು ಅವುಗಳನ್ನು `Settings > Secrets and variables > Actions` ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು. ನಂತರ ಅವು ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋನಲ್ಲಿ `secrets` ಸಂದರ್ಭದ ಮೂಲಕ ಲಭ್ಯವಿರುತ್ತವೆ, ಉದಾಹರಣೆಗೆ `${{ secrets.MY_API_KEY }}`.
- GitLab CI/CD ನಲ್ಲಿ, ಇವುಗಳನ್ನು `Settings > CI/CD > Variables` ಅಡಿಯಲ್ಲಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ.
- Jenkins ನಲ್ಲಿ, ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳನ್ನು ಅದರ ಅಂತರ್ನಿರ್ಮಿತ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಸ್ ಮ್ಯಾನೇಜರ್ ಮೂಲಕ ನಿರ್ವಹಿಸಬಹುದು.
ಷರತ್ತುಬದ್ಧ ವರ್ಕ್‌ಫ್ಲೋಗಳು ಮತ್ತು ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು
ನೀವು ಯಾವಾಗಲೂ ಪ್ರತಿ ಕಮಿಟ್‌ಗೆ ಪ್ರತಿ ಜಾಬ್ ಅನ್ನು ರನ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಸಮಯ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸಲು ನಿಮ್ಮ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನೀವು ಉತ್ತಮಗೊಳಿಸಬಹುದು:
- ದುಬಾರಿ E2E ಪರೀಕ್ಷೆಗಳನ್ನು ಕೇವಲ ಪುಲ್ ವಿನಂತಿಗಳ ಮೇಲೆ ಅಥವಾ `main` ಬ್ರಾಂಚ್‌ಗೆ ವಿಲೀನಗೊಂಡಾಗ ಮಾತ್ರ ಚಲಾಯಿಸಿ.
- `paths-ignore` ಬಳಸಿ ಕೇವಲ ದಾಖಲಾತಿ ಬದಲಾವಣೆಗಳಿಗಾಗಿ CI ರನ್‌ಗಳನ್ನು ಸ್ಕಿಪ್ ಮಾಡಿ.
- ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ Node.js ಆವೃತ್ತಿಗಳು ಅಥವಾ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳ ವಿರುದ್ಧ ಪರೀಕ್ಷಿಸಲು ಮ್ಯಾಟ್ರಿಕ್ಸ್ ತಂತ್ರಗಳನ್ನು ಬಳಸಿ.
CI ಯ ಆಚೆಗೆ: ನಿರಂತರ ಡಿಪ್ಲಾಯ್‌ಮೆಂಟ್ (CD) ಗೆ ದಾರಿ
ನಿರಂತರ ಏಕೀಕರಣವು ಸಮೀಕರಣದ ಮೊದಲಾರ್ಧವಾಗಿದೆ. ಸ್ವಾಭಾವಿಕ ಮುಂದಿನ ಹಂತವೆಂದರೆ ನಿರಂತರ ವಿತರಣೆ (Continuous Delivery) ಅಥವಾ ನಿರಂತರ ಡಿಪ್ಲಾಯ್‌ಮೆಂಟ್ (Continuous Deployment) (CD).
- ನಿರಂತರ ವಿತರಣೆ: ಮುಖ್ಯ ಬ್ರಾಂಚ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳು ಪಾಸ್ ಆದ ನಂತರ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬಿಲ್ಡ್ ಆಗಿ ಬಿಡುಗಡೆಗೆ ಸಿದ್ಧವಾಗುತ್ತದೆ. ಅದನ್ನು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಲು ಅಂತಿಮ, ಹಸ್ತಚಾಲಿತ ಅನುಮೋದನೆಯ ಹಂತದ ಅಗತ್ಯವಿದೆ.
- ನಿರಂತರ ಡಿಪ್ಲಾಯ್‌ಮೆಂಟ್: ಇದು ಒಂದು ಹೆಜ್ಜೆ ಮುಂದೆ ಹೋಗುತ್ತದೆ. ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳು ಪಾಸ್ ಆದರೆ, ಯಾವುದೇ ಮಾನವ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ಹೊಸ ಆವೃತ್ತಿಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಲ್ಪಡುತ್ತದೆ.
ನೀವು ನಿಮ್ಮ CI ವರ್ಕ್‌ಫ್ಲೋಗೆ `deploy` ಜಾಬ್ ಅನ್ನು ಸೇರಿಸಬಹುದು, ಇದು `main` ಬ್ರಾಂಚ್‌ಗೆ ಯಶಸ್ವಿ ವಿಲೀನದ ಮೇಲೆ ಮಾತ್ರ ಪ್ರಚೋದಿಸಲ್ಪಡುತ್ತದೆ. ಈ ಜಾಬ್ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು Vercel, Netlify, AWS, Google Cloud, ಅಥವಾ ನಿಮ್ಮ ಸ್ವಂತ ಸರ್ವರ್‌ಗಳಂತಹ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸಲು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.
GitHub Actions ನಲ್ಲಿ ಒಂದು ಕಾನ್ಸೆಪ್ಚುವಲ್ ಡಿಪ್ಲಾಯ್ ಜಾಬ್:
deploy:
needs: [unit-tests, e2e-tests]
runs-on: ubuntu-latest
# ಈ ಜಾಬ್ ಅನ್ನು main ಬ್ರಾಂಚ್‌ಗೆ ಪುಶ್ ಮಾಡಿದಾಗ ಮಾತ್ರ ರನ್ ಮಾಡಿ
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
steps:
# ... ಚೆಕ್‌ಔಟ್, ಸೆಟಪ್, ಬಿಲ್ಡ್ ಹಂತಗಳು ...
- name: Deploy to Production
run: ./deploy-script.sh # ನಿಮ್ಮ ಡಿಪ್ಲಾಯ್‌ಮೆಂಟ್ ಕಮಾಂಡ್
env:
DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
ತೀರ್ಮಾನ: ಕೇವಲ ಒಂದು ಸಾಧನವಲ್ಲ, ಒಂದು ಸಾಂಸ್ಕೃತಿಕ ಬದಲಾವಣೆ
ನಿಮ್ಮ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಿಗಾಗಿ CI ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸುವುದು ತಾಂತ್ರಿಕ ಕಾರ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿದೆ; ಇದು ಗುಣಮಟ್ಟ, ವೇಗ ಮತ್ತು ಸಹಯೋಗಕ್ಕೆ ಒಂದು ಬದ್ಧತೆಯಾಗಿದೆ. ಇದು ಒಂದು ಸಂಸ್ಕೃತಿಯನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಪ್ರತಿಯೊಬ್ಬ ತಂಡದ ಸದಸ್ಯ, ಅವರ ಸ್ಥಳವನ್ನು ಲೆಕ್ಕಿಸದೆ, ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಕೊಡುಗೆ ನೀಡಲು ಅಧಿಕಾರವನ್ನು ಪಡೆಯುತ್ತಾರೆ, ಒಂದು ಶಕ್ತಿಯುತ ಸ್ವಯಂಚಾಲಿತ ಸುರಕ್ಷತಾ ಜಾಲವು ಜಾರಿಯಲ್ಲಿದೆ ಎಂದು ತಿಳಿದಿರುತ್ತಾರೆ.
ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳ ಒಂದು ದೃಢವಾದ ಅಡಿಪಾಯದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ—ವೇಗದ ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳಿಂದ ಹಿಡಿದು ಸಮಗ್ರ E2E ಬಳಕೆದಾರರ ಪ್ರಯಾಣಗಳವರೆಗೆ—ಮತ್ತು ಅವುಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತ CI ವರ್ಕ್‌ಫ್ಲೋಗೆ ಸಂಯೋಜಿಸುವ ಮೂಲಕ, ನಿಮ್ಮ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನೀವು ಪರಿವರ್ತಿಸುತ್ತೀರಿ. ನೀವು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುವ ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕ ಸ್ಥಿತಿಯಿಂದ ಅವುಗಳನ್ನು ತಡೆಯುವ ಪೂರ್ವಭಾವಿ ಸ್ಥಿತಿಗೆ ಚಲಿಸುತ್ತೀರಿ. ಇದರ ಫಲಿತಾಂಶವು ಹೆಚ್ಚು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಅಪ್ಲಿಕೇಶನ್, ಹೆಚ್ಚು ಉತ್ಪಾದಕ ಅಭಿವೃದ್ಧಿ ತಂಡ, ಮತ್ತು ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಹಿಂದೆಂದಿಗಿಂತಲೂ ವೇಗವಾಗಿ ಮತ್ತು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಮೌಲ್ಯವನ್ನು ತಲುಪಿಸುವ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ.
ನೀವು ಇನ್ನೂ ಪ್ರಾರಂಭಿಸದಿದ್ದರೆ, ಇಂದೇ ಪ್ರಾರಂಭಿಸಿ. ಚಿಕ್ಕದಾಗಿ ಪ್ರಾರಂಭಿಸಿ—ಬಹುಶಃ ಒಂದು ಲಿಂಟರ್ ಮತ್ತು ಕೆಲವು ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳೊಂದಿಗೆ. ಕ್ರಮೇಣ ನಿಮ್ಮ ಪರೀಕ್ಷಾ ವ್ಯಾಪ್ತಿಯನ್ನು ವಿಸ್ತರಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಆರಂಭಿಕ ಹೂಡಿಕೆಯು ಸ್ಥಿರತೆ, ವೇಗ ಮತ್ತು ಮನಸ್ಸಿನ ಶಾಂತಿಯಲ್ಲಿ ಹಲವು ಪಟ್ಟು ಮರುಪಾವತಿಯಾಗುತ್ತದೆ.