پرش به محتوا
۸ اوت ۲۰۲۶ · انتشار

سه راه برای زنده شدن

این مقاله محصول را در زمان انتشار توصیف می‌کند. برای قابلیت‌های فعلی به AI Builder و Agent Teams مراجعه کنید.

سه راه برای زنده شدن

این هفته را صرف واقعاً بردن یک ساخت به‌صورت زنده از هر سه مسیر کردم، به‌جای آنکه فقط آن‌ها را توصیف کنم، پس این هم گزارش کار — چه کاری انجام دادم، چه چیزی خراب شد، و اگر دوباره انجامش می‌دادم چه چیزی را رد می‌کردم.

روز اول، صبح — زیردامنه‌ی یک‌کلیکی

با سریع‌ترین گزینه شروع کردم: روی انتشار زدم و yourname.buildmidas.com را گرفتم، بدون DNS، بدون ساخت حساب، بدون هزینه. حدود چهار ثانیه طول کشید. این حرکت درستی است وقتی فقط می‌خواهید بدانید آیا کسی به این ایده اهمیت می‌دهد — لینک را به اشتراک بگذارید، ببینید چه اتفاقی می‌افتد، و تکرار کنید. تقریباً انتظار داشتم به دیواری بخورم به‌محض اینکه اپلیکیشن به چیزهای واقعیِ بک‌اند نیاز پیدا کند — حساب کاربری، پایگاه‌داده، یک لایه‌ی چندنفره‌ی WebSocket — اما نه، آن‌ها هم میزبانی و مدیریت می‌شوند. چیزی برای تنظیم از سمت من نبود. روز اول خوبی بود.

روز اول، بعدازظهر — تلاش برای خراب کردن استقرار SFTP

این بخشی بود که بیشترین نگرانی را درباره‌اش داشتم. وقتی محصولی از زیردامنه فراتر می‌رود و به دامنه‌ی خودش نیاز دارد، مستقیم از صفحه‌ی ساخت، از طریق SFTP استقرار می‌دهید. آن را به سروری اشاره دادم که از قبل یک وب‌روت با فایل‌های قدیمی داشت، تقریباً منتظر بودم چیزی رونویسی شود. در عوض، ایجنت استقرار سرور را بررسی کرد، استراتژی‌ای انتخاب کرد، و — این جزئیاتی است که اهمیت داشت — پیش از دست‌زدن به هرچیزی، وب‌روت پیشین را ضبط کرد. هر نسخه‌ای که بعد از آن مستقر شود هم نگه داشته می‌شود، و بازگردانی فقط یک کلیک است. پس وقتی بیست دقیقه بعد عمداً یک ساخت خراب را برای تست منتشر کردم، برگرداندنش تقریباً به همان اندازه‌ای طول کشید که فهمیدن اینکه ساخت خراب است. بیشتر درباره‌ی اهمیت این موضوع در تکرار بدون ترس نوشته‌ام — خلاصه‌اش این است که تاریخچه‌ی نسخه‌ها، استقرارها را از لحظه‌ای پر از نفس‌حبس‌شده به یک رویداد بی‌اهمیت تبدیل می‌کند.

کاری که دفعه‌ی بعد رد می‌کنم: بیست دقیقه صرف کردم تا با یک ساختار پوشه‌ی تودرتوی عجیب فریبش دهم، پیش از آنکه به یاد بیاورم کل نکته این است که این سرور شماست، دامنه‌ی شماست، فایل‌های شماست — این ابزار فقط یک جابه‌جاکننده‌ی دقیق است، نه یک دروازه‌بان. تلاشی هدررفته برای آزمایش چیزی که هرگز ریسک واقعی نبود.

روز دوم — مسیر فروشگاه، که تمامش نکردم

این یکی رو در واقع کامل نکردم، و راستش همین نکته مفیدتره. توزیع در استورها — اندروید به Google Play، اکستنشن‌ها به Chrome Web Store و Firefox Add-ons — از طریق حساب‌های توسعه‌دهنده‌ی خودتان انجام می‌شود، با لیستینگ‌ها و اعلامیه‌های حریم خصوصی که توسط ایجنت‌ها آماده می‌شوند. این واقعی است، اما یک فرایند چند روزه‌ی مستقل با صف‌های بررسی خارج از کنترل هرکسی هم هست، پس من بعد از مرحله‌ی آماده‌سازی لیستینگ متوقف شدم. اگر دنبال توزیع در استور هستید، برای آن جداگانه برنامه‌ریزی کنید؛ مسیر کامل را در From prompt to app store نوشته‌ام.

چه چیزی در آن لحظه مسیر را تعیین کرد

تا روز دوم، انتخاب تقریباً خودش مشخص شد:

کاری که در حال انجامش بودممسیری که انتخاب کردم
بررسی اینکه آیدیا اصلاً نبض داشت یا نهزیردامنه، همان روز
نیاز به یک دامنه‌ی برند واقعیابتدا زیردامنه، سپس SFTP به سرور خودم
ابزاری که مردم باید در یک استور پیدایش کنندصفحه‌ی فرود زیردامنه + ارسال به استور برای اپ
پروژه‌ی مشتری روی زیرساخت خودشSFTP به سرور مشتری، نسخه‌بندی‌شده

پایان هفته

تا جمعه یک سایت تبلیغاتی روی دامنه‌ی خودم داشتم، خود محصول روی یک زیردامنه فعال بود، و یک لیستینگ استور نیمه‌آماده — هر سه مسیر همزمان برای یک پروژه در حال اجرا، و در تمام مدت از همان چت ساخته و تکرار می‌شدند. ظاهراً این حالت پایانی معمول برای هر چیز جدی است، نه یک استثنا. کاش از روز اول همین را انتظار می‌کشیدم، به‌جای اینکه سه مسیر را تصمیم‌های جداگانه فرض کنم.

آن‌ها روی هم انباشته می‌شوند. یک مسیر را انتخاب نکنید و متوقف نشوید — شکل رایج برای یک محصول واقعی، یک دامنه، یک زیردامنه (یا سرور خودتان)، و یک لیستینگ استور است که همه با هم فعال‌اند.
در حال ارسال
اشتراک‌گذاریXLinkedInFacebookRedditQuoraواتساپتلگرامایمیل
← همه مطالب