உங்கள் ஏஜென்ட் Production-ஐச் செயலிழக்கச் செய்யவில்லை. உங்கள் பைப்லைன் தான் அதைச் செய்தது.

உங்கள் ஏஜென்ட் Production-ஐச் செயலிழக்கச் செய்யவில்லை. உங்கள் பைப்லைன் தான் அதைச் செய்தது.

பல குழுக்கள் pull requests-களைத் திறக்க ஏஜென்ட்களைப் பயன்படுத்துகின்றன. அவை linting, சோதனைகள் (tests) மற்றும் பில்ட்களை (builds) சரிபார்க்க CI-ஐப் பயன்படுத்துகின்றன. பின்னர், ஒரு திட்டமிடப்பட்ட பணி (scheduled job) குறியீட்டை (code) staging-லிருந்து production-க்கு மாற்றுகிறது. இந்த அமைப்பு இறுதியில் தோல்வியடைகிறது.

பிரச்சனை ஒரு தீய ஏஜென்ட் (malicious agent) அல்ல. பிரச்சனை ஒரு மோசமான செயல்முறை (bad process). நீங்கள் இரண்டு வெவ்வேறு கேள்விகளை ஒரே நுழைவாயிலுக்குள் (gate) சுருக்கிவிட்டீர்கள்:

• இது CI-ஐத் தேர்ச்சி பெற்றதா?
• இதை இப்போது ஒரு மனிதர் பார்ப்பதற்குப் பாதுகாப்பானதா?

இவை இரண்டும் ஒன்றல்ல. CI குறியீடு வேலை செய்கிறதா என்பதைச் சரிபார்க்கிறது. ஒரு அம்சம் (feature) வாடிக்கையாளர்களுக்குத் தயாராக உள்ளதா என்பதை அது சரிபார்க்காது.

உங்கள் பைப்லைன் "merged" மற்றும் "live" ஆகிய இரண்டையும் ஒன்றாகக் கருதினால், உங்களுக்கு ஒரு பிரச்சனை உள்ளது. நீங்கள் திட்டமிடாமலேயே தொடர்ச்சியான விநியோகத்திற்கு (continuous deployment) வழிவகுத்துவிட்டீர்கள்.

நீங்கள் இந்த இரண்டு நிகழ்வுகளையும் தனித்தனியாகப் பிரிக்க வேண்டும் (decouple).

இதைச் செய்ய நீங்கள் feature flags-களைப் பயன்படுத்தலாம். Feature flags என்பது வெறும் ஒரு boolean மற்றும் ஒரு if statement மட்டுமே. இதைத் தொடங்க உங்களுக்கு விலையுயர்ந்த கருவிகள் தேவையில்லை. ஒரு எளிய config மதிப்பு அல்லது environment variable போதுமானது.

எனது அமைப்பு இந்த விதிகளைப் பின்பற்றுகிறது:

• PR-கள் main-இல் இணைக்கப்படுகின்றன (merge), ஆனால் main எப்போதும் live-இல் இருக்காது.
• ஒரு தனித்த வெளியீட்டுப் படி (release step) main-ஐ ஒரு production branch-ஆக உயர்த்துகிறது.
• நான் வெளிப்படையாக "go" என்று சொல்ல வேண்டும். cron jobs அல்லது تایமர்கள் இருக்காது.
• வெளியீடு (release), பில்ட் டிராஃபிக்கை (traffic) கையாளும் வரை காத்திருக்கும்.
• தளம் வேலை செய்கிறதா என்பதை உறுதிப்படுத்த ஒரு தானியங்கிச் சரிபார்ப்பு (automated check) முக்கிய endpoints-களைச் சென்றடையும்.
• ஒரு மனிதர் மாற்றங்களின் மீது இறுதித் தார்மீகச் சரிபார்ப்பைச் (manual check) செய்வார்.

இது ஒரு நுழைவாயிலை (gate) உருவாக்குகிறது. ஒரு பயனர் எதையும் பார்ப்பதற்கு முன், ஒரு மனிதர், ஒரு இயந்திரம் மற்றும் மற்றொரு மனிதர் ஆகிய மூவருக்கும் "இல்லை" என்று சொல்ல ஒரு வாய்ப்பு கிடைக்கிறது.

ஒரு பிழை (bug) இன்னும் பயனரைச் சென்றடைந்தால், நீங்கள் விரைவாக அதைத் திரும்பப் பெற (revert) வேண்டும். இதைச் செய்ய, database migrations-களுக்கான expand and contract pattern முறையைப் பின்பற்றுங்கள்.

• ஒரு புதிய காலத்தை (column) nullable ஆகச் சேர்க்கவும்.
• தரவை நிரப்பவும் (backfill).
• பழைய மற்றும் புதிய காலங்கள் இரண்டிற்கும் எழுதவும்.
• புதிய ஒன்றிலிருந்து படிக்கவும்.
• ஒரு பிந்தைய வெளியீட்டில் (later release) மட்டுமே பழைய காலத்தை நீக்கவும் (drop).

இதைத் தவிர்த்தால், உங்கள் revert பொத்தான் பயனற்றதாகிவிடும். ஒரு migration பழைய குறியீட்டிற்குத் தேவையான ஒரு காலத்தை நீக்கிவிட்டால், உங்களால் பழைய நிலைக்குத் திரும்ப (roll back) முடியாது. நீங்கள் அப்படியே செயலிழந்து போவீர்கள்.

ஒரு ஏஜென்ட் இத்தகைய தவறுகளை விரைவாகச் செய்கிறது. உங்கள் மோசமான செயல்முறைகளை மறைத்து வைத்திருந்த கைமுறைத் தடைகளை (manual friction) அது நீக்கிவிடுகிறது. நீங்கள் தவிர்த்த ஒழுக்கம் (discipline) ஒருபோதும் விருப்பத்தேர்வு அல்ல. அது வெறும் வெள்ளிக்கிழமை மாலை 5:00 மணிக்கு முன் ஒரு மனிதர் ஒரு தவறைத் தற்செயலாகக் கண்டறிந்து சரிசெய்துகொண்டிருந்ததே தவிர.

மனிதனை இந்தச் சுழற்சியிலிருந்து (loop) நீக்கிவிட்டால், அந்த ஒழுக்கம் கட்டாயமாகிவிடும்.

மூலம்: https://dev.to/mattstratton/your-agent-didnt-break-prod-your-pipeline-did-4g9o