۸ کار که باید هنگام اجرای پروژه Laravel LIVE انجام دهید

shape
shape
shape
shape
shape
shape
shape
shape

بعد از اینکه دو هزار پروژه با لاراول راه اندازی کردم ، تصمیم گرفتم یک لیست چک برای پرتاب ها ایجاد کنم. مشکل این است که اغلب اوقات چیزی فراموش یا فراموش می شود – از طرف تیم ما ، یا از طرف مشتری. بنابراین این لیست چک باید از آن جلوگیری کند و احتمالاً در راه اندازی های شما نیز به شما کمک می کند.

برای اجرای برنامه نویسی اختصاصی با گروه برنامه نویسی لاراولیا ارتباط برقرار نمایید و از مشاوره کارشناسان این مجموعه بهره مند شوید.

سلب مسئولیت 1: هر مرحله در اینجا برای هر پروژه موردنیاز نیست ، لطفاً موارد خاص را برای پروژه (های) خود انتخاب کنید.

سلب مسئولیت 2: برخی از این نکات می تواند برای سایر پروژه های وب ، نه تنها Laravel مفید باشد.

بنابراین ، در روز آغاز رسمی باید چه چیزی را مراقبت کنیم؟

1. تست دستی در محیط آزمایش / مرحله بندی
تست دستی

شما محیط آزمایش دارید ، درست است؟ برخی آنرا آزمایش می نامند ، برخی دیگر آن را مرحله بندی می نامند ، اما نکته این است – برخی سرور از راه دور برای آزمایش پروژه برای توسعه دهندگان و مشتری.

برای اینکه کار مرحله به مرحله کار راحت صورت بگیرد ، ممکن است از به اصطلاح “بذر دیتابیس” مراقبت کنید – داده های اصلی که به عنوان اولین پر کردن بانک اطلاعاتی برای راه اندازی پروژه ارائه می شود. با مشتری چه اطلاعاتی باید داشته باشید ، سعی کنید آن را تا آنجا که ممکن است به پایگاه داده زنده آینده نزدیک نگه دارید.

اکنون ، دو نکته مهم در اینجا وجود دارد – اول ، سرور مرحله بندی باید به اندازه سرور زنده شبیه باشد. همان سیستم عامل ، پیکربندی وب سرور و غیره. پس از انتقال به سرور زنده (که به آن “تولید” نیز می گویند) شانس اینکه اشتباهی رخ دهد را به حداقل می رسانید. اغلب یک اشتباه برای توسعه دهندگان است که بصورت محلی با سیستم عامل ویندوز و وب سرور Apache (یا چیزی شبیه به XAMPP) آزمایش کنند ، در حالی که سرورهای مرحله بندی / تولید مبتنی بر لینوکس با سرور Nginx هستند.

نکته مهم دیگر این است که مشتری باید به شدت در این آزمایش شرکت کند. در این مرحله شما باید نه تنها آزمایش فنی انجام دهید (a.k.a “اگر چیزی خراب نشود ، ما خنک هستیم”) بلکه منطق تجارت نیز ممکن است – چیزی ممکن است از دست رفته یا نادیده گرفته شود. بعد از این قسمت مشتری باید راه اندازی را امضا کند (به هر شکلی که توافق کردید) و سپس به صورت زنده ادامه دهید.

2. تست دستی بر روی سرور زنده
سرور تولید

این مرحله است که اغلب به اشتباه می رود – شما آن را به صورت محلی و سرور تست کرده اید ، اما وقتی بعضی از سایت های SomeFancyAddress.com را به صورت زنده حرکت می دهید و به صورت زنده می روید. و همیشه به کارایی مربوط نمی شود – ممکن است این یک تغییر مسیر دامنه باشد ، گواهی SSL (شما از SSL استفاده می کنید ، درست است؟ اکنون آسان و رایگان است) ، تنظیمات مختلف / نامعتبر یا پرونده های پیکربندی گمشده.

اکنون ، دو روش برای انجام این آزمایش “زنده” وجود دارد.

اگر پرتاب شما می تواند “ساکت” باشد – در واقع می توانید مستقیماً به زندگی خود ادامه دهید و به کسی نگویید. به مشتری بگویید که هیچ بازاریابی راه اندازی نکند ، هیچ پیام وبلاگ یا توییتی را بنویسد ، یک روز را صرف آزمایش همه این موارد کند.
یا می توانید دامنه را جعلی کرده و آدرس IP سرور را در پرونده میزبان خود اختصاص دهید ، بنابراین این امر به صورت زنده وجود دارد.
هنگام آزمایش زنده ، به هر یک از ادغام های شخص ثالث توجه ویژه ای کنید – مانند ارسال نامه الکترونیکی / پیام کوتاه ، فروشندگان پرداخت و غیره. اینها خطر زیادی برای کار نکردن با پیکربندی زنده دارند ، که متفاوت از بیان متغیرهای محیط است – معمولاً همه آن دسته 3 احزاب نوعی “ماسهبازی” دارند اما لطفاً اطمینان حاصل کنید که محیط زندگی شما نیز کار می کند.

توجه دیگر: اطمینان حاصل کنید که بازدید کنندگان با نسخه زنده آنچه را که باید نبینند ، نمی بینند: مانند خطاهای “Whoops” (ساخت همه الگوهای 404 و سایر صفحات خطا در Blade) ، Laravel Debugbar ، JavaScript console.log () و غیره به همین دلیل معمولاً متغیر APP_ENV به عنوان “تولید” در پرونده پیکربندی .env شما کافی است ، اما می تواند به پروژه بستگی داشته باشد.

3. روش استقرار سریع و شفاف
که چه

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

چه کسی به مخزن / سرور دسترسی دارد؟
روند کار با مخزن: انشعاب چیست؟ ادغام؟
روند ثبت کد متعهد چگونه است؟ پیام های تعهد کافی است؟
آیا دکمه Deploy Now وجود دارد ، یا این فقط “نصب git pull + آهنگساز نصب شده” است ، یا این یک میزبان مشترک با FTP است؟
اینجاست که متوقف می شوم و کمی غیرقابل توصیف خواهم بود.
برای پروژه موفق ، از محیط های میزبان مشترک برای پروژه های Laravel استفاده نکنید.
رفته اند زمانی که سرورهای اختصاصی هزینه ثروت دارند ، و همچنین مواردی مانند Digital Ocean / Linode / Amazon AWS وجود دارد که بیشترین درد را از نظر راه اندازی از بین می برد.

من در گذشته نوشتم که چگونه می توان با هاست مشترک و لاراول کار کرد ، و این امکان وجود دارد ، اما شما اساساً بیشترین مزایای چارچوب های مدرن PHP مانند Laravel را از دست می دهید – با دسترسی به SSH نمی توانید دستورات ترمینال مانند ” git pull “،” آهنگساز نصب “،” artisan مهاجرت “و غیره بنابراین شما باید هر زمان که بخواهید بصورت دستی انجام دهید – هم هنگام اجرای اولین بار پروژه و هم برای هر نسخه بعدی. و می دانید که این روند نه تنها درد در گردن ، بلکه فراموش کردن چیزی ، اتصال FTP ناپایدار و غیره نیز بسیار سخت است.

در تجربه ما ، ما قبلاً با استدلال آنها مبنی بر “ما یک میزبان میزبان داریم و نمی خواهیم به هر مکانی حرکت کنیم” ، مشتریانی را با میزبانی مشترک پذیرفتیم. اما بعد از آنکه مشتری ها روند کندی و جهنم استقرار را مشاهده کردند (که هزینه اضافی را نیز پرداخت کردند) ، Digital Ocean خیلی سریع معرفی شد. برد – برد.

همچنین توصیه می کنم زندگی خود را آسان تر کرده و از ابزارهایی مانند Laravel Forge و Envoyer برای استقرار و مدیریت سرور استفاده کنید. در کل ارزش آن را دارد ، به ویژه وقتی که مسئولیت چندین پروژه را بر عهده دارید – اساساً می توانید SSH و Terminal را فراموش کنید.

نکته دیگر – برای هر استقرار باید از خرابی صفر اطمینان داشته باشید (اینجاست که Envoyer در جای خود قرار می گیرد) ، یا یک صفحه مناسب “استقرار در حال انجام است” – موردی که در دستور “artisan down” نشان داده شده است. و بله ، هنگام استقرار ، اطمینان حاصل کنید که “artisan down” را اجرا می کنید. حتی ممکن است یک قدم جلوتر بروید و برخی از اعلان ها را به بازدید کنندگان خود معرفی کنید – مانند به زودی استقرار در چنین ساعتی اتفاق می افتد.

