🧚🏻 🤞 💆🏼 डॉकटर के माध्यम से दोस्तों PHPstorm, xDebug और दूरस्थ शाखाओं को कैसे संकलित करें? बहुत सरल ... 👨‍✈️ 🦂 🏇🏻

शुभ दिन, हेब्र!

एक साल पहले, PHP में कोड डीबग करने की मेरी प्रक्रिया में दो लाइनें शामिल थीं:

var_dump($variable); die();

समय-समय पर, निश्चित रूप से, मुझे अधिक "जटिल" निर्माणों का उपयोग करना पड़ा:

 console.log(data);

 echo json_encode($variable, JSON_UNESCAPED_UNICODE); exit();

नहीं, तुम क्या हो! मुझे पता था - हमारे समय में ऐसा करने के लिए एक सांस्कृतिक प्रोग्रामर के लिए उपयुक्त नहीं है

प्राचीन शिल्प

एक और प्राचीन शिल्प के बारे में एक चुटकुला

लेकिन ईमानदारी से, मैं हमेशा उस चीज से डरता था जो मुझे समझ नहीं आया। XDebug ~~प्रिंटर~~ सहित, विशेष रूप से इस पूरी चीज़ को कैसे कॉन्फ़िगर करें। एक अच्छा दिन, मैं इसे अपनी कार में और एक स्थानीय परियोजना में करने में कामयाब रहा - खुशी की कोई सीमा नहीं थी। कई महीने बाद, मैं एक नई समस्या के साथ आया, कि कैसे PHPDorm में xDebug के माध्यम से डिबग किया जाए, अगर परियोजना को CI के माध्यम से दूरस्थ रूप से बनाया गया है।

यदि आप, मेरी तरह, अलग-अलग चीजों को कॉन्फ़िगर करने में कठिनाई करते हैं, तो बिल्ली का स्वागत करें, मैं डॉकर, एक्सडेबग, सीआई जैसे डरावने शब्दों के साथ एक डिबगिंग वातावरण स्थापित करने के अपने अनुभव के बारे में बात करूंगा।

उन लोगों के लिए जो पानी पसंद नहीं करते हैं और सीधे सेटिंग के सार पर जाना चाहते हैं।

आपको फफूंदी डिबगिंग विधियों से दूर क्यों होना चाहिए और पर्याप्त प्रौद्योगिकियों पर स्विच करना चाहिए?

मैंने बिल्ली को थोड़ा धोखा दिया, मैं कारीगर के डिबगिंग में लगा हुआ था, न केवल इसलिए कि मुझे कुछ कॉन्फ़िगर करने में डर था, और इसलिए नहीं कि यह बहुत बेवकूफ था, लेकिन सिर्फ इसलिए कि मुझे कुछ और सुविधाजनक की आवश्यकता नहीं थी। सबसे अधिक बार, मैंने अपने शक्तिशाली कंप्यूटर पर स्थानीय रूप से परियोजनाओं पर काम किया, और कार्य इतने जटिल नहीं थे कि डिबगिंग प्रक्रिया ने एक महत्वपूर्ण स्थान पर कब्जा करना शुरू कर दिया।

कुछ बिंदु पर, मैंने खुद के लिए महसूस किया कि मैं बस असहज था, और स्थानीय प्रोजेक्ट पर काम करते समय दोस्तों को एक्सबग और PHPstorm बनाने की कोशिश की। परेशानी यह है कि अधिकांश दस्तावेज और गाइड जो मुझे लगा कि उन्हें पढ़ने वाला व्यक्ति विषय क्षेत्र में पारंगत है और सब कुछ समझता है, मेरे मामले में यह मामला नहीं था और मैंने अपने पहले xDebug सेटअप पर 4-5 खर्च किए दोपहर 2 बजे। यह बहुत कठिन नैतिक था, मुझे असीम रूप से गूंगा महसूस हुआ। फिर भी, यह कॉन्फ़िगर करने के लिए निकला, सब कुछ काम किया!

हां, यह घर पर, स्थानीय रूप से, और अधिक सुविधाजनक हो गया, लेकिन मुख्य कार्य पर मैंने साइटों को दूरस्थ रूप से किया, और सबसे अधिक बार मैं या तो साइट को स्थानीय रूप से अनलोड करने में सक्षम नहीं था (एक कमजोर मशीन या असुविधाजनक परिनियोजन प्रक्रिया के कारण), या इसकी वजह से सेटिंग्स को प्रभावित करने के लिए होस्टिंग, इसलिए, संपादन "लाइव" और html- टिप्पणी मुद्रण_आर में लगे डिबगिंग (उस काम पर यह "सामान्य" था, हालांकि इस अनुभव पर गर्व नहीं किया गया)।

