‏AWS Transform custom: ریفکتور انبوه از داخل چت

بلاگ دواپس AWS با یه درد آشنا شروع می‌کنه: کارهای تبدیل کد که هیچ ابزار آماده‌ای براشون نوشته نشده. کوچ دادن سرویس‌ها از یه کتابخونهٔ داخلی، اعمال کنوانسیون error handling تیم، یکسان‌سازی لاگینگ بین ده‌ها سرویس — این‌ها تو بک‌لاگ تلنبار می‌شن چون ابزارهای عمومی با کدبیس شما نوشته نشدن. AWS Transform custom دقیقاً سراغ همین‌ها می‌ره: یه سرویس ایجنتی که تبدیل‌های دلخواهت رو به زبان طبیعی توصیف می‌کنی و روی کدبیس اجراشون می‌کنه.

واحد کار «تعریف تبدیل» یا TD ـه؛ یه دستور غذای قابل استفادهٔ مجدد که می‌گه تبدیل چطور باید انجام بشه، و تو نسخهٔ custom به زبان طبیعی نوشته می‌شه. مثال‌هایی که خود AWS می‌زنه: «کدبیس رو از C++11 ببر به C++17» یا «فراخوانی‌های auth-sdk-v1 منسوخ رو با auth-sdk-v2 عوض کن، ولی تنظیمات retry دست‌نخورده بمونه». کنارش یه کاتالوگ آماده هم هست: ارتقای نسخهٔ جاوا، boto2 به boto3، مهاجرت SDKهای AWS و کوچ از x86 به Graviton.

سه سطح برای کار باهاش وجود داره که هر سه به یه سرویس وصلن و TDها رو با هم شریک می‌شن: پاور AWS Transform داخل Kiro IDE، اسکیل ایجنت که روی استاندارد باز Agent Skills سواره و رو بیشتر از ۴۰ ایجنت سازگار کار می‌کنه (از Kiro CLI و Claude Code تا Cursor، GitHub Copilot، Gemini CLI و Windsurf)، و پلاگین IDE برای VS Code و Open VSX که به‌جای چت، رابط گرافیکی می‌ده.

قبلاً ساختن TD یعنی رفتن سراغ ترمینال و یه جلسهٔ تعاملی با CLI (همون دستور atx). حالا همون کار تو چت انجام می‌شه: به ایجنت می‌گی چی می‌خوای، اون چند سؤال روشن‌کننده دربارهٔ دامنه و رفتار تبدیل می‌پرسه، TD رو درفت می‌کنه، فرصت بازبینی و اصلاح می‌ده و آخرش تو اکانت AWS خودت منتشرش می‌کنه. بعد از انتشار، TD بلافاصله برای هر سه مسیر در دسترسه.

اجرا شش قدمه: ایجنت اول ریپوها رو بررسی می‌کنه و فایل‌هایی مثل pom.xml، package.json، requirements.txt و Dockerfile رو می‌خونه؛ بعد اون‌ها رو با TDهای منتشرشده‌ات تطبیق می‌ده و گزارش می‌ده کدوم تبدیل به کدوم ریپو می‌خوره؛ ورودی‌های لازم مثل نسخهٔ هدف رو می‌پرسه؛ منتظر تأیید نقشه می‌مونه (بدون تأیید، هیچی اجرا نمی‌شه)؛ بعد اجرا می‌کنه، پیشرفت رو استریم می‌کنه و آرتیفکت‌ها — پلن، ورک‌لاگ و خلاصهٔ اعتبارسنجی — رو تو ادیتور باز می‌کنه. خروجی هم کامیت‌های معمولی گیته که می‌شه ریویوشون کرد.

محلی حداکثر سه ریپو رو می‌شه هم‌زمان تبدیل کرد که برای کار موردی بسه ولی به درد یه کمپین مدرن‌سازی واقعی نمی‌خوره. حالت remote روی AWS Batch و Fargate اجرا می‌شه و صدها ریپو رو موازی جلو می‌بره؛ نکتهٔ جالبش اینه که خود ایجنت زیرساختش رو می‌سازه — محیط محاسباتی Batch، صف جاب، تعریف جاب، نقش‌های IAM و شبکه — بدون اینکه CloudFormation دستی بنویسی یا بری تو کنسول. ورودی‌ها هم می‌تونن مسیر محلی، آدرس گیت یا S3 باشن.

برای شروع باید AWS CLI نصب و کانفیگ‌شده باشه و اعتبارنامه‌ای با پالیسی AWSTransformCustomFullAccess (یا حداقل دسترسی‌های transform-custom) داشته باشی؛ ویندوز نیتیو پشتیبانی نمی‌شه و باید از WSL استفاده کنی. آخر کار هم ایجنت می‌پرسه منابع حالت remote رو نگه داره یا پاک کنه. جمع‌بندی AWS اینه که ارزش این سرویس تو تبدیل‌هاییه که فقط خودت می‌تونی بنویسی؛ همون‌هایی که کتابخونه‌ها، کنوانسیون‌ها و استانداردهای سازمان خودت رو کدگذاری می‌کنن.

نکات کلیدی:

• AWS Transform custom تبدیل‌های سفارشی کد رو با توصیف زبان طبیعی می‌سازه و اجرا می‌کنه
• تعریف تبدیل (TD) از تو چت ساخته، بازبینی و تو اکانت AWS منتشر می‌شه
• سه مسیر: پاور Kiro، اسکیل ایجنت سازگار با بیشتر از ۴۰ ایجنت، و پلاگین VS Code و Open VSX
• محلی تا ۳ ریپوی موازی؛ حالت remote روی Batch و Fargate تا صدها ریپو، با زیرساخت خودکار
• هیچ تغییری بدون تأیید اجرا نمی‌شه و خروجی نهایی، کامیت‌های معمولی گیته