سرانجام ، چند نکته در مورد استقرار تصادفی:

برای زندگی در جمعه یا آخر روز اعزام نشوید
در هنگام استقرار ، اگر چیزی نادرست پیش آمد ، آماده شوید که حداقل یک ساعت وقت وظیفه داشته باشید (نه تنها برای تیم توسعه بلکه پشتیبانی مشتری).
4- خطا در روش و ابزار گزارش
اوه

چه اتفاقی می افتد وقتی کسی به برخی از اشکالات در وب سایت برخورد کند؟ این ممکن است شما یا مشتری شما نباشد ، ممکن است یک بازدید کننده تصادفی باشد. حتی ممکن است متوجه این اشکال نشوید. اما آنها و مشتری شما از این رنج رنج می برد.

البته ، شما می توانید و باید پرونده laravel.log را جمع آوری کنید که همه خطاها را جمع می کند. اما راحت نیست – پرونده (یا پرونده ها اگر آنها را براساس تاریخ تقسیم کنید) بزرگتر و بزرگتر می شود.

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

و قبل از اینکه بگویید پرداخت 29 دلار در ماه گران است ، وقتی می توانید نظارت خود را به صورت رایگان انجام دهید ، صبر کنید تا ده ها پروژه برای نظارت داشته باشید – اینجاست که قدرت چنین ابزارهایی زنده می شود.

5. تست های خودکار (برای پروژه های بزرگتر)
تست های خودکار

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

بنابراین آزمایشات خودکار (با PHPUnit یا سایر موارد) فقط در صورتی معنی دارند که ارزش آنها را بیابند. آزمایش فقط به خاطر نوشتن تست ها – در واقع اتلاف وقت است. شما فقط باید سناریوهایی بنویسید که سناریوهای مشخصی از آنچه تست می کنید نوشته شود ، نتایج / شکست ها و غیره چیست؟

به عبارت دیگر ، این به نوشتن تست ها مربوط نمی شود – این به معنای طراحی ساختار آنها به روشی مناسب است ، پس من طرفدار آزمون ها هستم. و معمولاً این اتفاق می افتد برای پروژه های بزرگتر با موارد و سناریوهای واقعاً دشوار. در جایی که به جای اعتماد به ماشین برای انجام آزمایش ، زمان بیشتری نیاز است.

نکته دیگر به اصطلاح “آزمایش دود” است – این همان چیزی است که من برای هر پروژه ای پیشنهاد می کنم. هدف در اینجا آزمایش ساده ترین چیزهاست – خواه صفحات در حال بارگیری با کد وضعیت 200 و بدون هیچ خطایی هستند. بنابراین ، کاری که ما اغلب انجام می دهیم ساخت مجموعه ای از چنین “آزمایش دود” با لیستی از URL ها ، تلاش برای مراجعه به آنها و بررسی نتیجه خوب است. اصولاً ، همان کارهایی که یک توسعه دهنده انجام می داد ، صرفاً بدون وقت انسانی صرف شده است.

6. Google Analytics ، SEO و متن
تجزیه و تحلیل ترافیک گوگل

این یکی لاراول خاص نیست اما اغلب کاملاً فراموش شده است. اطمینان حاصل کنید که پروژه را با کد Analytics (یا اگر کد تحلیلی دیگری مانند Piwik دارید) در نسخه زنده وب سایت راه اندازی کنید. اما آزمایش نیست. در غیر این صورت مشتری شما آمارهای ضروری را از دست می دهد ، زیرا معمولاً لحظه شروع اولین داوری در مورد نتایج است – و فقط درصورتی که بتوانید آن را اندازه بگیرید ، می توانید در چیزی پیشرفت کنید.

همچنین ، عناوین سئو ، عناوین ، H1 ها ، برچسب های ALT ، نقشه سایت و غیره نیز از ابتدا باید وجود داشته باشد.

سرانجام ، مشتری باید تمام متن ها را از سیستم خارج کند – نباید نسخه Lorem ipsum یا تصاویر حفره یا سوراخ نگه داشته شود. ممکن است در صورت لزوم برخی از بلوک ها را پنهان کنید ، اما انتشار آن باید نه تنها از منظر توسعه بلکه “قابل ارائه” باشد.

