உங்கள் GitHub Actions CI ஏன் மெதுவாக உள்ளது (மற்றும் அதை எவ்வாறு வேகப்படுத்துவது)

யாரும் கவனிக்காத பிரச்சனை

ஒரு workflow தோற்கும்போது GitHub உங்களுக்கு மின்னஞ்சல் அனுப்பும். ஆனால் உங்கள் CI எடுத்துக்கொள்ள வேண்டிய நேரத்தை விட இருமடங்கு நேரம் எடுக்கும் போது? உங்களுக்கு அமைதியே பதிலாகும். ஒவ்வொரு pull request மற்றும் ஒவ்வொரு commit-இலும் இயங்கும் ஒரு மெதுவான build, ஒரே வகையான dependencies-ஐ மீண்டும் மீண்டும் கம்பைல் செய்வது—கண்ணெதிரே மறையும் வீணடிப்பாகும்.

ஜூன் 30, 2026 நிலவரப்படி, CI செயல்திறன் எப்போதையும் விட மிக முக்கியமானது. மென்பொருள் உருவாக்கக் குழுக்கள் பெரியதாகிவிட்டன, deployments வேகமாக நடக்கின்றன, மற்றும் மெதுவான பின்னூட்ட சுழற்சிகளின் (feedback loops) செலவு முழு குழுவையும் பாதிக்கிறது. உங்கள் CI 5 நிமிடங்களுக்குப் பதிலாக 15 நிமிடங்கள் எடுத்துக் கொண்டால், உங்கள் குழு வாரத்திற்கு 40 PR-களைத் திறந்தால், நீங்கள் எந்திரங்களுக்காகக் காத்திருப்பதில் வாரத்திற்கு 8 மணிநேரத்தை கூட்டாக வீணடிக்கிறீர்கள். அது ஒரு முழு நபரின் சும்மா இருக்கும் நேரத்திற்குச் சமம். இருந்தபோதிலும், பெரும்பாலான குழுக்கள் இந்த பிரச்சனை குறித்து எச்சரிக்கும் ஒரு dashboard-ஐப் பார்ப்பதே இல்லை.

இது ஏன் நடக்கிறது

GitHub Actions-ஐ அமைப்பது மிகவும் எளிது, இதுவே அவை எங்கும் பரவுவதற்கான ஒரு காரணமாகும். ஆனால் அந்த எளிமையின் காரணமாக இயல்பான அமைப்புகள் (sensible defaults) பல நேரங்களில் செயல்திறன் வீழ்ச்சிகளை மறைத்துவிடுகின்றன. நீங்கள் ஒரு workflow-ஐ உருவாக்குவீர்கள், அது வேலை செய்யும், மேலும் ஏதேனும் பெரியளவில் முறியும் வரை அதைப் பற்றி யோசிப்பதை நிறுத்திவிடுவீர்கள். இதற்கிடையில், அந்த workflow தேவையற்ற வேலைகளைச் செய்துகொண்டிருக்கலாம்: ஒவ்வொரு இயக்கத்திலும் packages-ஐ மீண்டும் நிறுவுவது, மிகப்பெரிய cache artifacts-ஐ பதிவேற்றுவது, workflow matrix-ல் உள்ள எழுத்துப் பிழை காரணமாக சோதனைகளை இருமுறை இயக்குவது, அல்லது பூட் ஆக நீண்ட நேரம் எடுக்கும் பழைய images-ஐப் பயன்படுத்துவது.

வழக்கமான காரணிகளைக் கண்டறிந்து சரிசெய்வது எளிதானது. அவற்றை ஒவ்வொன்றாகப் பார்ப்போம்.

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

ஒவ்வொரு முறையும் dependencies-ஐ மீண்டும் உருவாக்குதல்

உங்கள் dependencies-ஐ cache செய்யாமல் விடுவதே மிகவும் எளிதாகச் செய்யப்படும் தவறுகளில் ஒன்றாகும். உங்கள் workflow ஒவ்வொரு இயக்கத்திலும் ஒரே npm packages, Go modules, அல்லது Python libraries ஆகியவற்றை நிறுவினால், அதே கோப்புகளுக்காக ஒரு நாளில் பலமுறை இணையக் கட்டணம், பிரித்தெடுத்தல் (unpacking) மற்றும் சரிபார்த்தல் ஆகியவற்றின் கிரயத்தைச் செலுத்துகிறீர்கள்.

