CI/CD என்றால் என்ன? Continuous Integration, Delivery எளிய விளக்கம்

CI/CD என்பது மென்பொருளை வெளியிடும் ஒரு முறை: ஒவ்வொரு code மாற்றமும் தானாகவே build செய்யப்பட்டு, சோதிக்கப்பட்டு, தேறினால் வெளியீட்டுக்குத் தயார் செய்யப்படும் அல்லது வெளியிடப்படும். CI (continuous integration) என்றால் மாற்றங்கள் அடிக்கடி இணைக்கப்பட்டு ஒவ்வொரு முறையும் தானியங்கி சோதனைகளால் சரிபார்க்கப்படுகின்றன. CD (continuous delivery அல்லது deployment) என்றால் தேறிய மாற்றங்கள் குறைந்த அல்லது கைமுறை வேலை இல்லாமல் பயனர்களை நோக்கித் தொகுக்கப்பட்டு அனுப்பப்படுகின்றன.

நோக்கம் எளிது: தவறுகளை அவை செய்யப்பட்ட சில நிமிடங்களிலேயே பிடிப்பது — வாடிக்கையாளர் அவற்றைக் கண்டுபிடிக்கும் வாரங்கள் கழித்து அல்ல.

AI மூலம் உருவாக்கும்போது CI/CD ஏன் முக்கியம்

AI builders code மாற்றங்களை வேகமாகச் செய்கின்றன. ஒரே prompt பத்து கோப்புகளைத் தொடலாம். Checkout பக்கத்தில் செய்த மாற்றம் அமைதியாக login பக்கத்தை உடைத்தால், ஒரு பயனர் உங்களுக்கு email அனுப்பும் வரை யாருக்கும் தெரியாது என்பது வரை அந்த வேகம் நன்றாக இருக்கும்.

CI/CD இதற்கான பாதுகாப்பு வலை. ஒவ்வொரு மாற்றமும் சரி என்று நம்புவதற்குப் பதிலாக, ஒரு pipeline ஒவ்வொரு முறையும் அதே சோதனைகளை இயக்குகிறது:

• App இன்னும் பிழைகள் இல்லாமல் build ஆகிறதா?
• தானியங்கி சோதனைகள் இன்னும் தேறுகின்றனவா?
• Code திட்டத்தின் விதிகளைப் பின்பற்றுகிறதா (types, formatting, பாதுகாப்புச் சோதனைகள்)?

ஏதேனும் சோதனை தோல்வியடைந்தால், பயனர்களை அடையும் முன்பே மாற்றம் நிறுத்தப்படும். உங்கள் code எவ்வளவு வேகமாக மாறுகிறதோ, அவ்வளவு மதிப்புமிக்கது சோர்வடையாத, ஒரு படியையும் தவிர்க்காத சோதனை.

ஒரு அன்றாட உவமை

ஒவ்வொரு காலையும் கடைகளுக்கு ரொட்டி விற்கும் ஒரு பேக்கரியை நினையுங்கள்.

• CI/CD இல்லாவிட்டால், ஒவ்வொரு பேக்கரும் ஒரு வாரம் தனது செய்முறையை மாற்றிக்கொண்டிருப்பார்; வெள்ளிக்கிழமை இரவு எல்லாவற்றையும் சேர்த்து, ரொட்டி இன்னும் உப்புமா என்று நம்புவார்கள். உப்பாமல் போனால், எந்த மாற்றம் காரணம் என்று யாருக்கும் தெரியாது.
• CI உடன், ஒவ்வொரு சிறிய செய்முறை மாற்றமும் உடனே ஒரு சோதனை ரொட்டியாகச் சுடப்பட்டு சோதிக்கப்படும் — சுவை, எடை, வடிவம். ஒரு மோசமான மாற்றம் அன்றே பிடிபடும், எது காரணம் என்று சரியாகத் தெரியும்.
• CD உடன், சோதனையில் தேறிய ரொட்டிகள் நேராக விநியோக வேனுக்குச் செல்லும், ஒவ்வொரு முறையும் ஒரே மாதிரி பொட்டலமிட்டு லேபிள் ஒட்டப்பட்டு — அதிகாலை 5 மணிக்கு யாரோ கையால் பெட்டிகளில் அடுக்காமல்.

சோதனை பேக்கர்களை சிறந்தவர்களாக்குவதில்லை. அது அவர்களின் தவறுகளை மலிவாக்குகிறது.

CI/CD pipeline எப்படி வேலை செய்கிறது

