أمضيت هذا الأسبوع في نشر إصدار فعلي مباشرة عبر الطرق الثلاث بدلًا من مجرد وصفها، فإليكم السجل — ما نفّذته، وما تعطّل، وما كنت سأتخطاه لو أعدت الكرّة.
اليوم الأول، صباحًا — النطاق الفرعي بنقرة واحدة
بدأت بأسرع خيار: ضغطت نشر، وحصلت على yourname.buildmidas.com دون أي إعدادات DNS، ودون إنشاء حساب، ودون تكلفة. استغرق الأمر أربع ثوانٍ تقريبًا. هذه هي الخطوة المناسبة عندما تريد فقط معرفة ما إذا كان أحد سيهتم بالفكرة — شارك الرابط، وراقب ما يحدث، ثم كرّر التطوير. توقعت أن أصطدم بعائق بمجرد أن يحتاج التطبيق إلى متطلبات خادم حقيقية — حسابات، قاعدة بيانات، طبقة لعب جماعي عبر WebSocket — لكن لا، كل ذلك مُستضاف ومُدار أيضًا. لا شيء يحتاج إلى إعداد من جانبي. يوم أول جيد.
اليوم الأول، مساءً — محاولة كسر النشر عبر SFTP
هذا هو الجزء الذي كنت الأكثر قلقًا بشأنه. بمجرد أن يتجاوز المنتج مرحلة النطاق الفرعي ويحتاج إلى نطاقه الخاص، تنشره عبر SFTP مباشرة من صفحة الإصدار. وجّهته إلى خادم كان يحتوي بالفعل على مجلد ويب (webroot) بملفات قديمة، متوقعًا حدوث كتابة فوق البيانات. بدلًا من ذلك، فحص وكيل النشر الخادم، واختار استراتيجية، والأهم من ذلك — التقط نسخة من مجلد الويب الموجود قبل أن يلمس أي شيء. وكل إصدار يُنشر بعد ذلك يُحتفظ به أيضًا، والتراجع بنقرة واحدة. لذا عندما أطلقت عمدًا إصدارًا معطوبًا بعد عشرين دقيقة لاختبار الأمر، استغرق التراجع وقتًا مماثلًا تقريبًا للوقت الذي استغرقته ملاحظة أن الإصدار معطوب. كتبت المزيد عن أهمية ذلك في التكرار دون خوف — والخلاصة أن سجل الإصدارات يحوّل عمليات النشر من لحظة حبس أنفاس إلى حدث عادي.
ما كنت سأتخطاه في المرة القادمة: أمضيت عشرين دقيقة أحاول خداعه ببنية مجلدات فرعية متداخلة غريبة قبل أن أتذكر أن الفكرة كلها هي أنه خادمك، ونطاقك، وملفاتك — الأداة مجرد ناقل حذر، وليست حارس بوابة. جهد ضائع في اختبار شيء لم يكن يومًا موضع خطر.
اليوم الثاني — مسار المتجر، الذي لم أُنهه
لم أُكمل هذا المسار فعليًا، وهذه بصراحة الملاحظة الأكثر فائدة. الشحن عبر المتاجر — أندرويد إلى Google Play، والإضافات إلى Chrome Web Store وFirefox Add-ons — يمر عبر حساباتك الخاصة كمطوّر، مع إعداد الإدراجات وإقرارات الخصوصية بواسطة الوكلاء. هذا حقيقي، لكنه أيضًا عملية متعددة الأيام بحد ذاتها تخضع لطوابير مراجعة خارجة عن سيطرة أي أحد، لذا توقفت بعد خطوة إعداد الإدراج. إذا كنت تسعى للتوزيع عبر المتاجر، خصّص وقتًا منفصلًا لذلك؛ كتبت المسار الكامل في من الطلب إلى متجر التطبيقات.
ما الذي حدد المسار المختار، في تلك اللحظة
بحلول اليوم الثاني، كان الاختيار يفرض نفسه تقريبًا:
| ما كنت أفعله | المسار الذي لجأت إليه |
|---|---|
| اختبار ما إذا كانت الفكرة تنبض بالحياة | نطاق فرعي، في نفس اليوم |
| احتجت نطاقًا حقيقيًا للعلامة التجارية | نطاق فرعي أولًا، ثم SFTP إلى خادمي الخاص |
| أداة يجب أن يجدها المستخدمون في متجر | صفحة هبوط على نطاق فرعي + شحن عبر المتجر للتطبيق |
| مشروع عميل على بنيته التحتية الخاصة | SFTP إلى خادمه، مع سجل إصدارات |
نهاية الأسبوع
بحلول الجمعة، كان لديّ موقع تسويقي على نطاقي الخاص، والمنتج نفسه منشورًا على نطاق فرعي، وإدراج متجر مُعدّ نصفيًا — الطرق الثلاثة تعمل جميعًا في وقت واحد لنفس المشروع، مبنية ومطوّرة من نفس المحادثة طوال الوقت. يبدو أن هذه هي الحالة النهائية الطبيعية لأي مشروع جاد، وليست حالة استثنائية. أتمنى لو بدأت بتوقّع ذلك منذ اليوم الأول بدلًا من معاملة الطرق الثلاثة كقرارات منفصلة.



