CI/CD ಎಂದರೇನು? Continuous Integration ಮತ್ತು Delivery ಸರಳ ವಿವರಣೆ
CI/CD ಎಂದರೆ ಸಾಫ್ಟ್‌ವೇರ್ ಬಿಡುಗಡೆ ಮಾಡುವ ಒಂದು ವಿಧಾನ, ಇದರಲ್ಲಿ ಪ್ರತಿ ಕೋಡ್ ಬದಲಾವಣೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ, ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು — ಉತ್ತೀರ್ಣವಾದರೆ — ಬಿಡುಗಡೆಗೆ ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತದೆ ಅಥವಾ ಬಿಡುಗಡೆ ಮಾಡಲಾಗುತ್ತದೆ. CI (continuous integration) ಎಂದರೆ ಬದಲಾವಣೆಗಳನ್ನು ಆಗಾಗ್ಗೆ ವಿಲೀನಗೊಳಿಸಿ ಪ್ರತಿ ಬಾರಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳಿಂದ ಪರಿಶೀಲಿಸುವುದು. CD (continuous delivery ಅಥವಾ deployment) ಎಂದರೆ ಉತ್ತೀರ್ಣವಾದ ಬದಲಾವಣೆಗಳನ್ನು ಕಡಿಮೆ ಅಥವಾ ಯಾವುದೇ ಹಸ್ತಚಾಲಿತ ಕೆಲಸವಿಲ್ಲದೆ ಪ್ಯಾಕೇಜ್ ಮಾಡಿ ಬಳಕೆದಾರರ ಕಡೆಗೆ ತಳ್ಳುವುದು.
ಮುಖ್ಯ ಅಂಶ ಸರಳ: ತಪ್ಪುಗಳನ್ನು ವಾರಗಳ ನಂತರ ಗ್ರಾಹಕ ಕಂಡುಹಿಡಿಯುವ ಬದಲು, ಮಾಡಿದ ನಿಮಿಷಗಳೊಳಗೆ ಹಿಡಿಯುವುದು.
AI ಜೊತೆ ನಿರ್ಮಿಸುವಾಗ CI/CD ಏಕೆ ಮುಖ್ಯ
AI ಬಿಲ್ಡರ್‌ಗಳು ಕೋಡ್ ಬದಲಾವಣೆಗಳನ್ನು ವೇಗವಾಗಿ ಮಾಡುತ್ತವೆ. ಒಂದೇ ಪ್ರಾಂಪ್ಟ್ ಹತ್ತು ಫೈಲ್‌ಗಳನ್ನು ಮುಟ್ಟಬಹುದು. ಚೆಕ್‌ಔಟ್ ಪುಟದ ಬದಲಾವಣೆ ಲಾಗಿನ್ ಪುಟವನ್ನು ಶಾಂತವಾಗಿ ಮುರಿದು, ಬಳಕೆದಾರರು ನಿಮಗೆ ಇಮೇಲ್ ಮಾಡುವವರೆಗೆ ಯಾರಿಗೂ ಗೊತ್ತಾಗದಿದ್ದರೆ ಆ ವೇಗ ಅದ್ಭುತವಾಗಿದ್ದರೂ ಅಪಾಯಕಾರಿ.
CI/CD ಇದಕ್ಕೆ ಸರಿಯಾದ ಸುರಕ್ಷತಾ ಜಾಲ. ಪ್ರತಿ ಬದಲಾವಣೆ ಸರಿಯಾಗಿದೆ ಎಂದು ನಂಬುವ ಬದಲು, ಪೈಪ್‌ಲೈನ್ ಪ್ರತಿ ಬಾರಿ ಒಂದೇ ಪರಿಶೀಲನೆಗಳನ್ನು ನಡೆಸುತ್ತದೆ:
- ಆ್ಯಪ್ ದೋಷಗಳಿಲ್ಲದೆ ಇನ್ನೂ ನಿರ್ಮಿತವಾಗುತ್ತದೆಯೇ?
- ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಇನ್ನೂ ಉತ್ತೀರ್ಣವಾಗುತ್ತವೆಯೇ?
- ಕೋಡ್ ಯೋಜನೆಯ ನಿಯಮಗಳನ್ನು (ಟೈಪ್‌ಗಳು, ಫಾರ್ಮ್ಯಾಟಿಂಗ್, ಭದ್ರತಾ ಪರಿಶೀಲನೆಗಳು) ಪಾಲಿಸುತ್ತದೆಯೇ?
ಯಾವುದೇ ಪರಿಶೀಲನೆ ವಿಫಲವಾದರೆ, ಬದಲಾವಣೆ ಬಳಕೆದಾರರನ್ನು ತಲುಪುವ ಮೊದಲೇ ನಿಲ್ಲಿಸಲಾಗುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್ ಬದಲಾವಣೆ ವೇಗವಾದಷ್ಟೂ, ಎಂದಿಗೂ ದಣಿಯದ ಅಥವಾ ಯಾವುದೇ ಹಂತವನ್ನು ಬಿಟ್ಟುಬಿಡದ ಪರಿಶೀಲನೆ ಹೆಚ್ಚು ಮೌಲ್ಯಯುತ.
ದಿನನಿತ್ಯದ ಉದಾಹರಣೆ
ಪ್ರತಿ ಬೆಳಿಗ್ಗೆ ಅಂಗಡಿಗಳಿಗೆ ಬ್ರೆಡ್ ಮಾರುವ ಬೇಕರಿಯನ್ನು ಯೋಚಿಸಿ.
- CI/CD ಇಲ್ಲದೆ, ಪ್ರತಿ ಬೇಕರ್ ಒಂದು ವಾರ ತಮ್ಮದೇ ಪಾಕವಿಧಾನದ ಬದಲಾವಣೆಗಳ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ, ನಂತರ ಶುಕ್ರವಾರ ರಾತ್ರಿ ಎಲ್ಲವನ್ನೂ ಸೇರಿಸಿ ಬ್ರೆಡ್ ಇನ್ನೂ ಏರುತ್ತದೆಯೇ ಎಂದು ಆಶಿಸುತ್ತಾರೆ. ಅದು ಏರದಿದ್ದಾಗ, ಯಾರ ಬದಲಾವಣೆ ಅದಕ್ಕೆ ಕಾರಣ ಎಂದು ಯಾರಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ.
- CI ಇದ್ದರೆ, ಪ್ರತಿ ಸಣ್ಣ ಪಾಕವಿಧಾನ ಬದಲಾವಣೆಯನ್ನು ತಕ್ಷಣ ಪರೀಕ್ಷಾ ರೊಟ್ಟಿಯಲ್ಲಿ ಬೇಯಿಸಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ — ರುಚಿ, ತೂಕ, ಆಕಾರ. ತಪ್ಪು ಬದಲಾವಣೆ ಅದೇ ದಿನ ಸಿಕ್ಕಿಬೀಳುತ್ತದೆ, ಮತ್ತು ಅದು ಯಾವುದು ಎಂದು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿಯುತ್ತದೆ.
- CD ಇದ್ದರೆ, ಪರಿಶೀಲನೆ ಉತ್ತೀರ್ಣವಾದ ರೊಟ್ಟಿಗಳು ನೇರವಾಗಿ ವಿತರಣಾ ವ್ಯಾನ್‌ಗೆ ಹೋಗುತ್ತವೆ, ಪ್ರತಿ ಬಾರಿಯೂ ಒಂದೇ ರೀತಿ ಪ್ಯಾಕ್ ಮಾಡಿ ಲೇಬಲ್ ಮಾಡಲಾಗಿರುತ್ತದೆ — ಬೆಳಿಗ್ಗೆ 5 ಗಂಟೆಗೆ ಯಾರೋ ಕೈಯಿಂದ ಪೆಟ್ಟಿಗೆ ತುಂಬುವ ಬದಲು.
ಪರಿಶೀಲನೆ ಬೇಕರ್‌ಗಳನ್ನು ಉತ್ತಮರನ್ನಾಗಿ ಮಾಡುವುದಿಲ್ಲ. ಅದು ಅವರ ತಪ್ಪುಗಳನ್ನು ಅಗ್ಗವಾಗಿಸುತ್ತದೆ.
CI/CD ಪೈಪ್‌ಲೈನ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ
ಪೈಪ್‌ಲೈನ್ ಎಂದರೆ ಏನಾದರೂ ಸಂಭವಿಸಿದಾಗ CI/CD ಸೇವೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಚಲಾಯಿಸುವ ಹಂತಗಳ ಪಟ್ಟಿ — ಸಾಮಾನ್ಯವಾಗಿ ಯಾರಾದರೂ GitHub ನಂತಹ ರೆಪೊಸಿಟರಿಗೆ ಕೋಡ್ ತಳ್ಳಿದಾಗ. ಸಾಮಾನ್ಯ ಪೈಪ್‌ಲೈನ್ ಹೀಗಿರುತ್ತದೆ:
| ಹಂತ | ಏನು ಸಂಭವಿಸುತ್ತದೆ | ಏನನ್ನು ಹಿಡಿಯುತ್ತದೆ |
|---|---|---|
| 1. ಪ್ರಚೋದನೆ | ಕೋಡ್ ತಳ್ಳಲಾಗುತ್ತದೆ ಅಥವಾ ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ ತೆರೆಯಲಾಗುತ್ತದೆ | — |
| 2. ಇನ್‌ಸ್ಟಾಲ್ | ಹೊಸ ಯಂತ್ರ ಕೋಡ್ ಮತ್ತು ಅವಲಂಬನೆಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ | ಕಾಣೆಯಾದ ಅಥವಾ ಮುರಿದ ಪ್ಯಾಕೇಜ್‌ಗಳು |
| 3. ನಿರ್ಮಾಣ (Build) | ಆ್ಯಪ್ ಕಂಪೈಲ್ ಅಥವಾ ಬಂಡಲ್ ಮಾಡಲಾಗುತ್ತದೆ | ಸಿಂಟ್ಯಾಕ್ಸ್ ಮತ್ತು ಟೈಪ್ ದೋಷಗಳು, ಮುರಿದ ಆಮದುಗಳು |
| 4. ಪರೀಕ್ಷೆ | ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಚಲಿಸುತ್ತವೆ | ಇನ್ನು ಕೆಲಸ ಮಾಡದ ವೈಶಿಷ್ಟ್ಯಗಳು |
| 5. ಪರಿಶೀಲನೆಗಳು | ಲಿಂಟಿಂಗ್, ಫಾರ್ಮ್ಯಾಟಿಂಗ್, ಭದ್ರತಾ ಸ್ಕ್ಯಾನ್‌ಗಳು | ಶೈಲಿ ಸಮಸ್ಯೆಗಳು, ತಿಳಿದಿರುವ ದುರ್ಬಲ ಪ್ಯಾಕೇಜ್‌ಗಳು, ಸೋರಿಕೆಯಾದ ಕೀಗಳು |
| 6. ಸ್ಟೇಜಿಂಗ್‌ಗೆ ಡಿಪ್ಲಾಯ್ | ಆ್ಯಪ್ ಪ್ರೊಡಕ್ಷನ್‌ನ ಪರೀಕ್ಷಾ ಪ್ರತಿಗೆ ಹೋಗುತ್ತದೆ | ನಿಜವಾದ ಪರಿಸರದಲ್ಲಿ ಮಾತ್ರ ಕಾಣುವ ಸಮಸ್ಯೆಗಳು |
| 7. ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ಡಿಪ್ಲಾಯ್ | ಆ್ಯಪ್ ಲೈವ್ ಆಗುತ್ತದೆ — ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಥವಾ ಅನುಮೋದನೆಯ ನಂತರ | — |
ಪ್ರತಿ ಹಂತ ಯಾರದೋ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಅಲ್ಲ, ಸ್ವಚ್ಛ ಯಂತ್ರದಲ್ಲಿ ಚಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ "ನನ್ನ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ" ಎನ್ನುವುದು ಸಬೂಬು ಆಗುವುದಿಲ್ಲ. ಒಂದು ಹಂತ ವಿಫಲವಾದರೆ, ಪೈಪ್‌ಲೈನ್ ನಿಲ್ಲುತ್ತದೆ ಮತ್ತು ಬದಲಾವಣೆ ಮಾಡಿದವರಿಗೆ ತಿಳಿಸುತ್ತದೆ.
ಹಂತಗಳನ್ನು ಕೋಡ್ ಜೊತೆ ಇರುವ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ GitHub Actions ನಲ್ಲಿ, ಅದು ರೆಪೊಸಿಟರಿಯ .github/workflows ಫೋಲ್ಡರ್‌ನಲ್ಲಿರುವ YAML ಫೈಲ್.
Continuous delivery vs continuous deployment
"CD" ಎನ್ನುವುದು ಅಸ್ಪಷ್ಟ, ಮತ್ತು ಜನರು ಇದನ್ನು ಎರಡೂ ರೀತಿಯಲ್ಲಿ ಬಳಸುತ್ತಾರೆ:
| Continuous delivery | Continuous deployment | |
|---|---|---|
| ಪರೀಕ್ಷೆಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಚಲಿಸುತ್ತವೆ | ಹೌದು | ಹೌದು |
| ಬಿಡುಗಡೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ಯಾಕೇಜ್ ಆಗುತ್ತದೆ | ಹೌದು | ಹೌದು |
| ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಲೈವ್ ಆಗುತ್ತದೆ | ಇಲ್ಲ — ವ್ಯಕ್ತಿ "ಬಿಡುಗಡೆ" ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾರೆ | ಹೌದು — ಉತ್ತೀರ್ಣವಾದ ಪ್ರತಿ ಬದಲಾವಣೆ ಬಿಡುಗಡೆಯಾಗುತ್ತದೆ |
| ಯಾರಿಗೆ ಒಳ್ಳೆಯದು | ಹೆಚ್ಚಿನ ಸಣ್ಣ ತಂಡಗಳು, ಪಾವತಿಸುವ ಬಳಕೆದಾರರಿರುವ ಆ್ಯಪ್‌ಗಳು | ಬಲವಾದ ಪರೀಕ್ಷಾ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಇರುವ ತಂಡಗಳು |
ಪರೀಕ್ಷೆಗಳು ಉತ್ತಮವಾಗಿದ್ದರೆ ಮಾತ್ರ continuous deployment ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ ಪರೀಕ್ಷೆಗಳು ಚೆಕ್‌ಔಟ್ ಅನ್ನು ಒಳಗೊಳ್ಳದಿದ್ದರೆ, continuous deployment ಮುರಿದ ಚೆಕ್‌ಔಟ್ ಅನ್ನು ಸಂತೋಷದಿಂದ ಬಿಡುಗಡೆ ಮಾಡುತ್ತದೆ.
ಒಂದು ಕೆಲಸ ಮಾಡಿದ ಉದಾಹರಣೆ: ಪೈಪ್‌ಲೈನ್ ಇರುವ ಬುಕಿಂಗ್ ಆ್ಯಪ್
ನಿಮ್ಮ ಬಳಿ ಸಲೂನ್ ಬುಕಿಂಗ್ ಆ್ಯಪ್ ಇದೆ, ಮತ್ತು ಅದರ ಕೋಡ್ GitHub ರೆಪೊಸಿಟರಿಯಲ್ಲಿದೆ ಎಂದು ಭಾವಿಸಿ. ನೀವು AI ಬಿಲ್ಡರ್‌ಗೆ "ಮೊದಲ ಬಾರಿ ಗ್ರಾಹಕರಿಗೆ 10% ರಿಯಾಯಿತಿ ಸೇರಿಸಿ" ಎಂದು ಕೇಳುತ್ತೀರಿ.
- ಬದಲಾವಣೆಯನ್ನು ಹೊಸ ಬ್ರಾಂಚ್‌ಗೆ ತಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ ತೆರೆಯಲಾಗುತ್ತದೆ.
- ಪೈಪ್‌ಲೈನ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಅದು ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿ ಆ್ಯಪ್ ನಿರ್ಮಿಸುತ್ತದೆ — ಇದು ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ.
- ಅದು ಪರೀಕ್ಷೆಗಳನ್ನು ಚಲಾಯಿಸುತ್ತದೆ. ಒಂದು ಪರೀಕ್ಷೆ, "ಹಿಂದಿರುಗಿದ ಗ್ರಾಹಕ ಪೂರ್ಣ ಬೆಲೆ ಪಾವತಿಸುತ್ತಾರೆ," ವಿಫಲವಾಗುತ್ತದೆ: ರಿಯಾಯಿತಿ ಎಲ್ಲರಿಗೂ ಅನ್ವಯವಾಗುತ್ತಿದೆ.
- ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ ಕೆಂಪು ಗುರುತು ತೋರಿಸುತ್ತದೆ. ಬದಲಾವಣೆಯನ್ನು ವಿಲೀನಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ.
- ನೀವು AI ಗೆ ಅದನ್ನು ಸರಿಪಡಿಸಲು ಕೇಳುತ್ತೀರಿ. ಅದು ತಿದ್ದುಪಡಿ ತಳ್ಳುತ್ತದೆ; ಪೈಪ್‌ಲೈನ್ ಮತ್ತೆ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ.
- ಬದಲಾವಣೆ ವಿಲೀನಗೊಳ್ಳುತ್ತದೆ. ಪೈಪ್‌ಲೈನ್ ಅದನ್ನು **ಸ್ಟೇಜಿಂಗ್ ಪರಿಸರ**ಕ್ಕೆ ಡಿಪ್ಲಾಯ್ ಮಾಡುತ್ತದೆ, ಅಲ್ಲಿ ನೀವು ಒಂದು ಪರೀಕ್ಷಾ ಬುಕಿಂಗ್ ಪ್ರಯತ್ನಿಸುತ್ತೀರಿ.
- ನೀವು ಅನುಮೋದಿಸುತ್ತೀರಿ, ಮತ್ತು ಅದು ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ಡಿಪ್ಲಾಯ್ ಆಗುತ್ತದೆ.
ಪೈಪ್‌ಲೈನ್ ಇಲ್ಲದಿದ್ದರೆ, ಹಂತ 3 ನಿಮ್ಮ ಗ್ರಾಹಕರ ಹಣದ ಮೇಲೆಯೇ ನಡೆಯುತ್ತಿತ್ತು.
ಪ್ರಮುಖ ಪದಗಳು
| ಪದ | ಅರ್ಥ |
|---|---|
| ಪೈಪ್‌ಲೈನ್ (Pipeline) | ಪ್ರತಿ ಬದಲಾವಣೆಯ ಮೇಲೆ ಚಲಿಸುವ ಸ್ವಯಂಚಾಲಿತ ಹಂತಗಳ ಅನುಕ್ರಮ. |
| ನಿರ್ಮಾಣ (Build) | ಮೂಲ ಕೋಡ್ ಅನ್ನು ಚಲಾಯಿಸಬಹುದಾದ ವಸ್ತುವಾಗಿ ಪರಿವರ್ತಿಸುವುದು. |
| ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ (Automated test) | ಇತರ ಕೋಡ್ ಸರಿಯಾಗಿ ಮಾಡಬೇಕಾದದ್ದನ್ನು ಮಾಡುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವ ಕೋಡ್. |
| ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ (PR) | ವಿಲೀನಗೊಳ್ಳುವ ಮೊದಲು ಇತರರು (ಮತ್ತು ಪೈಪ್‌ಲೈನ್) ಪರಿಶೀಲಿಸುವ ಪ್ರಸ್ತಾವಿತ ಬದಲಾವಣೆ. GitHub ಎಂದರೇನು ನೋಡಿ. |
| ಬ್ರಾಂಚ್ (Branch) | ಪ್ರಗತಿಯಲ್ಲಿರುವ ಕೆಲಸ ಮುಖ್ಯ ಕೋಡ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಂತೆ ಪ್ರತ್ಯೇಕ ಬದಲಾವಣೆಗಳ ಸಾಲು. |
| ಸ್ಟೇಜಿಂಗ್ (Staging) | ಬಳಕೆದಾರರು ನೋಡುವ ಮೊದಲು ಬದಲಾವಣೆಗಳನ್ನು ಪರಿಶೀಲಿಸಲು, ಪ್ರೊಡಕ್ಷನ್‌ನ ಖಾಸಗಿ ಪ್ರತಿ. |
| ಪ್ರೊಡಕ್ಷನ್ (Production) | ನಿಮ್ಮ ಬಳಕೆದಾರರು ಬಳಸುವ ಲೈವ್ ಆ್ಯಪ್. |
| ರೋಲ್‌ಬ್ಯಾಕ್ (Rollback) | ಬಿಡುಗಡೆ ತಪ್ಪಾದಾಗ ಹಿಂದಿನ ಕೆಲಸ ಮಾಡುವ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗುವುದು. |
| ಹಸಿರು / ಕೆಂಪು ಬಿಲ್ಡ್ (Green / red build) | ಉತ್ತೀರ್ಣವಾದ / ವಿಫಲವಾದ ಪೈಪ್‌ಲೈನ್ ರನ್. |
ಸಾಮಾನ್ಯ ತಪ್ಪು ಕಲ್ಪನೆಗಳು
- "CI/CD ಎಂದರೆ ನನ್ನ ಆ್ಯಪ್ ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟಿದೆ." ಪೈಪ್‌ಲೈನ್ ನಿಮಗೆ ಇರುವ ಪರೀಕ್ಷೆಗಳನ್ನು ಮಾತ್ರ ಚಲಾಯಿಸುತ್ತದೆ. ಪರೀಕ್ಷೆಗಳೇ ಇಲ್ಲದಿದ್ದರೆ, CI ಆ್ಯಪ್ ನಿರ್ಮಿತವಾಗುತ್ತದೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ — ಅದಕ್ಕಿಂತ ಹೆಚ್ಚೇನೂ ಇಲ್ಲ. ಅತಿ ಮುಖ್ಯವಾದ ಹರಿವುಗಳಿಗೆ ಪರೀಕ್ಷೆ ಬರೆಯಲು AI ಗೆ ಕೇಳಿ.
- "CI/CD ದೊಡ್ಡ ಕಂಪನಿಗಳಿಗೆ ಮಾತ್ರ." GitHub Actions ನಂತಹ ಹೋಸ್ಟ್ ಮಾಡಿದ ಸಾಧನಗಳಿಗೆ ಸೆಟಪ್ ಮಾಡಲು ಸಣ್ಣ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಬೇಕು, ಮತ್ತು ಸಣ್ಣ ತಂಡಗಳು ಅವನ್ನು ಸದಾ ಬಳಸುತ್ತವೆ. ಪ್ರಯತ್ನ ಬೇಕಾಗುವುದು ಸಾಧನಕ್ಕಲ್ಲ, ಪರೀಕ್ಷೆಗಳಿಗೆ.
- "ಸ್ವಯಂಚಾಲಿತ ಡಿಪ್ಲಾಯ್ ಎಂದರೆ ಯಾರೂ ಏನನ್ನೂ ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ." ಉತ್ತಮ ಪೈಪ್‌ಲೈನ್‌ಗಳು ಪರಿಶೀಲನೆಗಳನ್ನು ಸೇರಿಸುತ್ತವೆ, ತೆಗೆಯುವುದಿಲ್ಲ. ಅನೇಕ ತಂಡಗಳು ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ಮೊದಲು ಮಾನವ ಅನುಮೋದನೆ ಹಂತವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ.
- "ಪೈಪ್‌ಲೈನ್ ಹಸಿರಾಗಿದ್ದರೆ, ಆ್ಯಪ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ." ಅಂದರೆ ಸ್ವಯಂಚಾಲಿತ ಪರಿಶೀಲನೆಗಳು ಉತ್ತೀರ್ಣವಾಗಿವೆ. ನೀವು ಇನ್ನೂ ಬದಲಾವಣೆಯನ್ನು ನೀವೇ ಪ್ರಯತ್ನಿಸಬೇಕು, ಆದರ್ಶವಾಗಿ ಪೂರ್ವವೀಕ್ಷಣೆ ಅಥವಾ ಸ್ಟೇಜಿಂಗ್‌ನಲ್ಲಿ.
- "CI/CD ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಬದಲಿಸುತ್ತದೆ." ಇಲ್ಲ. ಪರೀಕ್ಷೆಗಳನ್ನು ಉತ್ತೀರ್ಣಗೊಳಿಸುವ ಕೆಟ್ಟ ಡೇಟಾಬೇಸ್ ಮೈಗ್ರೇಷನ್ ಇನ್ನೂ ನಿಜವಾದ ಡೇಟಾವನ್ನು ಹಾನಿಗೊಳಿಸಬಹುದು. ಬ್ಯಾಕಪ್‌ಗಳು ಮತ್ತು ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ.
ನಿಮ್ಮ AI ಬಿಲ್ಡರ್‌ಗೆ ಏನು ಕೇಳಬೇಕು
- "ಸೈನ್-ಅಪ್, ಲಾಗಿನ್ ಮತ್ತು ಚೆಕ್‌ಔಟ್‌ಗಾಗಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಿರಿ, ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ಚಲಾಯಿಸುವುದು ಎಂದು ತೋರಿಸಿ."
- "ಪ್ರತಿ ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್‌ನಲ್ಲಿ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿ, ಆ್ಯಪ್ ನಿರ್ಮಿಸಿ ಮತ್ತು ಪರೀಕ್ಷೆಗಳನ್ನು ಚಲಾಯಿಸುವ GitHub Actions ವರ್ಕ್‌ಫ್ಲೋ ಸೆಟಪ್ ಮಾಡಿ."
- "ಪೈಪ್‌ಲೈನ್‌ಗೆ ಟೈಪ್ ಪರಿಶೀಲನೆ ಮತ್ತು ಲಿಂಟರ್ ಸೇರಿಸಿ, ಮತ್ತು ದೋಷಗಳಲ್ಲಿ ವಿಫಲವಾಗುವಂತೆ ಮಾಡಿ."
- "ಪೈಪ್‌ಲೈನ್‌ನ ಪ್ರತಿ ಹಂತ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಸರಳ ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿ ವಿವರಿಸಿ."
- "ಡಿಪ್ಲಾಯ್ ಅರ್ಧದಲ್ಲಿ ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ? ನಾನು ಹೇಗೆ ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡಬೇಕು?"
- "ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಅಥವಾ ಪೈಪ್‌ಲೈನ್ ಲಾಗ್‌ಗಳಲ್ಲಿ ಯಾವುದೇ ರಹಸ್ಯಗಳು ಹಾರ್ಡ್-ಕೋಡ್ ಆಗಿಲ್ಲ ಅಥವಾ ಮುದ್ರಣವಾಗಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸಿ."
ನಿಮ್ಮ ಆ್ಯಪ್ API ಕೀಗಳನ್ನು ಬಳಸಿದರೆ, ಪೈಪ್‌ಲೈನ್‌ಗೂ ಅವು ಬೇಕು — CI ಸಾಧನದಲ್ಲಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ರಹಸ್ಯಗಳಾಗಿ ಸಂಗ್ರಹಿಸಲ್ಪಟ್ಟು, ಎಂದಿಗೂ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ ಅಲ್ಲ. ಪರಿಸರ ವೇರಿಯೇಬಲ್‌ಗಳು ಮತ್ತು ರಹಸ್ಯಗಳು ನೋಡಿ.
CI/CD ಮತ್ತು Mythex
Mythex ನಿಮಗಾಗಿ CI ಪೈಪ್‌ಲೈನ್ ಚಲಾಯಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅದೇ ಕೆಲವು ಅಗತ್ಯಗಳನ್ನು ತನ್ನದೇ ರೀತಿಯಲ್ಲಿ ಪೂರೈಸುತ್ತದೆ:
- ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳು. ಪ್ರತಿ ಯಶಸ್ವಿ ಏಜೆಂಟ್ ತಿರುವಿನ ನಂತರ, Mythex git ಚೆಕ್‌ಪಾಯಿಂಟ್ ಉಳಿಸುತ್ತದೆ, ಮತ್ತು ಬದಲಾವಣೆ ತಪ್ಪಾದರೆ Revert to this point ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಹಿಂದಕ್ಕೆ ತಿರುಗಿಸುತ್ತದೆ. Chat ನೋಡಿ.
- ಆ್ಯಪ್ ಪರೀಕ್ಷೆ.
/testಟೈಪ್ ಮಾಡಿ, ಮತ್ತು ಏಜೆಂಟ್ ನಿಮ್ಮ ಲೈವ್ ಪೂರ್ವವೀಕ್ಷಣೆಯಲ್ಲಿ ಬಳಕೆದಾರರಂತೆ ಕ್ಲಿಕ್ ಮಾಡಿ ಮುರಿದ ಹರಿವುಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ — ಪ್ರತಿ ಪ್ರಕಟಣೆಗೆ ಮೊದಲು ಉಪಯುಕ್ತ. App Testing ನೋಡಿ. - ಪ್ರಕಟಣೆ ಉದ್ದೇಶಪೂರ್ವಕ ಹಂತ. ಬದಲಾವಣೆಗಳು ಮೊದಲು ಖಾಸಗಿ ಪೂರ್ವವೀಕ್ಷಣೆಯಲ್ಲಿ ಕಾಣಿಸುತ್ತವೆ; ನಿಮ್ಮ ಸಾರ್ವಜನಿಕ ಆ್ಯಪ್ ನೀವು ಮತ್ತೆ ಪ್ರಕಟಿಸಿದಾಗ ಮಾತ್ರ ನವೀಕರಣಗೊಳ್ಳುತ್ತದೆ — continuous deployment ಗಿಂತ continuous delivery ಗೆ ಹತ್ತಿರ.
- GitHub ಸಿಂಕ್ (Pro). ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು GitHub ರೆಪೊಸಿಟರಿಗೆ ಸಿಂಕ್ ಮಾಡಿದರೆ, ಪ್ರತಿ ಪುಶ್‌ನಲ್ಲಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಚಲಾಯಿಸಲು ನಿಮ್ಮದೇ GitHub Actions ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ಸೇರಿಸಬಹುದು. GitHub ಮತ್ತು ರಫ್ತು ನೋಡಿ.
ಲೈವ್ ಆಗುವ ಮೊದಲು ಕೈಯಿಂದ ಏನು ಪರೀಕ್ಷಿಸಬೇಕು ಎಂಬ ಪರಿಶೀಲನಾಪಟ್ಟಿಗಾಗಿ, ಬಿಡುಗಡೆ ಮೊದಲು ನಿಮ್ಮ ಆ್ಯಪ್ ಪರೀಕ್ಷಿಸುವುದು ಹೇಗೆ ನೋಡಿ, ಮತ್ತು ವರ್ಷನ್ ಕಂಟ್ರೋಲ್ ಜೊತೆ ಕೆಲಸ ಮಾಡಲು, AI ನಿರ್ಮಿತ ಆ್ಯಪ್‌ನೊಂದಿಗೆ Git ಬಳಸುವುದು ಹೇಗೆ ನೋಡಿ.
ಪ್ರಶ್ನೆಗಳು
CI/CD ಎಂಬುದರ ಅರ್ಥವೇನು?
CI ಎಂದರೆ continuous integration: ಪ್ರತಿ ಕೋಡ್ ಬದಲಾವಣೆಯನ್ನು ಆಗಾಗ್ಗೆ ವಿಲೀನಗೊಳಿಸಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ಮಿಸಿ ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ. CD ಎಂದರೆ continuous delivery ಅಥವಾ continuous deployment: ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣವಾದ ಬದಲಾವಣೆಗಳನ್ನು ಬಿಡುಗಡೆಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತದೆ (delivery) ಅಥವಾ ಹಸ್ತಚಾಲಿತ ಹಂತವಿಲ್ಲದೆ ಬಳಕೆದಾರರಿಗೆ ಬಿಡುಗಡೆ ಮಾಡಲಾಗುತ್ತದೆ (deployment).
Continuous delivery ಮತ್ತು continuous deployment ನಡುವಿನ ವ್ಯತ್ಯಾಸವೇನು?
Continuous delivery ಯಲ್ಲಿ, ಪೈಪ್‌ಲೈನ್ ಉತ್ತೀರ್ಣಗೊಳಿಸುವ ಪ್ರತಿ ಬದಲಾವಣೆ ಬಿಡುಗಡೆಗೆ ಸಿದ್ಧವಾಗಿರುತ್ತದೆ, ಆದರೆ ಅದನ್ನು ಲೈವ್ ಮಾಡುವ ಸಮಯವನ್ನು ಇನ್ನೂ ವ್ಯಕ್ತಿಯೇ ನಿರ್ಧರಿಸುತ್ತಾರೆ. Continuous deployment ನಲ್ಲಿ, ಉತ್ತೀರ್ಣಗೊಂಡ ಪ್ರತಿ ಬದಲಾವಣೆ ಮಾನವ ಅನುಮೋದನೆ ಇಲ್ಲದೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಲೈವ್ ಆಗುತ್ತದೆ.
AI ನಿರ್ಮಿತ ಸಣ್ಣ ಆ್ಯಪ್‌ಗೆ CI/CD ಬೇಕೇ?
ಮೊದಲ ದಿನದಿಂದಲೇ ಅಲ್ಲ. ಬೆರಳೆಣಿಕೆಯ ಬಳಕೆದಾರರಿರುವ ಸಣ್ಣ ಆ್ಯಪ್ ಪೂರ್ವವೀಕ್ಷಣೆಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ ಕೈಯಿಂದ ಪ್ರಕಟಿಸುವ ಮೂಲಕ ನಡೆಯಬಹುದು. ಹಲವು ಜನರು ಕೋಡ್ ಬದಲಿಸಿದಾಗ, ನಿಜವಾದ ಗ್ರಾಹಕರು ಆ್ಯಪ್ ಅವಲಂಬಿಸಿದಾಗ, ಅಥವಾ ಮೊದಲು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದದ್ದನ್ನು ಪದೇ ಪದೇ ಮುರಿಯುತ್ತಿದ್ದಾಗ CI/CD ತನ್ನ ಮೌಲ್ಯ ತೋರಿಸುತ್ತದೆ.
CI/CD ಗೆ ಯಾವ ಸಾಧನಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ?
ಸಾಮಾನ್ಯ ಸಾಧನಗಳಲ್ಲಿ GitHub Actions, GitLab CI/CD, CircleCI ಮತ್ತು Jenkins ಸೇರಿವೆ, ಜೊತೆಗೆ ಹೋಸ್ಟಿಂಗ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ಅಂತರ್ನಿರ್ಮಿತ ಡಿಪ್ಲಾಯ್ ಪೈಪ್‌ಲೈನ್‌ಗಳು. ಇವೆಲ್ಲವೂ ಒಂದೇ ಮೂಲ ಕೆಲಸ ಮಾಡುತ್ತವೆ: ಕೋಡ್ ಬದಲಾದಾಗಲೆಲ್ಲಾ ಹಂತಗಳ ಪಟ್ಟಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಚಲಾಯಿಸುವುದು.