संगीतकार के विकास / उत्पादन स्विच का उपयोग करते समय सही तरीके से कैसे तैनात किया जाए?

Question

संगीतकार के पास केवल विकास में रहते हुए कई निर्भरताएँ लोड करने का विकल्प होता है, इसलिए उपकरण उत्पादन में (लाइव सर्वर पर) स्थापित नहीं होंगे। यह (सिद्धांत में) लिपियों के लिए बहुत आसान है जो केवल विकास में समझ में आता है, जैसे परीक्षण, नकली-डेटा-उपकरण, डिबगर, आदि।

जाने का तरीका require-devदेव में आपकी ज़रूरत के साधनों के साथ एक अतिरिक्त ब्लॉक जोड़ना है :

"require-dev": {
    "codeception/codeception": "1.6.0.3"
}

और फिर (सैद्धांतिक रूप से) इन निर्भरताओं को माध्यम से लोड करते हैं

composer install --dev

समस्या और प्रश्न:

संगीतकार के व्यवहार बदल गया है installऔर update2013 में नाटकीय रूप से, require-dev-dependencies अब डिफ़ॉल्ट रूप से स्थापित कर रहे हैं (!), एक के साथ एक composer.json बनाने के लिए स्वतंत्र महसूस require-devब्लॉक और एक प्रदर्शन composer installपुन: पेश करने।

जैसा कि तैनात करने का सबसे स्वीकृत तरीका संगीतकार को धक्का देना है। लॉक (जो आपके वर्तमान संगीतकार सेटअप को रखता है) और फिर composer installउत्पादन सर्वर पर करता है, इससे विकास सामग्री भी स्थापित होगी।

-देवी निर्भरता को स्थापित किए बिना इसे तैनात करने का सही तरीका क्या है ?

_{नोट: मैं अजीब कंपोजर की तैनाती को स्पष्ट करने के लिए यहां एक विहित क्यू / ए बनाने की कोशिश कर रहा हूं। इस प्रश्न को संपादित करने के लिए स्वतंत्र महसूस करें।}

Comments

@all: पता नहीं कहाँ बाउंटी है :( मैं एक और दृष्टिकोण शुरू करूँगा।

— शालिक

यदि आप इसे सक्रिय रूप से पुरस्कार नहीं देते हैं, और कोई भी उत्तर स्वीकार नहीं किया जाता है या पर्याप्त उत्थान नहीं मिलता है, तो किसी को भी इनाम नहीं मिलता है।

— स्वेन

मुझे व्यक्तिगत रूप से यह दृष्टिकोण बिल्कुल पसंद नहीं है। composer.lockGit रेपो के लिए कभी नहीं जोड़ा जाना चाहिए, कभी नहीं। सही दृष्टिकोण स्टेजिंग पर संगीतकार अपडेट का उपयोग करना है और फिर फ़ाइल को उत्पादन में (यदि सब कुछ काम करता है) निश्चित रूप से सिंक करना है। स्टेजिंग को उत्पादन वातावरण की सटीक प्रतिलिपि होना चाहिए। composer.lockका हिस्सा होना चाहिए .gitignore।

— संज्ञा

composer.lock को निश्चित रूप से आपके CSV में शामिल किया जाना है !!! आप कैसे सुनिश्चित करें कि हर कोई एक ही संस्करण का उपयोग करता है ?? तो कभी अपने CSV से कंपोज़र को अनलॉक न करें !!!

— टोबियास गर्टनर

@TobiasGaertner मुझे लगता है कि आपको VCS (संस्करण नियंत्रण सॉफ़्टवेयर) से मतलब है, लेकिन अन्यथा आप सही हैं और परियोजना की आधिकारिक सिफारिशों के अनुरूप हैं ।

— Xiong Chiamiov

Answer 1

क्यों

आईएमएचओ एक अच्छा कारण है कि आजकल कंपोजर --devफ्लैग का उपयोग डिफ़ॉल्ट रूप से (इंस्टॉल और अपडेट पर) करेगा। संगीतकार ज्यादातर परिदृश्य में चलता है जहां यह वांछित व्यवहार है:

मूल संगीतकार वर्कफ़्लो इस प्रकार है:

• एक नई परियोजना शुरू की गई है: composer.phar install --devजेसीएस और लॉक फाइलें वीसीएस के लिए प्रतिबद्ध हैं।
• अन्य डेवलपर्स प्रोजेक्ट पर काम करना शुरू करते हैं: वीसीएस का चेकआउट और composer.phar install --dev।
• डेवलपर dependancies जोड़ता है: composer.phar require <package>जोड़ने, --devआप में पैकेज चाहते हैं, तो require-devखंड (और प्रतिबद्ध)।
• अन्य साथ जाते हैं: (चेकआउट और) composer.phar install --dev।
• एक डेवलपर निर्भरता के नए संस्करण चाहता है: composer.phar update --dev <package>(और प्रतिबद्ध)।
• अन्य साथ जाते हैं: (चेकआउट और) composer.phar install --dev।
• परियोजना तैनात है: composer.phar install --no-dev

जैसा कि आप देख सकते हैं कि --devध्वज का उपयोग ध्वज से अधिक (बहुत दूर) किया गया है --no-dev, खासकर जब परियोजना पर काम करने वाले डेवलपर्स की संख्या बढ़ती है।

उत्पादन तैनात है

"देव" निर्भरता स्थापित किए बिना इसे तैनात करने का सही तरीका क्या है?

ठीक है, composer.jsonऔर composer.lockफ़ाइल को वीसीएस के लिए प्रतिबद्ध होना चाहिए। छोड़ना नहीं चाहिए composer.lockक्योंकि इसमें पैकेज-संस्करणों पर महत्वपूर्ण जानकारी है जिसका उपयोग किया जाना चाहिए।

जब कोई उत्पादन परिनियोजित करता है, तो आप --no-devध्वज को संगीतकार के पास भेज सकते हैं :

composer.phar install --no-dev

composer.lockफ़ाइल देव-पैकेज के बारे में जानकारी हो सकती है। इससे कोई फर्क नहीं पड़ता। --no-devझंडा यकीन है कि उन देव-संकुल स्थापित नहीं हैं कर देगा।

जब मैं कहता हूं कि "उत्पादन तैनात है", मेरा मतलब है कि एक ऐसी तैनाती जिसका उद्देश्य उत्पादन में उपयोग किया जा रहा है। मैं तर्क नहीं दे रहा हूं कि क्या composer.phar installउत्पादन सर्वर पर किया जाना चाहिए, या एक स्टेजिंग सर्वर पर जहां चीजों की समीक्षा की जा सकती है। यह इस उत्तर की गुंजाइश नहीं है। मैं केवल composer.phar install"देव" पर निर्भरता स्थापित किए बिना कैसे इंगित कर रहा हूं ।

विषय से परे

--optimize-autoloaderझंडा भी उत्पादन पर वांछनीय हो सकता है (यह एक वर्ग नक्शा जो अपने आवेदन में Autoloading तेज़ हो जाएगी उत्पन्न करता है):

composer.phar install --no-dev --optimize-autoloader

या जब स्वचालित तैनाती की जाती है:

composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --no-suggest --optimize-autoloader

यदि आपका कोडबेस इसका समर्थन करता है, तो आप इसके --optimize-autoloaderलिए स्वैप कर सकते हैं --classmap-authoritative। अधिक जानकारी यहाँ

Comments

मैं एक अपवाद के साथ कही गई अधिकांश बातों से सहमत हूं। "कंपोज़र इनस्टॉल -नो-देव" को केवल स्टेजिंग वातावरण में निष्पादित किया जाना चाहिए और उस वातावरण को अपरिवर्तनीय माना जाना चाहिए। मैं किसी भी निर्भरता को सीधे अपने उत्पादन सर्वर पर डाउनलोड नहीं करना चाहता और बिना पूर्वावलोकन / मंचन के। यह सावधानी का एक अतिरिक्त सा है।

— स्केलेबल

@ स्केलेबल: हालाँकि मैं आपसे सहमत हूँ (और स्वेन ने अपने उत्तर में इसे अच्छी तरह से शामिल किया है), यह मेरे उत्तर का दायरा नहीं है, और न कि मेरा "उत्पादन तैनात" के साथ क्या मतलब है। मैंने यह स्पष्ट करने के लिए एक पैराग्राफ जोड़ा है।

— जैस्पर एन। ब्रूवर

वास्तव में मुझे लगता है कि डिफ़ॉल्ट को कम खतरनाक विकल्प होना चाहिए। - डिफ़ॉल्ट बनाना और गलती से प्रोडक्शन में कंपोज़र इंस्टॉल करना घातक हो सकता है।

— हेक्टर ऑर्डोनेज़

में अच्छी बात है --optimize-autoloader। इस पर भी विचार करें --classmap-authoritative- यहां से प्रलेखन से getcomposer.org/doc/03-cli.md आप इसे देख सकते हैं: "केवल क्लासमेट से ऑटोलॉड कक्षाएं। Implicitly सक्षम बनाता है --optimize-autoloader" ताकि आप उपयोग कर सकें कि क्या आप कक्षाओं को जानते हैं "। जब तक आप गतिशील रूप से कक्षाएं उत्पन्न नहीं करते हैं, तब तक संभवत: आपके उत्पादों के वातावरण में ऐसा होना चाहिए।

— ज़ावि मोंटेरो

शानदार उत्तर, मैं optimize-autoloaderसीधे जोड़ना चाहूँगा composer.json:{"config": { "optimize-autoloader": true } }

— यवन

Answer 2

वास्तव में, मैं अत्यधिक उत्पादन सर्वर पर निर्भरता स्थापित करने की सलाह दूंगा।

मेरी सिफारिश एक तैनाती मशीन पर कोड की जांच करने के लिए है, आवश्यकतानुसार निर्भरता स्थापित करें (यदि कोड उत्पादन में नहीं जाता है तो देव निर्भरता स्थापित करना शामिल है), और फिर सभी फाइलों को लक्ष्य मशीन में स्थानांतरित करें।

क्यों?

• साझा होस्टिंग पर, आप कमांड लाइन में नहीं जा पाएंगे
• यहां तक ​​कि अगर आपने किया, तो कमांड, मेमोरी या नेटवर्क एक्सेस के संदर्भ में PHP को प्रतिबंधित किया जा सकता है
• रिपॉजिटरी सीएलआई उपकरण (Git, Svn) स्थापित नहीं होने की संभावना है, जो विफल हो जाएगा यदि आपकी लॉक फाइल ने जिप के रूप में उस कमेट को डाउनलोड करने के बजाय एक निश्चित कमिटमेंट की जांच करने के लिए एक निर्भरता दर्ज की है (आपने उपयोग किया है --prefer-source, या Composite पड़ा था उस संस्करण को पाने का कोई अन्य तरीका नहीं)
• यदि आपकी उत्पादन मशीन एक छोटे परीक्षण सर्वर की तरह है (अमेज़ॅन ईसी 2 माइक्रो उदाहरण सोचें) तो निष्पादित करने के लिए संभवतः पर्याप्त मेमोरी स्थापित नहीं है composer install
• जब संगीतकार चीजों को तोड़ने की कोशिश नहीं करता है, तो आप आंशिक रूप से टूटी हुई उत्पादन वेबसाइट के साथ समाप्त होने के बारे में कैसा महसूस करते हैं क्योंकि कुछ यादृच्छिक निर्भरता को कंपोजर स्थापित चरण के दौरान लोड नहीं किया जा सकता है

लंबी कहानी छोटी: एक ऐसे वातावरण में संगीतकार का उपयोग करें जिसे आप नियंत्रित कर सकते हैं। आपकी विकास मशीन अर्हता प्राप्त करती है क्योंकि आपके पास पहले से ही वे सभी चीजें हैं जो संगीतकार को संचालित करने के लिए आवश्यक हैं।

-देवी निर्भरता को स्थापित किए बिना इसे तैनात करने का सही तरीका क्या है?

उपयोग करने की आज्ञा है

composer install --no-dev

यह किसी भी वातावरण में काम करेगा, चाहे वह उत्पादन सर्वर ही हो, या परिनियोजन मशीन, या विकास मशीन जिसे अंतिम जांच करने के लिए माना जाता है कि क्या वास्तविक सॉफ्टवेयर के लिए किसी भी देव आवश्यकता का गलत उपयोग किया जाता है।

आदेश इंस्टॉल नहीं होगा, या सक्रिय रूप से अनइंस्टॉल नहीं होगा, कंपोज़र ।लॉक फ़ाइल में घोषित देव आवश्यकताएं।

यदि आप किसी उत्पादन सर्वर पर विकास सॉफ़्टवेयर घटकों को तैनात करने से इनकार नहीं करते हैं, तो रनिंग composer installएक ही काम करेगा, लेकिन बस बाइट्स की मात्रा में इजाफा होगा, और एक बड़ा ऑटोलैडर घोषणा भी बना सकते हैं।

Comments

दिलचस्प वर्कफ़्लो, लेकिन वहाँ एक बड़ा चोर है : रिपॉजिटरी में कभी भी विक्रेता फ़ोल्डर / सामग्री नहीं होनी चाहिए (संगीतकार पेज पर आधिकारिक बयान), इसलिए उन्हें सीधे गिट-आधारित तैनाती में उत्पादन के लिए धक्का नहीं दिया जाएगा (जो एक सामान्य मानक afaik है) यदि मैं गलत हूं तो मुझे सही करों)। तो मूल रूप से उपरोक्त समाधान केवल "पुराने-स्कूल" एफ़टीपी-तैनाती के साथ काम करता है? " कृपया इसके बारे में आगे चर्चा करें ...

— शालिक

मेरे सुझाए गए वर्कफ़्लो में कोड को GIT के माध्यम से उत्पादन सर्वर पर धकेलना शामिल नहीं है। वास्तव में, मैं इसके खिलाफ सिफारिश करूंगा, क्योंकि ऐसा करने से आपको प्रोडक्शन सर्वर पर कम्पोजर निर्भरता स्थापित करने के लिए मजबूर होना पड़ेगा, जो किसी भी मुद्दे को उठा सकता है। यदि आप चाहते हैं कि आपकी तैनाती सुचारू रूप से चले, तो आपको वर्तमान संस्करण को नष्ट करने और इसे बदलने से पहले एप्लिकेशन को चलाने के लिए आवश्यक सभी कोड को इकट्ठा करना होगा। एफ़टीपी पसंद नहीं है? SSH के माध्यम से RSync करें, फिर सिमिलिंक फ्लिप करके संस्करणों को स्विच करें। लेकिन अगर आप चाहें तो आप पुश, चेकआउट और कंपोजर भी लगा सकते हैं।

— स्वेन

@Panique: मैंने सिर्फ आपकी टिप्पणी के उस हिस्से को देखा है और मुझे जवाब देना है: "एक गिट-आधारित तैनाती में उत्पादन को धक्का दिया (जो कि एक सामान्य मानक है, मुझे सही कर रहा हूं अगर मैं गलत हूं)" - नहीं, यह नहीं सामान्य मानक नहीं है। इसे करने का सिर्फ एक तरीका है।

— स्वेन

मैं जिस टीम में हूं, उसने इसे अपने वर्कफ़्लो में बड़ी सफलता के साथ शामिल किया है। हमारे पास एक निर्माण मशीन (जेनकिंस, निश्चित रूप से) है: 1) एससी 2 से बाहर की जाँच करता है) संगीतकार स्थापित करता है / अपडेट 3) यूनिट परीक्षण चलाता है 4) देव निर्भरता को हटाता है 5) एक फ़ार फ़ाइल ( app-1.34.pharआदि) उत्पन्न करता है । एक अलग तंत्र है जिसे अधिसूचित किया जाता है और उस फ़ाइल को हड़पने के लिए निर्णय लिया जाता है कि उसे कहाँ स्थानांतरित करना है और फिर इसके साथ क्या करना है। कुछ टीमें सर्वर पर एक बार फ़ार को अनपैक करने के लिए चुनती हैं और कुछ टीमें इसे चलाती हैं। यह हमारे deploys की स्थिरता और प्रतिलिपि प्रस्तुत करने योग्यता के लिए बहुत विश्वास है।

— जोश जॉनसन

मैं इस जवाब से 100% सहमत हूँ। कंपोज़र को परिनियोजन सर्वर पर स्थापित नहीं किया जाना चाहिए, न ही गिट। निरंतर परिनियोजन / इंटरग्रेशन सर्वर वास्तव में स्रोत और निर्भरता को प्रबंधित करने के लिए चाहिए होते हैं: गिट पुल> कम्पोज़र इंस्टाल> परिनियोजित

— एरिक मॉरेंड

Answer 3

अब require-devडिफ़ॉल्ट रूप से सक्षम है, स्थानीय विकास के लिए composer installऔर विकल्प के composer updateबिना आप कर सकते हैं --dev।

जब आप उत्पादन के लिए तैनात करना चाहते हैं, तो आपको यह सुनिश्चित करना होगा कि आपके composer.lockपास कोई पैकेज नहीं है require-dev।

आप इसके साथ कर सकते हैं

composer update --no-dev

एक बार जब आप स्थानीय रूप से परीक्षण कर लेते हैं, --no-devतो आप उत्पादन के आधार पर सब कुछ तैनात कर सकते हैं और उसके आधार पर स्थापित कर सकते हैं composer.lock। आपको --no-devफिर से विकल्प की आवश्यकता है, अन्यथा संगीतकार कहेंगे "लॉक फ़ाइल में आवश्यकता-देव जानकारी नहीं है" ।