7. پشتیبان گیری
پشتیبان گیری

تهیه نسخه پشتیبان از کد و بانک اطلاعاتی شما بسته به سیستم عامل و موارد دیگر ، یک فرایند بسیار دستی و دشوار بود. دیگر لازم نیست – یک بسته عالی و برجسته با نام Laravel-backup وجود دارد که استفاده از آن بسیار ساده است و هیچ دلیلی وجود ندارد.

حتی اگر مشتری شما به دلیل خواب خوب شبانه هزینه آن را پرداخت نکرده است ، به ویژه از بانک اطلاعاتی ، نسخه پشتیبان تهیه کنید. Codebase معمولاً در یک مخزن ذخیره می شود (اگرچه توصیه نمی شود از آن به عنوان پشتیبان اصلی استفاده شود) ، اما بانک اطلاعاتی برای تهیه نسخه پشتیبان از آنها بسیار مهم است – این بستگی به پروژه و میزان داده شما دارد ، ممکن است روزانه ، ساعتی و غیره باشد.

همچنین این بسته به شما امکان می دهد تا از درایوهای خارجی مانند Dropbox یا Amazon S3 نسخه پشتیبان تهیه کنید ، همچنین پیکربندی آن نیز آسان است. در واقع ، این نوع کار “تنظیم کنید و آن را فراموش کنید”

اما لطفاً اطمینان حاصل کنید که آن نسخه های پشتیبان در واقع چیزی دارند ، حداقل یک بار بازیابی را انجام دهید تا مطمئن شوید که کار می کند. همچنین – در مورد پشتیبان گیری به مشتری خود بگویید ، در تئوری باید حساب Dropbox / S3 / etc خود را ارائه دهند ، زیرا از نظر فنی داده های آنهاست نه شما. با مالکیت مخزن – به طور پیش فرض ، باید یا به حساب GitHub / BitBucket مشتری منتقل شود ، یا در وهله اول متعلق به مشتری باشد.

8. مستندات
مستندات

تصور کنید که بعد از یک ماه یک توسعه دهنده اضافی استخدام کنید تا سوار شوید و به شما در سرعت بخشیدن به روند کمک کند. چگونه آنها با سرعت به پروژه سرعت می یابند؟

از نظر مستندات فنی ، معمولاً یک پرونده Readme.md در فهرست اصلی کافی است. در آنجا باید مراحل نصب را بنویسید – چه دستوراتی برای اجرای پروژه در محیط محلی برای اجرای آنها نیاز دارند.

صحبت از محیط ها ، این کار خوب است که پرونده .env.example را در مخزن تهیه کنید – سپس توسعه دهندگان می دانند چه متغیرهایی را برای تنظیم در پرونده .env نهایی خود نیاز دارند.

همچنین ، اگر شما به نوعی API ایجاد می کنید (یا کل پروژه API پشتیبان است) ، مستندات بسیار مهم است. چه پارامترهایی پذیرفته شده و مورد نیاز / اختیاری هستند ، قالب های برگشتی ، کد ها و پیام های مختلف خطا چیست؟ باز هم – یک توسعه دهنده همکار جدید نباید همه اینها را حدس بزند. و همچنین هر فروشنده ای که به طور بالقوه می تواند از آن API در آینده استفاده کند. می توانید از سازنده مستندات خودکار مانند Documentarian استفاده کنید.

سرانجام ، اگر مشتری درخواست اسناد غیر فنی – مانند آموزش فیلم یا توضیحی در مورد تغییر متون یا سایر اطلاعات در وب سایت را داشته باشد ، بستگی به نحوه توافق شما با مشتری از نظر پرداخت دارد. این یک کار با هزینه اضافی است ، اما این وظیفه شماست که آن را با مشتری مرتب کنید. هدف شما در اینجا اجتناب از تماسهای تلفنی نیمه شب با “چگونه می توانم X را انجام دهم؟”

من حدس می زنم که اینها همه اقدامات اصلی برای راه اندازی پروژه Laravel است. اگر همه اینها خوب پیش برود ، می توانید موتور بازاریابی را روشن کنید ، در همه رسانه های خود در رسانه های اجتماعی فریاد بزنید و یک آبجو بگیرید. شما آن را سزاوار ، کار خوب!

[تعداد: 0   میانگین: 0/5]

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

Call Now Button