பெரும்பாலான மொழிகளில் உள்ளமைக்கப்பட்ட caching உத்தி உள்ளது. Node.js-க்கு, GitHub Actions ஒரு cache action-ஐ வழங்குகிறது, அது சேமிப்பது node_modules அல்லது இயக்கங்களுக்கு இடையே உங்கள் lock file. Python-க்கு, நீங்கள் pip wheels-ஐ cache செய்யலாம். Java-வில் Maven மற்றும் Gradle caches உள்ளன. நீங்கள் அவற்றைப் பயன்படுத்தாவிட்டால், உங்கள் CI தேவையற்ற வேலையைச் செய்கிறது.

மெதுவான அல்லது பெரிய அளவிலான (bloated) images

GitHub Actions workflow-கள் containers-ல் இயங்குகின்றன. நீங்கள் தேர்ந்தெடுக்கும் image, ஒவ்வொரு இயக்கமும் பூட் ஆக எவ்வளவு நேரம் எடுக்கும் என்பதற்கான அடிப்படையை நிர்ணயிக்கிறது. பழைய அல்லது மிகப்பெரிய base image-ஐப் பயன்படுத்துவது (உங்களுக்குத் தேவையில்லாத build tools கொண்ட முழு Ubuntu போல) ஒவ்வொரு இயக்கத்திலும் பல நிமிடங்களை வீணாக்கும்.

முடியும் போது குறைந்தபட்ச (minimal) images-க்கு மாறுங்கள். உங்களுக்கு குறிப்பிட்ட கருவிகள் தேவைப்பட்டால், ஒருமுறை தனிப்பயன் Docker image-ஐ உருவாக்கி, அதை GitHub Container Registry போன்ற ஒரு registry-க்கு push செய்து, மீண்டும் பயன்படுத்துங்கள். முதல் இயக்கம் image-ஐ உருவாக்க அதிக நேரம் எடுக்கும், ஆனால் அடுத்தடுத்த இயக்கங்கள் அதை உடனடியாக pull செய்யும்.

தவறுதலாக jobs-ஐ இருமுறை இயக்குதல்

Workflow matrices மிகவும் சக்திவாய்ந்தவை, ஆனால் அவற்றை தவறாக அமைப்பது எளிது. பல்வேறு Node பதிப்புகள் அல்லது இயங்குதளங்களுக்கு matrix-ஐ அமைத்துவிட்டு, பின்னர் உண்மையில் ஒருமுறை மட்டுமே இயக்க விரும்பியதை உணர்வது ஒரு பொதுவானத் தவறாகும். ஒவ்வொரு போலி இயக்கமும் CPU, சேமிப்பகம் மற்றும் நேரத்தை வீணடிக்கிறது.

உங்கள் workflow YAML-ஐ மதிப்பாய்வு செய்யுங்கள். தேவையற்ற வேலையை இருமுறை செய்யும் ஒரு matrix-ஐ நீங்கள் கண்டால், அதைச் சீரமைக்கவும் (flatten) அல்லது குறிப்பிட்ட கிளைகளில் (branches) மட்டும் இயங்குவதற்கான நிபந்தனையைச் சேர்க்கவும்.

பெரிய அல்லது தேவையற்ற artifacts

ஒவ்வொரு இயக்கத்திற்கும் பிறகு உங்கள் workflow பெரிய build artifacts அல்லது logs-ஐ பதிவேற்றினால், GitHub அவற்றைச் சேமிக்கவும் சுருக்கவும் (compress) நேரத்தைச் செலவிடும். அந்த artifacts-ஐ நீங்கள் உண்மையில் பின்வரும் செயல்பாடுகளுக்குப் பயன்படுத்தாவிட்டால், அவை முற்றிலும் வீணே.

நீங்கள் எதைப் பதிவேற்றுகிறீர்கள் என்பதில் தெளிவாக இருங்கள். உங்களுக்கு முழு build directory தேவையா, அல்லது இறுதி binary மட்டுமா? வெற்றிகரமான இயக்கங்களின் logs தேவையா, அல்லது தோல்வியின் போது மட்டுமா? பழைய artifacts குவியாமல் இருக்க retention policy-ஐ அமைக்கவும்.

இணையாக (parallel) இயங்கக்கூடிய தொடர்ச்சியான (serial) படிகள்

உங்கள் workflow lint, பிறகு tests, பிறகு build என அனைத்தையும் வரிசையாக இயக்கினால், நீங்கள் குறிப்பிட்ட நேரம் வரை ஒரே ஒரு CPU core-ஐ மட்டுமே பயன்படுத்துகிறீர்கள். GitHub Actions இயல்பாகவே பல jobs-ஐ இணையாக (in parallel) இயக்கும் திறன் கொண்டது. சுயாதீனமான படிகள் உங்களிடம் இருந்தால், அவற்றை தனித்தனி jobs-ஆகப் பிரிக்கவும்.