composer install --no-dev

नोट: ऐसी किसी भी चीज़ से सावधान रहें जिसमें देव और उत्पादन के बीच के अंतर को पेश करने की क्षमता है! मैं आम तौर पर जहां भी संभव हो वहां आवश्यकता-देवता से बचने की कोशिश करता हूं, क्योंकि देव उपकरण भी एक बड़ा उपरि नहीं है।

Comments

यह वास्तव में विवरण में गलत है। composer.lockदेव निर्भरता के लिए जाँच करने की कोई आवश्यकता नहीं है । आप बस चलाएंगे composer install --no-dev, और आपको केवल नियमित निर्भरताएँ ही मिलेंगी - वास्तव में, संगीतकार भी इस चरण में किसी भी प्रकार की निर्भरता को हटा देगा।

— स्वेन

अगर मेरे स्थानीय लोगों की composer.lockइसमें निर्भरता थी (और संभवतः गैर-देव संकुल के संस्करणों को प्रभावित किया) तो मैं इसे अपडेट करना चाहूंगा कि यह कैसे उत्पादन में होगा। यह आपको composer install --no-devउत्पादन में चलाने के लिए भी मजबूर composer installकरेगा , क्योंकि त्रुटि होगी। तकनीकी रूप से मुझे लगता है कि आप सही हैं; इसकी आवश्यकता नहीं है, लेकिन यह सुरक्षा का एक अतिरिक्त स्तर है, जो मुझे पसंद है।

— dave1010

ठीक है, डेमो परिदृश्य: अपनी एप्लिकेशन आवश्यक है dev/toolऔर prod/lib:~1.0। नवीनतम ठेस / परिवाद 1.3 है, लेकिन देव / उपकरण की भी आवश्यकता है prod/lib:1.1.*। परिणाम: आप संस्करण 1.1.9 (1.1.x शाखा में नवीनतम) स्थापित करेंगे और अपने विकास के दौरान इसका उपयोग करेंगे। मैं कहूंगा कि यह सिर्फ अपडेट करने के लिए सुरक्षित नहीं है --no-dev, इस प्रकार नवीनतम ठेस / परिवाद 1.3 शामिल है और परीक्षण के बिना सब कुछ काम करता है। और शायद परीक्षण देव / उपकरण की कमी के कारण असंभव है। मुझे लगता है कि क्योंकि उत्पादन में देव / उपकरण की आवश्यकता नहीं है, इसे रोल आउट नहीं किया जाना चाहिए, लेकिन सॉफ्टवेयर को 1.1.9 का उपयोग करना चाहिए।

— स्वेन

यदि आप उपयोग कर रहे हैं --no-devतो आपको इसका स्थानीय स्तर पर परीक्षण करने की आवश्यकता है, जैसा कि मैंने उत्तर में बताया है। मैं अभी भी --no-devहालांकि सभी का उपयोग नहीं करने की सलाह दूंगा।

— डेव 1010

तो मूल रूप से आप यह सुझाव देते हैं: composer updateफिर कुछ विकास करते हैं composer update --no-dev, फिर करते हैं , फिर रिलीज़ परीक्षण करते हैं, फिर उत्पादन और करने के लिए धक्का देते हैं composer install --no-dev। दो समस्याएं: 1. मैं देव निर्भरता के बिना रिलीज का परीक्षण नहीं कर सकता, और 2. मैं उत्पादन में उदाहरण के लिए स्थापित नहीं कर सकता।

— स्वेन

Answer 4

उत्पादन सर्वर पर मैं नाम बदलने vendorके लिए vendor-<datetime>, और तैनाती के दौरान दो विक्रेता dirs होगा।

एक HTTP कुकी मेरे सिस्टम को नए विक्रेता को चुनने का कारण बनता है autoload.php, और परीक्षण के बाद मैं भविष्य के सभी अनुरोधों के लिए पुराने विक्रेता dir को अक्षम करने के लिए उनके बीच पूरी तरह से परमाणु / त्वरित स्विच करता हूं, फिर मैं कुछ दिनों बाद पिछले dir को हटा देता हूं।

यह मैं अपाचे / php में उपयोग कर रहा है फाइलसिस्टम कैश की वजह से किसी भी समस्या से बचा जाता है, और किसी भी सक्रिय PHP कोड को पिछले विक्रेता डायर का उपयोग जारी रखने की अनुमति देता है।