हालांकि, 3 महीने पहले मैं एक कूलर कंपनी में चला गया और एक उच्च भार के साथ वास्तव में एक गंभीर परियोजना में शामिल होना शुरू कर दिया। और यहां मेरे लिए बहुत कुछ बदल गया है। बुनियादी ढाँचा और विकास की प्रक्रिया लगभग निम्नलिखित हैं: एक GitLab सर्वर है, प्रत्येक प्रोजेक्ट की अपनी रिपॉजिटरी है, कार्य जीरा में आते हैं, आप टास्क नंबरों द्वारा एक शाखा बनाते हैं, जब CI का उपयोग करके एक शाखा बनाते हैं, तो जिस साइट पर आप चुपचाप काम करते हैं उसके साथ आपका स्वयं का सैंडबॉक्स स्वचालित रूप से बनाया जाता है, प्रत्येक पुश शाखा को पुन: प्रस्तुत करता है, कार्य के अंत में आप इसे कोड की समीक्षा के लिए देते हैं, शाखा को मास्टर में डालते हैं।

एक बीयूटी को छोड़कर सब कुछ अच्छा है, प्रत्येक मामले में एक शाखा के पुनर्निर्माण में लगभग 10 सेकंड लगते हैं। विकास की प्रक्रिया में, यह एक महत्वहीन समय है, क्योंकि मैंने पहले ही चरण को पार कर लिया है जब मुझे अनिश्चितता और थोड़े अनुभव के कारण लगभग हर पंक्ति के कोड की संचालन क्षमता की जांच करनी थी। हालांकि, जब मैंने डिबगिंग पर स्विच किया, तो इन 10 सेकंडों ने एक ठोस भूमिका निभानी शुरू कर दी। इस तरह के डिबगिंग की प्रक्रिया निम्नानुसार देखी गई:

2 लाइनें जोड़ें
पुषु कमिट
मैं 10 सेकंड प्रतीक्षा करता हूं
जांच करें, देखें क्या गलत है
दोहराना

मोटे अनुमान के अनुसार, एक मर्ज-तैयार शाखा में लगभग 20% उपयोगी कमिट और 80% डिबग कमिट थे। मान लीजिए कि मैंने 300 कमिट्स वाली एक शाखा पर काम किया, जिसमें से 240 अनिवार्य रूप से मेरे काम करने के समय का केवल 40 मिनट का समय लेता है (और यह शाखा की विधानसभा के लिए केवल प्रतीक्षा समय है, 2 सेकंड जोड़ने के लिए मिनटों को जोड़ने वाले सेकंड को ध्यान में नहीं रखते। और फिर उन्हें हटा दें)।

कुछ बिंदु पर मैं इससे थक गया था और मैंने डिबगिंग प्रक्रिया को कम खर्चीला बनाने के लिए xDebug को कॉन्फ़िगर करने का निर्णय लिया। दुर्भाग्य से, मेरे वर्तमान सहयोगियों ने या तो इस तकनीक का उपयोग नहीं किया था (मैं एक शांत कंपनी के बारे में मज़ाक का इंतजार कर रहा था जहां कोई xDebug का उपयोग नहीं करता है), या उन्हें पता नहीं था कि शाखा के साथ xDebug IDE से दोस्ती कैसे करें। सीआई के माध्यम से दूरस्थ रूप से जाना, और जब से मैंने कभी नहीं किया है और जैसा कि मैंने ऊपर उल्लेख किया है, कुछ स्थापित करने की प्रक्रिया मेरे लिए एक दर्दनाक प्रक्रिया है, अंत में काम करने में लगभग 6 घंटे का शुद्ध समय लगता है, और मुझे यह प्रक्रिया समझ में आई, और यह काफी सुविधाजनक होगा।

सेटअप प्रक्रिया

मैं सामान्य रूप से CI, Docker को कैसे तेज किया जाए, बुनियादी ढांचे को कैसे इकट्ठा किया जाए, इस पर विवरण में नहीं जाऊंगा, यह माना जाता है कि यह सब किया जाता है और जो कुछ भी शेष है वह आपके व्यक्तिगत वातावरण को स्थापित करना है।

मान लीजिए कि हमारी रिपॉजिटरी में कुछ इस तरह की संरचना है:

पहले हमें यह जांचने की आवश्यकता है कि क्या xDebug स्वयं वर्तमान छवि में है, इसके लिए आप phpinfo () का उपयोग कर सकते हैं ;

यदि xDebug पहले से ही असेंबली में शामिल है - ठीक है, यदि नहीं, तो इस स्रोत की जांच करें , जिससे मुझे सेटअप में सीधे मदद मिली, हालांकि, मैं थोड़ा अलग तरीके से गया।

Php.ini को कॉन्फ़िगर करें

सब कुछ अंत में काम करने के लिए, 2 xDebug सेटिंग्स हमारे लिए महत्वपूर्ण हैं:

xdebug.remote_enable
xdebug.remote_host

दूरस्थ शाखा की अंतिम असेंबली में, Remote_enable को सक्षम किया जाना चाहिए, और Remote_host में नेटवर्क पर आपके कंप्यूटर का IP असाइन किया जाना चाहिए। आइए इन सेटिंग्स को हमारे बिल्ड में शामिल करें।