Pipeline என்பது ஏதேனும் நிகழும்போது CI/CD சேவை தானாக இயக்கும் படிகளின் பட்டியல் — பொதுவாக யாராவது GitHub போன்ற repository-க்குக் code push செய்யும்போது. ஒரு வழக்கமான pipeline இப்படி இருக்கும்:

ஒவ்வொரு படியும் யாருடைய laptop-இலும் அல்ல, சுத்தமான இயந்திரத்தில் ஓடுகிறது; அதனால் “என் கணினியில் வேலை செய்கிறது” என்பது சாக்காகாது. ஒரு படி தோல்வியடைந்தால், pipeline நின்று மாற்றம் செய்தவருக்குத் தெரிவிக்கும்.

படிகள் code-உடனேயே இருக்கும் ஒரு கட்டமைப்பு கோப்பில் வரையறுக்கப்படுகின்றன. எடுத்துக்காட்டாக GitHub Actions-இல் அது repository-இன் .github/workflows கோப்புறையில் உள்ள YAML கோப்பு.

Continuous delivery மற்றும் continuous deployment

“CD” என்பது தெளிவற்றது; மக்கள் இரண்டு பொருளிலும் பயன்படுத்துகின்றனர்:

Continuous deployment சோதனைகள் நன்றாக இருந்தால் மட்டுமே நன்றாக வேலை செய்யும். உங்கள் சோதனைகள் checkout-ஐ உள்ளடக்கவில்லை என்றால், continuous deployment உடைந்த checkout-ஐ மகிழ்ச்சியாக அனுப்பும்.

ஒரு செயல்முறை எடுத்துக்காட்டு: pipeline உள்ள ஒரு booking ஆப்

உங்களிடம் ஒரு salon booking ஆப் உள்ளது; அதன் code ஒரு GitHub repository-இல் உள்ளது. AI builder-இடம் கேட்கிறீர்கள்: “முதல் முறை வாடிக்கையாளர்களுக்கு 10% தள்ளுபடி சேர்.”

1. மாற்றம் ஒரு புதிய branch-க்கு push செய்யப்படுகிறது, ஒரு pull request திறக்கப்படுகிறது.
2. Pipeline தொடங்குகிறது. Packages நிறுவி app-ஐ build செய்கிறது — இது தேறுகிறது.
3. அது சோதனைகளை இயக்குகிறது. ஒன்று, “திரும்பி வரும் வாடிக்கையாளர் முழு விலை செலுத்துகிறார்”, தோல்வியடைகிறது: தள்ளுபடி எல்லோருக்கும் பொருந்துகிறது.
4. Pull request-இல் சிவப்புக் குறி தோன்றுகிறது. மாற்றத்தை இணைக்க முடியாது.
5. AI-இடம் சரிசெய்யச் சொல்கிறீர்கள். அது ஒரு திருத்தத்தைத் தள்ளுகிறது; pipeline மீண்டும் இயங்குகிறது, எல்லாம் தேறுகிறது.
6. மாற்றம் இணைக்கப்படுகிறது. Pipeline அதை ஒரு staging சூழலுக்கு deploy செய்கிறது; அங்கே ஒரு சோதனை booking செய்து பார்க்கிறீர்கள்.
7. ஒப்புதல் அளிக்கிறீர்கள், அது production-க்கு deploy ஆகிறது.

Pipeline இல்லாவிட்டால், படி 3-இல் நடந்தது உங்கள் வாடிக்கையாளர்களின் பணப்பையில் நடந்திருக்கும்.

முக்கிய சொற்கள்

பொதுவான தவறான புரிதல்கள்

• “CI/CD என்றால் என் ஆப் சோதிக்கப்படுகிறது.” Pipeline உங்களிடம் உள்ள சோதனைகளை மட்டுமே இயக்கும். சோதனைகள் இல்லை என்றால், CI ஆப் build ஆகிறது என்பதை மட்டுமே நிரூபிக்கும் — அதற்கு மேல் இல்லை. முக்கியமான flows-க்கு சோதனைகள் எழுதும்படி AI-இடம் கேளுங்கள்.
• “CI/CD பெரிய நிறுவனங்களுக்கு மட்டும்.” GitHub Actions போன்ற hosted கருவிகளை அமைக்க ஒரு குறுகிய கட்டமைப்பு கோப்பு போதும்; சிறிய குழுக்கள் அவற்றை அடிக்கடி பயன்படுத்துகின்றன. முயற்சியைத் தேவைப்படுத்துவது கருவிகள் அல்ல, சோதனைகள்தான்.
• “தானியங்கி deployment என்றால் யாரும் எதையும் சரிபார்ப்பதில்லை.” நல்ல pipelines சரிபார்ப்புகளைக் குறைப்பதில்லை, சேர்க்கின்றன. பல குழுக்கள் production-க்கு முன் ஒரு மனித ஒப்புதல் படியை வைத்திருக்கின்றன.
• “Pipeline பச்சையாக இருந்தால் ஆப் வேலை செய்கிறது.” அதன் பொருள் தானியங்கி சோதனைகள் தேறின என்பது மட்டுமே. மாற்றத்தை நீங்களே முயற்சிக்க வேண்டும், முன்னுரிமையாக preview அல்லது staging-இல்.
• “CI/CD backups-ஐ மாற்றிவிடும்.” மாற்றாது. சோதனைகளைத் தேறிய ஒரு மோசமான database migration கூட உண்மையான தரவை சேதப்படுத்தலாம். Backups-உம் திரும்பும் வழியும் வைத்திருங்கள்.

