يوم جيد ، هبر!
قبل عام ، كانت عملية تصحيح الأخطاء في PHP تتكون من سطرين:
var_dump($variable); die();
من وقت لآخر ، بالطبع ، كان عليّ استخدام منشآت "أكثر تعقيدًا":
console.log(data);
echo json_encode($variable, JSON_UNESCAPED_UNICODE); exit();
لا ما انت! كنت أعلم - في عصرنا هذا ليس من المناسب لمبرمج ثقافي أن يفعل ذلك
الحرف القديمةنكتة عن حرفة قديمة أخرى
لكن بصراحة ، كنت دائمًا خائفة مما لم أفهمه. بما في ذلك
طابعات xDebug ، ولا سيما كيفية تكوين هذا الأمر بالكامل. في أحد الأيام الجميلة ، تمكنت من القيام بذلك في سيارتي وفي مشروع محلي - لم يكن هناك حد للفرح. بعد عدة أشهر ، صادفت مشكلة جديدة ، كيفية تصحيح الأخطاء في PHPstorm عبر xDebug ، إذا تم بناء المشروع عن بعد بواسطة عامل الميناء عبر CI.
إذا كنت ، مثلي ، تجد صعوبة في تكوين أشياء مختلفة ، ومرحبًا بك في القطة ، سأتحدث عن تجربتي في إنشاء بيئة تصحيح الأخطاء باستخدام كلمات مخيفة مثل Docker و xDebug و CI.
بالنسبة لأولئك الذين لا يحبون الماء ويريدون الذهاب مباشرة إلى جوهر الإعداد.
لماذا يجب عليك الابتعاد عن طرق التصحيح المتعفنة والتحول إلى التقنيات المناسبة؟
لقد خدعت القطة قليلاً ، لقد انخرطت في تصحيح الأخطاء الحرفية ، ليس فقط لأنني كنت خائفة من تكوين شيء ما ، وليس لأنه كان غبيًا جدًا ، ولكن ببساطة لأنني لم أكن بحاجة إلى شيء أكثر ملاءمة. في معظم الأحيان ، كنت أعمل على مشاريع محليًا على جهاز الكمبيوتر القوي الخاص بي ، ولم تكن المهام معقدة للغاية لدرجة أن عملية التصحيح بدأت في شغل منصب مهم إلى حد ما.
في مرحلة ما ، أدركت بنفسي أنني غير مرتاح ، وحاولت تكوين صداقات xDebug و PHPstorm عند العمل في مشروع محلي. المشكلة هي أن معظم الوثائق والأدلة التي وجدتها تشير ضمنيًا إلى أن الشخص الذي يقرأها على دراية جيدة في مجال الموضوع ويفهم كل شيء ، في حالتي لم يكن الأمر كذلك وقضيت 4-5 في إعداد xDebug الأول ساعات في 2 بعد الظهر. لقد كان الأمر أخلاقيًا صعبًا ، وشعرت بالغباء بلا حدود. ومع ذلك ، اتضح أن كل شيء يعمل!
نعم ، أصبح الأمر أكثر ملاءمة ، محليًا ، في المنزل ، ولكن في العمل الرئيسي قمت بالمواقع عن بُعد ، وفي الغالب لم أتمكن من إما تفريغ الموقع محليًا (بسبب ضعف الجهاز أو عملية النشر غير المريحة) ، أو للتأثير على إعدادات الخادم بسبب الاستضافة ، لذلك ، جعلت التعديلات "مباشرة" وتصحيح الأخطاء في html-commenting print_r (في هذا العمل كان "طبيعيًا" ، على الرغم من أنه ليس فخورًا بهذه التجربة).
ومع ذلك ، قبل 3 أشهر ، انتقلت إلى شركة أكثر برودة وبدأت الانخراط في مشروع خطير حقًا مع حمولة عالية. وهنا تغير الكثير بالنسبة لي. البنية التحتية وعملية التطوير هي تقريبًا ما يلي: هناك خادم GitLab ، كل مشروع له مستودعه الخاص ، المهام تأتي إلى Jira ، يمكنك إنشاء فرع حسب أرقام المهام ، عند إنشاء فرع باستخدام CI ، يتم إنشاء صندوق الحماية الخاص بك مع الموقع الذي تعمل فيه بهدوء تلقائيًا ، كل دفعة يعيد تجميع الفرع ، في نهاية العمل الذي تعطيه لمراجعة الشفرة ، صب الفرع في الرئيسي.
كل شيء رائع باستثناء BUT واحد ، كل إعادة بناء فرع في حالتي تستغرق حوالي 10 ثوانٍ. في عملية التطوير نفسها ، يعد هذا وقتًا غير ذي أهمية ، نظرًا لأنني قد تجاوزت المرحلة بالفعل عندما كان عليّ التحقق من قابلية تشغيل الرمز لكل سطر تقريبًا بسبب عدم اليقين وقلة الخبرة. ومع ذلك ، عندما تحولت إلى تصحيح الأخطاء ، بدأت هذه الثواني العشر تلعب دورًا ملموسًا. تبدو عملية تصحيح الأخطاء كما يلي:
- أضف سطرين
- تلتزم Pushu
- أنتظر 10 ثوان
- تحقق ، انظر ما هو الخطأ
- كرر
وفقًا للتقديرات التقريبية ، حصل الفرع الجاهز للدمج على ارتباطات مفيدة بنسبة 20٪ تقريبًا و 80٪ من عمليات تصحيح الأخطاء. لنفترض أنني انتهيت من العمل في فرع يحتوي على 300 التزام ، منها 240 التزامًا استهلكت 40 دقيقة فقط من وقت عملي (وهذا هو فقط وقت الانتظار لتجميع الفرع ، مع عدم مراعاة الثواني التي تصل إلى دقائق ، لإضافة سطرين ثم حذفها).
في وقت ما كنت قد سئمت منه وقررت تكوين xDebug لجعل عملية التصحيح أقل تكلفة. لسوء الحظ ، إما أن زملائي الحاليين إما لم يستخدموا هذه التكنولوجيا (أنا في انتظار نكتة عن "لدي شركة رائعة حيث لا أحد يستخدم xDebug") ، أو أنهم لا يعرفون / لم يتذكروا كيفية تكوين صداقات مع xDebug IDE عندما يقوم الفرع الذهاب عن بعد من خلال CI ، وبما أنني لم أقم أبداً بتطويره وكما ذكرت أعلاه ، فإن عملية إعداد شيء ما هي عملية مؤلمة بالنسبة لي ، فقد أدت إلى حوالي 6 ساعات من الوقت الخالص ، حتى نجحت في النهاية ، وفهمت العملية وهذا سيكون ملائماً بما يكفي.
عملية الإعداد
لن أخوض في تفاصيل حول كيفية تثبيت CI ، Docker ، بشكل عام ، وكيفية تجميع البنية التحتية ، ومن المفترض أن يتم كل ذلك وكل ما تبقى هو إعداد بيئتك الشخصية.
لنفترض أن المستودع الخاص بنا يحتوي على شيء مثل هذا الهيكل:
نحتاج أولاً إلى التحقق مما إذا كان xDebug نفسه في الصورة الحالية ، لذلك يمكنك استخدام
phpinfo () ؛إذا تم تضمين xDebug بالفعل في التجميع - جيد ، إذا لم يكن كذلك ، فراجع
هذا المصدر ، الذي ساعدني مباشرة في الإعداد نفسه ، ومع ذلك ، فقد ذهبت بطريقة مختلفة قليلاً.
تكوين php.ini
لكي يعمل كل شيء في النهاية ، هناك إعدادان مهمان بالنسبة لنا:
- xdebug.remote_enable
- xdebug.remote_host
في التجميع النهائي للفرع البعيد ، يجب تمكين
remote_enable ، وفي
remote_host يجب
تعيين IP الخاص بجهاز الكمبيوتر الخاص بك على الشبكة. دعنا ندرج هذه الإعدادات في بنائنا.
تحتاج أولاً إلى معرفة مكان تخزين إعدادات php ، ويمكن وضعها إما في
/usr/local/etc/php/conf.d/php.ini ، أو يمكن تسمية ملف .ini بشكل مختلف ، في حالتي هو
/ usr / local / etc / php / conf.d / php-settings.ini . يمكنك معرفة ذلك من إعدادات الصورة المجمعة.
نقوم بإنشاء
إعداداتنا الإضافية في فرعنا من خلال نفس ملف php-settings.ini ،
ونضعه في
./build_env/php/php-settings.iniنكتب فيه 2 من الإعدادات المذكورة أعلاه:
xdebug.remote_enable = on
xdebug.remote_host = IP...بعد ذلك ، نحتاج إلى إضافة هذا الملف إلى إعدادات الصورة "الأصل". أقوم بذلك من خلال المجلدات عن طريق إضافة السطر إلى ./build_env/docker-compose/docker-compose.tmpl:
- ${PROJECT_DIR}/build_env/php/php-settings.ini:/usr/local/etc/php/conf.d/php-settings.iniهذا ما يبدو عليه docker-compose.tmpl في مشروعي:
في المرة التالية التي تقوم فيها بإنشاء الفرع ، يمكنك التحقق مما إذا كانت الإعدادات الجديدة مرتبطة عبر نفس
phpinfo () ؛ إذا كانت الإجابة بنعم - ممتاز ، إن لم يكن - فأنت محظوظ وسيتعين عليك أن تسير بنفس الطريقة التي قمت بها في المرة الأولى :(
تخصيص التعيينات في PHPstorm
بعد ذلك ، تحتاج إلى تكوين PHPstorm نفسه. قررت عدم استخدام وكيل DBgp ، حتى لا أقوم بتكوين التعيينات في النافذة المنبثقة في كل مرة. في حالتي ، أستخدم قالب خادم يحتوي على التعيينات اللازمة.
انتقل إلى
الإعدادات / التفضيلات | اللغات والأطر | فب | خوادم- قم بإنشاء قالب خادم
- الاسم: فرع
- المضيف: أي ، لا يؤثر
- المنفذ: أي ، لا يؤثر
- المصحح: xDebug
- ضع داو على استخدام تعيينات المسار
- وضعنا التعيينات المناسبة ، يجب أن تتوافق المجلدات المحلية العاملة مع المجلدات الموجودة على الخادم حيث توجد الفروع التي تم جمعها ، وفي حالتي تكون البنيات التي تم جمعها في المجلد / var / www / builds / your_namespace / your_project / your_branch
نقوم بحفظ هذه الإعدادات ، وسنقوم بتغييرها في كل مرة نعمل فيها مع فرع جديد. على سبيل المثال ، إذا كنت أعمل اليوم مع فرع web-2233 ، فسوف أقوم بتغيير التعيين إلى
/ var / www / builds / build_path / web-2233قم بإضافة متغير بيئة جديد بحيث يقوم IDE بسحب التعيينات تلقائيًا لأعلى
الآن نقطة مهمة وليس النقطة الأكثر وضوحا. عندما نبدأ التصحيح ، يحتاج PHPstorm إلى فهم الملفات المحلية التي تتوافق مع الملفات الموجودة على الخادم البعيد. إذا لم يمنحه الخادم تثبيتًا محددًا ، فستظهر نافذة منبثقة تحتاج فيها إلى تعيين المسارات يدويًا. لكي يأخذ PHPstorm تعيينات على الفور من خادم باسم BRANCH ، تحتاج إلى إضافة متغير بيئة
PHP_IDE_CONFIG إلى مجموعتنا
في
./build_env/docker-compose/docker-compose.tmpl إنشاء متغير بيئة جديد في البيئة:
PHP_IDE_CONFIG: ${PHP_IDE_CONFIG}
في
.gitlab-ci.yml قمنا بتعيين هذا المتغير:
- export PHP_IDE_CONFIG="serverName=BRANCH"
انتهى!
لا نحتاج إلى ملحقات المستعرض ، لا نحتاج إلى تمرير URL XDEBUG_SESSION_START = IDE_KEY للحصول على المعلمات ، لسنا بحاجة إلى إضافة تكوينات إضافية.
فقط قم بتشغيل التنصت
وتحديث صفحة الموقع ، بمجرد تعثرنا عند نقطة التوقف الأولى ، سيتوقف التطبيق عندها
شكرا لكم على اهتمامكم ، آمل أن تكون هذه المقالة مفيدة وسيوفر شخص ما الوقت دون أن يخطو في نفس أشعل النار مثلي :)
المصادر التي استخدمتها أثناء الإعداد الأولي:
https://gist.github.com/chadrien/c90927ec2d160ffea9c4https://confluence.jetbrains.com/display/PhpStorm/Docker+Support+in+PhpStorm#DockerSupportinPhpStorm-DebuggingthePHPwebapplicationrunningintheDockercontainer