पहले आपको यह पता लगाने की आवश्यकता है कि php सेटिंग्स कहाँ संग्रहीत हैं, वे /usr/local/etc/php/conf.d/php.ini में स्थित हो सकते हैं, या .ini फ़ाइल को अलग से नाम दिया जा सकता है, मेरे कंप्यूटर में यह / usr / स्थानीय / स्थानीय है। आदि / 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.tpl पर लाइन जोड़कर वॉल्यूम के माध्यम से करता हूं:
- ${PROJECT_DIR}/build_env/php/php-settings.ini:/usr/local/etc/php/conf.d/php-settings.ini

यह मेरी परियोजना में docker-compose.tmpl जैसा दिखता है:

अगली बार जब आप शाखा का निर्माण करते हैं, तो आप जांच सकते हैं कि क्या नई सेटिंग्स उसी phpinfo () के माध्यम से बाध्य हैं ; यदि हाँ - उत्कृष्ट, यदि नहीं - तो आप भाग्य से बाहर हैं और उसी तरह से जाना होगा जैसे मैंने पहली बार किया था :(

PHPstorm में मैपिंग को अनुकूलित करना

अगला, आपको स्वयं PHPstorm को कॉन्फ़िगर करने की आवश्यकता है। मैंने DBgp प्रॉक्सी का उपयोग न करने का फैसला किया, ताकि हर बार पॉपअप में मैपिंग को कॉन्फ़िगर न किया जा सके। मेरे मामले में, मैं एक सर्वर टेम्पलेट का उपयोग करता हूं जिसमें आवश्यक मैपिंग शामिल होगी।

सेटिंग्स / वरीयताएँ पर जाएँ | भाषाएँ और रूपरेखा | Php | सर्वर

एक सर्वर टेम्पलेट बनाएँ
नाम: BRANCH
होस्ट: कोई भी, यह प्रभावित नहीं करता है
पोर्ट: किसी भी, यह प्रभावित नहीं करता है
डिबगर: xDebug
उपयोग पथ मैपिंग पर एक पंजा रखो
हम उपयुक्त मैपिंग को नीचे रखते हैं, कार्यशील स्थानीय फ़ोल्डर को सर्वर पर उन फ़ोल्डरों के अनुरूप होना चाहिए जहां एकत्रित शाखाएँ स्थित हैं, मेरे मामले में एकत्रित बिल्ड / / var / www / build / your_namespace / your_project (your_branch फ़ोल्डर) में हैं

हम इन सेटिंग्स को सहेजते हैं, हम हर बार जब हम एक नई शाखा के साथ काम करते हैं, तो हम उन्हें बदल देंगे। उदाहरण के लिए, अगर आज मैं वेब -2233 शाखा के साथ काम करता हूं, तो मैं मैपिंग को बदलकर / var / www / build / build_path / web-2233 कर दूंगा

एक नया वातावरण चर जोड़ें ताकि IDE स्वचालित रूप से मैपिंग को खींच ले

अब एक बल्कि महत्वपूर्ण और सबसे स्पष्ट बिंदु नहीं है। जब हम डिबग शुरू करते हैं, तो PHPstorm को समझने की जरूरत है कि कौन सी स्थानीय फाइलें रिमोट सर्वर पर फाइलों के अनुरूप हैं। यदि सर्वर ने इसे एक विशिष्ट इंस्टॉलेशन नहीं दिया, तो एक पॉप-अप विंडो दिखाई देगी जिसमें आपको पथ को मैन्युअल रूप से मैप करने की आवश्यकता होती है। PHPstorm के लिए तुरंत BRANCH नाम के सर्वर से मैपिंग लेने के लिए, आपको हमारी विधानसभा में PHP_IDE_CONFIG पर्यावरण चर जोड़ना होगा

In /build_env/docker-compose/docker-compose.tmpl पर्यावरण में एक नया वातावरण परिवर्तनशील बनाता है:
PHP_IDE_CONFIG: ${PHP_IDE_CONFIG}

.Itllab-ci.yml में हमने यह चर निर्धारित किया है:
- export PHP_IDE_CONFIG="serverName=BRANCH"

हो गया!

हमें ब्राउज़र एक्सटेंशन की आवश्यकता नहीं है, पैरामीटर प्राप्त करने के लिए URL XDEBUG_SESSION_START = IDE_KEY पास करने की आवश्यकता नहीं है, हमें अतिरिक्त कॉन्फ़िगरेशन जोड़ने की आवश्यकता नहीं है।

बस वायरटैप चालू करें

और साइट पृष्ठ को ताज़ा करें, जैसे ही हम पहले ब्रेकपॉइंट पर ठोकर खाते हैं, आवेदन उस पर बंद हो जाएगा

आपका ध्यान देने के लिए धन्यवाद, मुझे उम्मीद है कि यह लेख उपयोगी होगा और कोई भी मेरे जैसे ही रेक पर कदम रखे बिना समय बचा लेगा :)

प्रारंभिक सेटअप के दौरान मैंने जो स्रोत उपयोग किए हैं:
https://gist.github.com/chadrien/c90927ec2d160ffea9c4
https://confluence.jetbrains.com/display/PhpStorm/Docker+Support+in+PhpStorm#DockerSupportinPhpStorm-DebuggingthePHPwebapplicationrunningintheDockercontainer