உங்கள் AI builder-இடம் கேட்க வேண்டியவை

• “Sign-up, login, checkout ஆகியவற்றுக்கு தானியங்கி சோதனைகள் எழுது; அவற்றை எப்படி இயக்குவது என்று காட்டு.”
• “ஒவ்வொரு pull request-இலும் packages நிறுவி, app-ஐ build செய்து, சோதனைகளை இயக்கும் GitHub Actions workflow அமை.”
• “Pipeline-இல் type check மற்றும் linter சேர்; பிழைகள் இருந்தால் தோல்வியடையுமாறு செய்.”
• “Pipeline-இன் ஒவ்வொரு படியும் என்ன செய்கிறது என்று எளிய தமிழில் விளக்கு.”
• “Deploy பாதியில் தோல்வியடைந்தால் என்ன நடக்கும்? எப்படி rollback செய்வது?”
• “Repository-இலோ pipeline logs-இலோ எந்த secrets-உம் நேரடியாக எழுதப்படவில்லை என்று சரிபார்.”

உங்கள் ஆப் API keys பயன்படுத்தினால், pipeline-க்கும் அவை தேவை — CI கருவியில் குறியாக்கம் செய்யப்பட்ட secrets-ஆக, கட்டமைப்பு கோப்பில் ஒருபோதும் அல்ல. Environment variables மற்றும் secrets பார்க்கவும்.

CI/CD மற்றும் Mythex

Mythex உங்களுக்காக CI pipeline இயக்குவதில்லை, ஆனால் அதே தேவைகளில் சிலவற்றை அதன் சொந்த வழியில் நிறைவேற்றுகிறது:

• Checkpoints. ஒவ்வொரு வெற்றிகரமான agent turn-க்குப் பின், Mythex ஒரு git checkpoint சேமிக்கிறது; ஒரு மாற்றம் தவறானால் இந்தப் புள்ளிக்குத் திரும்பு மூலம் project-ஐ திரும்பக் கொண்டுவரலாம். Chat பார்க்கவும்.
• App Testing. /test என்று தட்டச்சு செய்தால், agent உங்கள் நேரலை preview-இல் ஒரு பயனரைப் போல கிளிக் செய்து உடைந்த flows-ஐ அறிவிக்கும் — ஒவ்வொரு வெளியீட்டுக்கும் முன் பயனுள்ளது. App Testing பார்க்கவும்.
• வெளியீடு ஒரு திட்டமிட்ட படி. மாற்றங்கள் முதலில் தனிப்பட்ட preview-இல் தோன்றும்; நீங்கள் மீண்டும் வெளியிடும் போதுதான் பொதுவான ஆப் புதுப்பிக்கப்படும் — continuous deployment-ஐ விட continuous delivery-க்கு அருகில்.
• GitHub sync (Pro). Project-ஐ GitHub repository-உடன் ஒத்திசைத்தால், ஒவ்வொரு push-இலும் சோதனைகளை இயக்க உங்கள் சொந்த GitHub Actions workflows-ஐ சேர்க்கலாம். GitHub மற்றும் export பார்க்கவும்.

நேரலைக்குப் போகும் முன் கையால் சோதிக்க வேண்டியவற்றின் பட்டியலுக்கு, வெளியீட்டுக்கு முன் உங்கள் ஆப்பை எப்படிச் சோதிப்பது பார்க்கவும்; பதிப்புக் கட்டுப்பாட்டுடன் வேலை செய்ய, AI-built ஆப்புடன் Git பயன்படுத்துவது எப்படி பார்க்கவும்.

கேள்விகள்