ஒரு எளிய உதாரணம்: linting வேகமானது மற்றும் முழு build தேவையில்லை. அதை அதன் சொந்த job-ஆக இயக்கவும். அது தோற்றால், tests-க்காகக் காத்திருக்காமல் உடனடியாக உங்களுக்குத் தெரியவரும். அது தேர்ச்சி பெற்றால், tests மற்றும் build ஒரே நேரத்தில் இயங்கும்.

மெதுவான வேகத்தை எவ்வாறு அளவிடுவது

நீங்கள் மேம்படுத்துவதற்கு (optimize) முன், உங்களுக்கு ஒரு அடிப்படை நிலை (baseline) தேவை. GitHub Actions தாவலில் workflow timeline-ஐ வழங்குகிறது. சமீபத்திய இயக்கத்தைத் திறந்து, ஒவ்வொரு job மற்றும் step-இன் கால அளவையும் பாருங்கள். இருக்க வேண்டியதை விட மிக மெதுவாக இருக்கும் குறைந்தது ஒரு படிநிலையையாவது நீங்கள் எப்போதும் கண்டறிவீர்கள்.

எண்களைக் குறித்துக் கொள்ளுங்கள். மாற்றங்களைச் செய்த பிறகு, மீண்டும் வந்து ஒப்பிட்டுப் பாருங்கள். "CI 12 நிமிடங்களில் இருந்து 5 நிமிடங்களாகக் குறைந்தது" என்பதைப் பார்ப்பது திருப்தி அளிப்பதுடன், தீர்வு வேலை செய்தது என்பதை நிரூபிக்கிறது.

படிப் படியான மேம்பாட்டுச் சரிபார்ப்புப் பட்டியல் (optimization checklist)

படி 1: Dependency caching-ஐச் செயல்படுத்துங்கள்

உங்கள் மொழிக்கான caching படிநிலையைச் சேர்க்கவும். Node.js-க்கு, இதை உங்கள் workflow-இல் சேர்க்கவும்:

- uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'

அந்த cache: 'npm' வரி, GitHub-க்கு உங்கள் node_modules -ஐ இயக்கங்களுக்கு இடையே தானாகவே சேமித்து மீட்குமாறு கூறுகிறது. பிற மொழிகளிலும் இதுபோன்ற விருப்பங்கள் உள்ளன—உங்களுக்கான அதிகாரப்பூர்வ action-ஐச் சரிபார்க்கவும்.

படி 2: உங்கள் base image-ஐ தணிக்கை செய்யுங்கள்