---

इसके खिलाफ सिफारिश करने वाले अन्य उत्तरों के बावजूद, मैं व्यक्तिगत रूप composer installसे सर्वर पर चलता हूं , क्योंकि यह मेरे स्टेजिंग क्षेत्र (मेरे लैपटॉप पर एक वीएम) से rsync से तेज है।

मैं उपयोग करता हूं --no-dev --no-scripts --optimize-autoloader। यह जाँचने के लिए कि आपके पर्यावरण पर यह उचित है, आपको प्रत्येक के लिए डॉक्स पढ़ना चाहिए।

Answer 5

मुझे लगता है कि प्रक्रिया को स्वचालित करना बेहतर है:

अपनी git रिपॉजिटरी में कंपोज़र.लोक फ़ाइल जोड़ें, यह सुनिश्चित करें कि आप रिलीज़ होने पर कंपोज़र का उपयोग करें। कोई इंस्टॉलेशन -no-dev नहीं है , लेकिन देव मशीन में आप बिना किसी चिंता के किसी भी कंपोज़र कमांड का उपयोग कर सकते हैं, यह प्रोडक्शन में नहीं जाएगा, उत्पादन लॉक फ़ाइल में इसकी निर्भरता को आधार देगा।

सर्वर पर आप इस विशिष्ट संस्करण या लेबल की जांच करते हैं, और ऐप को बदलने से पहले सभी परीक्षणों को चलाते हैं, यदि परीक्षण पास होते हैं तो आप तैनाती जारी रखते हैं।

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

इसे स्वचालित करें और बाकी को भूल जाएं, बीयर पीएं :-)

पुनश्च: @ @ टिप्पणी में bellow के रूप में, एक अच्छा विचार नहीं है, ताकि composer.lock फ़ाइल को चेकआउट न किया जाए, क्योंकि यह संगीतकार को काम को संगीतकार अद्यतन के रूप में स्थापित करेगा।

आप उस स्वचालन को http://deployer.org/ से कर सकते हैं । यह एक सरल उपकरण है।

Comments

नहीं करने और बाहर की जाँच की तरह कार्य composer.lockकरेगा । तो आप जिन संस्करणों को तैनात करते हैं, वे आपके साथ विकसित नहीं होते हैं। यह परेशानी उत्पन्न करने की संभावना है (और ऐसा ही हाल ही में हल किए गए सुरक्षा मुद्दे के प्रकाश में "प्रतिस्थापित" के साथ संगीतकार में)। आपको यह सत्यापित करने के बिना अप्रयुक्त चलना चाहिए कि यह कुछ भी नहीं तोड़ता है। composer installcomposer updatecomposer update

— स्वेन

@ इस तरह से एक ही टिप्पणी में एक सुझाव है कि तैनाती से पहले स्वचालित रूप से यूनिट परीक्षण चलाने के लिए। लेकिन आप सही कह रहे हैं, वैसे भी कंपोजर.लोक फ़ाइल को बेहतर रखना है।

— गियोवन्नी सिल्वा

अब केवल एक चीज आपको समझानी होगी: आप PHPUnit जैसी देव निर्भरता के बिना सर्वर पर परीक्षण कैसे चलाते हैं?

— स्वेन

बहुत अच्छा होगा, अगर निर्भरता, परीक्षण और परिनियोजन को एक साथ एक उपकरण में रखा गया था, जैसे जावा ग्रैडल या एसबीटी या यहां तक ​​कि मावेन (मावेन इतना अच्छा नहीं है)। एक PHP उपकरण जो संगीतकार फ़ापुनिट और परिनियोजन कार्य को एक साथ करता है। या यहां तक ​​कि एक ग्रेडल या स्काला एसबीटी प्लग इन चीजों को बनाने के लिए, क्योंकि वे अज्ञेय निर्मित उपकरण हैं, प्लगइन यहां तक ​​कि जावास्क्रिप्ट को कम करने और सास को संकलित करने, सीएसएस को कम करने जैसी परिसंपत्तियों के साथ काम कर सकता है। किसी को कुछ पता है?

— जियोवानी सिल्वा

बेशक यह सर्वर में वास्तविक वातावरण का परीक्षण करने के लिए किया जाता है, लेकिन साइट vhost में प्रत्यक्ष नहीं है, आप इसे एक अलग अस्थायी फ़ोल्डर में कर सकते हैं और परिणाम को सफल होने पर vhost पर ले जा सकते हैं

— Giovanni Silva