உங்கள் workflow runs-on: ubuntu-latest-ஐப் பயன்படுத்தினால், அந்த image-இல் என்ன சேர்க்கப்பட்டுள்ளது என்பதைச் சரிபார்க்கவும். உங்களுக்கு Node.js மட்டுமே தேவைப்பட்டால், அதிகாரப்பூர்வ Node image-க்கு (docker://node:20) அல்லது GitHub-இன் இலகுரக பதிப்பிற்கு மாறுவதைக் பரிசீலிக்கவும். உங்களுக்குத் தனிப்பயனாக்கப்பட்ட அமைப்பு தேவைப்பட்டால், ஒருமுறை குறைந்தபட்ச image-ஐ உருவாக்கி push செய்யுங்கள்.

படி 3: மெதுவான jobs-ஐ இணையான jobs-ஆகப் பிரிக்கவும்

உங்கள் workflow YAML-ஐ மதிப்பாய்வு செய்யுங்கள். ஒன்றையொன்று சாராத தொடர்ச்சியான jobs இருந்தால், அவற்றைப் பிரிக்கவும். உதாரணத்திற்கு:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run test

இப்போது lint மற்றும் test ஆகியவை lint-பிறகு-test என்பதற்குப் பதிலாக ஒரே நேரத்தில் இயங்கும்.

படி 4: தேவையற்ற artifacts-ஐ அகற்றுங்கள்

உங்கள் workflow-இல் actions/upload-artifact-ஐச் சரிபார்க்கவும். அந்த artifact மற்றொரு job-ஆல் பயன்படுத்தப்படாவிட்டால் அல்லது கைமுறையாக பதிவிறக்கப்படாவிட்டால், அதை அகற்றிவிடவும். பிழைத்திருத்தத்திற்காக (debugging) artifacts-ஐ வைத்தால், குறுகிய retention time-ஐ அமைக்கவும்:

- uses: actions/upload-artifact@v4
  if: failure()
  with:
    name: logs-on-failure
    retention-days: 7

இது தோல்வியின் போது மட்டுமே logs-ஐ பதிவேற்றும் மற்றும் ஒரு வாரத்திற்குப் பிறகு அவற்றை நீக்கிவிடும்.

படி 5: Matrix நகல் உருவாக்கத்தைச் சரிபார்க்கவும்

உங்கள் workflow-இல் matrix: -ஐத் தேடி ஒவ்வொன்றையும் மதிப்பாய்வு செய்யவும். Matrix நீங்கள் விரும்பும் நடத்தையை உண்மையில் மாற்றவில்லை என்றால், அதை அகற்றிவிடவும். ஒவ்வொரு build-ஐயும் இருமுறை இயக்கும் matrix ஒரு கூடுதல் சுமையாகும்.

படி 6: படிநிலைகளின் வரிசையை மதிப்பாய்வு செய்யவும்

ஒரு job-க்குள், ஒவ்வொரு படியும் தொடர்ச்சியாக இயங்குகிறது. வரிசை முறை சரியாக உள்ளதா என்பதை உறுதிப்படுத்தவும். ஒரு படி மெதுவாக இருந்து, அதன் முடிவு மிகத் தாமதமாகவே தேவைப்பட்டால், அது பயன்படுத்தப்படும் இடத்திற்கு அருகில் அதை நகர்த்துவது குறித்து பரிசீலிக்கவும். ஒரு படி வேகமாகவும் சுயாதீனமாகவும் இருந்தால், அது முன்னதாகவே தோல்வியடையும் பொருட்டு அதை முன்னால் நகர்த்தவும்.

காலப்போக்கில் கண்காணித்தல்

நீங்கள் மேம்படுத்திய பிறகு, அதை மறந்துவிடாதீர்கள். CI workflow-கள் மாறக்கூடும்—dependencies பெரியதாகின்றன, புதிய படிகள் சேர்க்கப்படுகின்றன, images மாறுகின்றன. உங்கள் மிக மெதுவான workflow-ஐ அவ்வப்போது சரிபார்க்க மாதந்தோறும் ஒரு நினைவூட்டலை அமைக்கவும். அது மேலும் மெதுவாகிக்கொண்டே இருந்தால், பிரச்சனை பெரிதாக உருவெடுப்பதற்கு முன் அதை ஆராயுங்கள்.

சில குழுக்கள் GitHub Actions அளவீடுகளை (metrics) ஒரு கண்காணிப்பு dashboard-க்கு ஏற்றுமதி செய்கின்றன. இது மேம்பட்ட தொழில்நுட்பம், ஆனால் உங்களிடம் பல workflow-கள் இருந்தால், மாறுதல்களைத் தானாகவே கண்டறிவதன் மூலம் இது பலனளிக்கும்.

முடிவுரை

மெதுவான CI என்பது உங்கள் குழுவின் வேகத்தின் மீதான ஒரு வரியாகும், அது பில்லில் ஒருபோதும் தோன்றாது. இது வாரத்திற்கு நூற்றுக்கணக்கான இயக்கங்களில் அமைதியாகப் பெருகுகிறது. தீர்வுகள் கடினமானவை அல்ல—caching, parallel jobs, வீணடிப்பை அகற்றுதல்—ஆனால் அதற்கு முதலில் சிக்கலைக் காண வேண்டும். இந்த வாரம் ஒரு மணிநேரம் உங்கள் workflow-களை மதிப்பாய்வு செய்யச் செலவிடுங்கள். ஒவ்வொரு இயக்கத்திலும் 5-10 நிமிடங்கள் வீணான நேரத்தை நீங்கள் கண்டறிய வாய்ப்புள்ளது. அது உங்கள் எதிர்காலத்திற்கு நீங்களே அளிக்கும் ஒரு பரிசாகும்.

நன்மைகள்

• வேகமான பின்னூட்ட சுழற்சிகள் (feedback loops) மென்பொருள் உருவாக்குநர்களைத் தடைகளின்றித் தொடர்ந்து பணியாற்ற வைக்கின்றன.
• இயக்கங்கள் வேகமாக நிறைவடைவதால், மேகக்கணி கணக்கீட்டு (cloud compute) செலவுகள் குறைகின்றன.
• பிரச்சனைகளை முன்னதாகவே கண்டறிதல் (எ.கா., பிரிக்கப்பட்ட jobs முன்னதாகவே தோற்கின்றன).
• சிறந்த developer அனுபவம்; 15 நிமிடங்களுக்குப் பதிலாக 3 நிமிடங்கள் காத்திருப்பதை மக்கள் அதிகம் விரும்புவார்கள்.
• சிறிய மாற்றங்கள் வாரத்திற்குப் பல டஜன் இயக்கங்களில் சேர்ந்து கணிசமான நேர சேமிப்பாக மாறுகின்றன.
• அளவிடுவது எளிது; dashboard தரவு ஏற்கனவே GitHub-இல் கிடைக்கிறது.

குறைபாடுகள்

• தணிக்கை மற்றும் பராமரிப்பு தேவைப்படுகிறது; மதிப்பாய்வு இல்லாமல் workflow-கள் மேம்படுத்தப்பட்ட நிலையிலேயே இருப்பதில்லை.
• அதிகப்படியான caching, production வரை dependency பிழைகளை மறைக்கக்கூடும்.
• Jobs-ஐ அதிகளவில் பிரிப்பது சிக்கலை உருவாக்குகிறது; அதிக jobs என்றால் பிழைதிருத்தம் (debug) செய்ய வேண்டிய விஷயங்களும் அதிகம்.
• குறைந்தபட்ச images-இல் சில சமயங்களில் உங்களுக்குப் பின்னர் தேவைப்படும் கருவிகள் இருக்காது, இதனால் மீண்டும் வேலை செய்ய வேண்டியிருக்கும்.
• Artifact cleanup கொள்கைகளால் பிழைதிருத்தத்திற்குத் தேவையான logs-ஐ இழக்கும் அபாயம் உள்ளது.
• உங்களிடம் போதுமான concurrency quota இருந்தால் மட்டுமே இணையாக்கம் (parallelization) உதவும்; GitHub-இன் இலவச திட்டம் வரம்பிற்குட்பட்டது.

எச்சரிக்கை

இந்தக் கட்டுரையில் உள்ள அனைத்து பெயர்கள், கட்டமைப்பு மதிப்புகள் (configuration values), மற்றும் placeholders (எ.கா., node:20, ubuntu-latest, app.example.com) உதாரண நோக்கங்களுக்காக மட்டுமே. ஏதேனும் workflow-ஐ production-இல் அமைப்பதற்கு முன், அதை ஒரு staging branch-இல் முழுமையாகச் சோதிக்கவும். உங்கள் குறிப்பிட்ட அமைப்பு, மொழிப் பதிப்புகள் மற்றும் உள்கட்டமைப்பு ஆகியவை மாறுபடலாம். ஒரு திட்டத்திற்கு நன்றாக வேலை செய்யும் Caching உத்திகள் மற்றொன்றுக்கு ஏற்றதாக இல்லாமல் இருக்கலாம். உங்கள் உண்மையான சூழலில் செயல்திறன் மேம்பாடுகளை எப்போதும் சரிபார்த்து, பக்க விளைவுகளைக் கண்காணிக்கவும் (எ.கா., பழைய cache காரணமாகப் பயன்பாட்டில் இல்லாத dependencies ஏற்படுவது). உங்கள் சொந்த பொறுப்பில் தொடரவும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• GitHub Actions-இல் ஒரு களஞ்சியத்திற்கு (repository) அதிகபட்ச cache அளவு என்ன?
• என் workflow-இல் GitHub Actions caching உண்மையில் பயன்படுத்தப்படுகிறதா என்பதை நான் எவ்வாறு அறிவது?
• என் CI-ஐ வேகப்படுத்த நான் ஒரு தனிப்பயன் Docker image-ஐப் பயன்படுத்தலாமா?
• ஒரு cache-ஐ உருவாக்கிய பிறகு எனது முதல் இயக்கம் ஏன் குறைவாக இல்லாமல் அதிக நேரம் எடுக்கிறது?
• Concurrency quota பயன்பாட்டை அதிகரிக்காமல் GitHub Actions-இல் jobs-ஐ எவ்வாறு இணையாக்குவது?
• node_modules-ஐ cache செய்வது நல்லதா அல்லது lock file-ஐ மட்டும் cache செய்வது நல்லதா?
• மெதுவான CI இயக்கங்கள் என் workflow-ஐ GitHub தானாகவே ரத்து செய்யக் காரணமாக அமையுமா?
• எனது GitHub Actions workflow-களை நான் எவ்வளவு அடிக்கடி மதிப்பாய்வு செய்து புதுப்பிக்க வேண்டும்?

டேக்குகள்

#github #actions #ci #cicd #devops #performance #optimization #workflows #automation #testing