วิธีการปรับใช้อย่างถูกต้องเมื่อใช้สวิตช์การพัฒนา / การผลิตของนักแต่งเพลง

180

นักแต่งเพลงมีตัวเลือกในการโหลดการอ้างอิงหลายอย่างเท่านั้นในขณะที่อยู่ในการพัฒนาดังนั้นเครื่องมือจะไม่ถูกติดตั้งในการผลิต (บนเซิร์ฟเวอร์สด) นี่คือ (ในทางทฤษฎี) มีประโยชน์มากสำหรับสคริปต์ที่ใช้ในการพัฒนาเท่านั้นเช่นการทดสอบเครื่องมือข้อมูลปลอมเครื่องมือดีบั๊กและอื่น ๆ

วิธีที่จะไปคือการเพิ่มrequire-devบล็อกเพิ่มเติมด้วยเครื่องมือที่คุณต้องการใน dev:

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

และจากนั้น (ในทางทฤษฎี) โหลดการพึ่งพาเหล่านี้ผ่าน

composer install --dev

ปัญหาและคำถาม:

นักแต่งเพลงได้เปลี่ยนพฤติกรรมของinstallและupdateอย่างมากในปี 2013 require-devตอนนี้ - ติดตั้งตามค่าเริ่มต้น (!) อย่าลังเลที่จะสร้าง composer.json ด้วยrequire-devบล็อกและดำเนินการcomposer installในการทำซ้ำ

ในฐานะที่เป็นวิธีที่ได้รับการยอมรับมากที่สุดในการใช้งานคือการผลักนักแต่งเพลงล็อค (ที่เก็บการตั้งค่าผู้แต่งปัจจุบันของคุณ) จากนั้นทำcomposer installบนเซิร์ฟเวอร์การผลิตสิ่งนี้จะติดตั้งสิ่งที่กำลังพัฒนาด้วย

เป็นวิธีที่ถูกต้องในการปรับใช้นี้ โดยไม่ต้องติดตั้งการพึ่งพา -dev คืออะไร

_{หมายเหตุ: ฉันพยายามสร้าง Q / A แบบบัญญัติขึ้นที่นี่เพื่อชี้แจงการปรับใช้นักแต่งเพลงแปลก ๆ รู้สึกอิสระที่จะแก้ไขคำถามนี้}

php deployment composer-php

— Sliq
แหล่งที่มา

@ ทั้งหมด: ไม่ทราบว่าความโปรดปรานอยู่ที่ไหน :( ฉันจะเริ่มต้นวิธีการอื่น

— Sliq

1

หากคุณไม่ได้ให้รางวัลอย่างจริงจังและไม่มีคำตอบใดที่จะได้รับการยอมรับหรือเพิ่มขึ้นมากจนเกินไปไม่มีใครได้รับรางวัล

— Sven

2

โดยส่วนตัวแล้วฉันไม่ชอบวิธีการนี้เลย composer.lockไม่ควรที่จะเพิ่มเข้ามาใน repo Git ไม่เคย แนวทางที่ถูกต้องคือการใช้การอัปเดตผู้แต่งเกี่ยวกับการจัดเตรียมแล้วซิงค์ไฟล์เข้ากับการผลิต (หากทุกอย่างทำงานได้แน่นอน) การจัดเตรียมจะต้องเป็นสำเนาที่แน่นอนของสภาพแวดล้อมการผลิต ควรเป็นส่วนหนึ่งของcomposer.lock .gitignore

— คำนาม

6

ผู้แต่งมีการรวมอยู่ใน CSV ของคุณอย่างแน่นอน !!! คุณแน่ใจได้อย่างไรว่าทุกคนใช้เวอร์ชั่นเดียวกัน? ดังนั้นอย่ารวมผู้แต่งล็อคจาก CSV ของคุณ !!!

— Tobias Gaertner

3

@TobiasGaertner ฉันคิดว่าคุณหมายถึง VCS (รุ่นซอฟต์แวร์ควบคุม) แต่มิฉะนั้นคุณกำลังถูกต้องและสอดคล้องกับโครงการของคำแนะนำอย่างเป็นทางการ

— Xiong Chiamiov

327

ทำไม

มี IMHO เป็นเหตุผลที่ดีที่นักแต่งเพลงจะใช้--devแฟลกตามค่าเริ่มต้น (ในการติดตั้งและอัปเดต) ทุกวันนี้ นักแต่งเพลงส่วนใหญ่ทำงานในสถานการณ์ที่เป็นพฤติกรรมที่ต้องการ:

เวิร์กโฟลว์นักแต่งเพลงพื้นฐานมีดังนี้:

โปรเจ็กต์ใหม่เริ่มทำงาน: composer.phar install --dev, json และล็อกไฟล์ถูกคอมมิตกับ VCS
นักพัฒนาอื่น ๆ เริ่มต้นการทำงานในโครงการ: เช็คเอาต์ของ VCS composer.phar install --devและ
นักพัฒนาเพิ่มการพึ่งพา: 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ค่าสถานะโดยเฉพาะเมื่อจำนวนนักพัฒนาที่ทำงานในโครงการเพิ่มขึ้น

การปรับใช้การผลิต

วิธีที่ถูกต้องในการปรับใช้นี้โดยไม่ต้องติดตั้งการพึ่งพา "dev" คืออะไร?

ดีcomposer.jsonและcomposer.lockไฟล์ควรมุ่งมั่นที่จะ VCS อย่าละเว้นcomposer.lockเนื่องจากมีข้อมูลสำคัญเกี่ยวกับแพ็คเกจเวอร์ชันที่ควรใช้

เมื่อทำการปรับใช้การผลิตคุณสามารถส่งการ--no-devตั้งค่าสถานะไปยังนักแต่งเพลง:

composer.phar install --no-dev

composer.lockไฟล์อาจมีข้อมูลเกี่ยวกับการพัฒนาแพคเกจ ไม่เป็นไร --no-devตั้งค่าสถานะจะทำให้แน่ใจว่าแพ็คเกจ dev เหล่านั้นไม่ได้ติดตั้ง

เมื่อฉันพูดว่า "การปรับใช้การผลิต" ฉันหมายถึงการปรับใช้ที่มุ่งใช้ในการผลิต ฉันไม่ได้โต้เถียงว่าcomposer.phar installควรทำ a บนเซิร์ฟเวอร์ที่ใช้งานจริงหรือบนเซิร์ฟเวอร์จัดเตรียมที่สามารถตรวจสอบสิ่งต่าง ๆ ได้ นั่นไม่ใช่ขอบเขตของคำตอบนี้ ฉันแค่ชี้ให้เห็นวิธีการcomposer.phar installโดยไม่ต้องติดตั้งการพึ่งพา "dev"

offtopic

--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

หาก codebase ของคุณรองรับคุณสามารถสลับออกได้ --optimize-autoloader--classmap-authoritativeสำหรับ ข้อมูลเพิ่มเติมที่นี่

— Jasper N. Brouwer
แหล่งที่มา

5

ฉันเห็นด้วยกับสิ่งที่ส่วนใหญ่พูดด้วยข้อยกเว้นหนึ่งข้อ "การติดตั้งผู้แต่ง - no-dev" ควรดำเนินการในสภาพแวดล้อมการจัดเตรียมเท่านั้นและสภาพแวดล้อมนั้นควรได้รับการพิจารณาว่าไม่เปลี่ยนรูป ฉันไม่ต้องการดาวน์โหลดการพึ่งพาโดยตรงที่เซิร์ฟเวอร์การผลิตของฉันและไม่ต้องดูตัวอย่าง / การแสดงละคร นั่นเป็นเพียงข้อควรระวังอีกเล็กน้อย

— ขยายขีดความสามารถ

3

@Scalable: แม้ว่าฉันจะเห็นด้วยกับคุณ (และ Sven ครอบคลุมคำตอบของเขาอย่างนี้) แต่นั่นไม่ใช่ขอบเขตของคำตอบของฉันและไม่ใช่สิ่งที่ฉันหมายถึงกับ "การปรับใช้การผลิต" ฉันได้เพิ่มย่อหน้าเพื่อให้ชัดเจน

— Jasper N. Brouwer

5

ที่จริงฉันคิดว่าค่าเริ่มต้นควรเป็นตัวเลือกที่อันตรายน้อยกว่า การสร้าง - เริ่มต้นและการติดตั้งผู้แต่งในการผลิตอาจเป็นอันตรายถึงชีวิตได้

— เฮ็กเตอร์ Ordonez

3

--optimize-autoloaderจุดที่ดีในการ พิจารณาด้วย--classmap-authoritative- จากเอกสารประกอบที่นี่ที่getcomposer.org/doc/03-cli.mdคุณสามารถเห็นสิ่งนี้: "คลาส Autoload จากคลาสแม็พเท่านั้นโดยปริยายจะเปิดใช้งาน --optimize-autoloader โดยปริยาย" เพื่อให้คุณสามารถใช้ถ้าคุณรู้ว่าคลาส "เป็น นั่น "ซึ่งอาจจะเกิดขึ้นในสภาพแวดล้อมการทำงานของคุณเว้นแต่คุณจะสร้างคลาสแบบไดนามิก

— Xavi Montero

6

คำตอบที่ดีฉันขอแนะนำให้เพิ่มoptimize-autoloaderโดยตรงในcomposer.json:{"config": { "optimize-autoloader": true } }

— Yvan

79

ที่จริงแล้วฉันขอแนะนำให้ติดตั้งการพึ่งพาบนเซิร์ฟเวอร์ที่ใช้งานจริง

คำแนะนำของฉันคือการเช็คเอาต์รหัสบนเครื่องใช้งานติดตั้งการอ้างอิงตามที่ต้องการ (ซึ่งรวมถึงการไม่ติดตั้ง dev dependencies หากรหัสไปใช้งานจริง) จากนั้นย้ายไฟล์ทั้งหมดไปยังเครื่องเป้าหมาย

ทำไม?

บนโฮสติ้งที่ใช้ร่วมกันคุณอาจไม่สามารถเข้าถึงบรรทัดคำสั่งได้
แม้ว่าคุณจะทำเช่นนั้น PHP อาจถูก จำกัด ในเรื่องของคำสั่งหน่วยความจำหรือการเข้าถึงเครือข่าย
เครื่องมือเก็บข้อมูล CLI (Git, Svn) มีแนวโน้มที่จะไม่ได้รับการติดตั้งซึ่งจะล้มเหลวหากไฟล์ล็อคของคุณได้บันทึกการพึ่งพาการชำระเงินการกระทำบางอย่างแทนที่จะดาวน์โหลดที่กระทำเป็น ZIP (คุณใช้ --prefer-source หรือ Composer ไม่มีวิธีอื่นในการรับรุ่นนั้น)
หากเครื่องที่ใช้งานของคุณเป็นเหมือนเซิร์ฟเวอร์ทดสอบขนาดเล็ก (คิดว่าเป็นอินสแตนซ์ขนาดเล็กของ Amazon EC2) อาจมีหน่วยความจำไม่เพียงพอที่จะทำการติดตั้ง composer install
ในขณะที่ผู้แต่งพยายามที่จะไม่หยุดพักคุณรู้สึกอย่างไรที่ลงท้ายด้วยเว็บไซต์การผลิตที่เสียบางส่วนเนื่องจากการพึ่งพาแบบสุ่มบางอย่างไม่สามารถโหลดได้ในระหว่างขั้นตอนการติดตั้งนักแต่งเพลง

เรื่องสั้นสั้น: ใช้นักแต่งเพลงในสภาพแวดล้อมที่คุณสามารถควบคุมได้ เครื่องพัฒนาของคุณมีคุณสมบัติเพราะคุณมีทุกสิ่งที่จำเป็นสำหรับการใช้งาน Composer

วิธีที่ถูกต้องในการปรับใช้นี้โดยไม่ต้องติดตั้งการพึ่งพา -dev คืออะไร?

คำสั่งที่ใช้คือ

composer install --no-dev

สิ่งนี้จะทำงานในสภาพแวดล้อมใด ๆ ไม่ว่าจะเป็นเซิร์ฟเวอร์ที่ใช้งานจริงหรือเครื่องใช้งานหรือเครื่องพัฒนาที่ควรทำการตรวจสอบครั้งสุดท้ายเพื่อค้นหาว่าข้อกำหนด dev ใด ๆ ที่ใช้ไม่ถูกต้องสำหรับซอฟต์แวร์จริง

คำสั่งจะไม่ติดตั้งหรือถอนการติดตั้งข้อกำหนด dev ที่ประกาศในไฟล์ composer.lock

หากคุณไม่คิดที่จะปรับใช้ส่วนประกอบซอฟต์แวร์การพัฒนาบนเซิร์ฟเวอร์ที่ใช้งานจริงการรันcomposer installจะทำงานเหมือนเดิม แต่เพียงเพิ่มจำนวนไบต์ที่เลื่อนไปมาและสร้างการประกาศอัตโนมัติขนาดใหญ่ขึ้น

— สเวน
แหล่งที่มา

14

ขั้นตอนการทำงานที่น่าสนใจ แต่มีขนาดใหญ่Con : คลังไม่ควรประกอบด้วยโฟลเดอร์ผู้ขาย / เนื้อหาเอง (งบอย่างเป็นทางการในหน้านักแต่งเพลง) ดังนั้นพวกเขาจะไม่ได้รับการผลักดันโดยตรงกับการผลิตในการปรับใช้ Git-based (ซึ่งเป็น AFAIK มาตรฐานทั่วไป ช่วยแก้ให้ด้วยนะถ้าฉันผิด). ดังนั้นโดยทั่วไปทางออกข้างต้นจะใช้ได้เฉพาะกับ FTP แบบเก่าเท่านั้น กรุณาพูดคุยเรื่องนี้ต่อไป ...

— Sliq

17

เวิร์กโฟลว์ที่แนะนำของฉันไม่ได้รวมการกดรหัสผ่าน GIT ไปยังเซิร์ฟเวอร์ที่ใช้งานจริง ในความเป็นจริงฉันอยากจะแนะนำเพราะการทำเช่นนั้นจะบังคับให้คุณติดตั้งการพึ่งพานักแต่งเพลงบนเซิร์ฟเวอร์การผลิตซึ่งสามารถทำให้เกิดปัญหาจำนวนเท่าใดก็ได้ หากคุณต้องการให้การปรับใช้ของคุณทำงานได้อย่างราบรื่นคุณต้องรวบรวมรหัสทั้งหมดที่จำเป็นในการเรียกใช้แอปพลิเคชันก่อนที่คุณจะทำลายเวอร์ชันปัจจุบันและแทนที่ ไม่ชอบ FTP ใช่ไหม RSync ผ่าน SSH แล้วสลับรุ่นโดยพลิก symlink แต่คุณสามารถผลักดันชำระเงินและติดตั้งโปรแกรมแต่งเพลงได้ถ้าคุณต้องการ

— สเวน

2

@Panique: ฉันเพิ่งเห็นส่วนหนึ่งของความคิดเห็นของคุณและฉันต้องตอบ: "ผลักให้ผลิตในการปรับใช้ git (ซึ่งเป็น afaik มาตรฐานทั่วไปให้แก้ไขฉันถ้าฉันผิด)" - ไม่นี้ ไม่ใช่มาตรฐานทั่วไป มันเป็นวิธีเดียวที่จะทำ

— Sven

1

ทีมของฉันได้รวมสิ่งนี้ไว้ในกระบวนการทำงานด้วยความสำเร็จที่ยิ่งใหญ่ เรามีเครื่องสร้าง (เจนกินส์ของหลักสูตร) ซึ่ง: 1) ตรวจสอบจาก SC 2) รันการติดตั้งนักแต่งเพลง / ปรับปรุง 3) ทำงานทดสอบหน่วย 4) ลบการพึ่งพา dev 5) สร้างไฟล์ phar ( app-1.34.pharฯลฯ ) มีกลไกแยกต่างหากที่ได้รับการแจ้งเตือนและตัดสินใจว่าจะคว้าไฟล์นั้นเมื่อไรจะถ่ายโอนไปที่ใดแล้วจะทำอย่างไรกับมัน บางทีมเลือกที่จะให้ phar แตกออกมาเมื่อมันอยู่บนเซิร์ฟเวอร์และบางทีมก็เรียกใช้ตามที่เป็นอยู่ มันให้ความมั่นใจอย่างมากกับเสถียรภาพและความสามารถในการทำซ้ำของ deploys ของเรา

— Josh Johnson

3

ฉันเห็นด้วย 100% กับคำตอบนี้ นักแต่งเพลงไม่ควรติดตั้งบนเซิร์ฟเวอร์การปรับใช้หรือ git เซิร์ฟเวอร์ Deployment / Intergration อย่างต่อเนื่องนั้นควรจะจัดการแหล่งที่มาและการดึงข้อมูลที่อ้างอิง: git pull> การติดตั้งผู้แต่ง> ปรับใช้

— Eric MORAND

4

ตอนนี้require-devถูกเปิดใช้งานโดยค่าเริ่มต้นสำหรับการพัฒนาท้องถิ่นที่คุณสามารถทำได้composer installและcomposer updateไม่มี--devตัวเลือก

เมื่อคุณต้องการปรับใช้กับการผลิตคุณจะต้องแน่ใจว่าcomposer.lockไม่มีแพ็คเกจที่มาจากrequire-devที่มาจาก

คุณสามารถทำได้ด้วย

composer update --no-dev

เมื่อคุณได้รับการทดสอบในประเทศกับคุณสามารถปรับใช้ทุกอย่างเพื่อการผลิตและติดตั้งอยู่บนพื้นฐานของ--no-dev composer.lockคุณจำเป็นต้องมี--no-devตัวเลือกอีกครั้งที่นี่มิฉะนั้นนักแต่งเพลงจะบอกว่า"แฟ้มล็อคไม่ได้มีข้อมูลต้อง-dev"

composer install --no-dev

หมายเหตุ:ระวังสิ่งที่มีศักยภาพในการแนะนำความแตกต่างระหว่าง dev และการผลิต! โดยทั่วไปฉันพยายามหลีกเลี่ยงความต้องการ -dev ที่เป็นไปได้รวมถึงเครื่องมือ dev ไม่ได้เป็นค่าใช้จ่ายใหญ่

— dave1010
แหล่งที่มา

1

นี่เป็นรายละเอียดที่ไม่ถูกต้องจริงๆ ไม่จำเป็นต้องตรวจสอบcomposer.lockการพึ่งพา dev คุณเพียงแค่เรียกใช้composer install --no-devและคุณจะได้รับการติดตั้งปกติเท่านั้นที่จริงแล้วนักแต่งเพลงจะลบการอ้างอิง dev ใด ๆ ในขั้นตอนนี้ด้วย

— สเวน

หากท้องถิ่นของฉันcomposer.lockมีการพึ่งพา dev ในนั้น (และอาจส่งผลกระทบต่อเวอร์ชันของแพ็คเกจที่ไม่ใช่ dev) ดังนั้นฉันต้องการอัปเดตเพื่อให้สะท้อนว่ามันจะใช้งานอย่างไร นอกจากนี้ยังบังคับให้คุณทำงานcomposer install --no-devในการผลิตตามที่composer installจะผิดพลาด ในทางเทคนิคฉันคิดว่าคุณพูดถูก ไม่จำเป็นต้องใช้สิ่งนี้ แต่เป็นระดับความปลอดภัยเพิ่มเติมที่ฉันชอบ

— dave1010

ตกลงสาธิตสถานการณ์: app ของคุณต้องการและdev/tool prod/lib:~1.0Prod / lib ใหม่ล่าสุดคือ 1.3 แต่ต้องการ dev / tool prod/lib:1.1.*ด้วย ผลลัพธ์: คุณจะติดตั้งเวอร์ชัน 1.1.9 (สาขาใหม่ล่าสุดของสาขา 1.1.x) และใช้ในระหว่างการพัฒนาของคุณ ฉันจะบอกว่ามันไม่ปลอดภัยเพียงแค่อัปเดต--no-devดังนั้นรวม prod / lib 1.3 ใหม่ล่าสุดและสมมติว่าทุกอย่างทำงานได้โดยไม่ต้องทดสอบ และการทดสอบอาจเป็นไปไม่ได้เพราะไม่มีเครื่องมือ / dev ฉันจะสมมติว่าเนื่องจาก dev / เครื่องมือไม่จำเป็นในการผลิตจึงไม่ควรถูกนำออกใช้ แต่ซอฟต์แวร์ต้องใช้ prod / lib 1.1.9 ในตอนนั้น

— สเวน

หากคุณกำลังใช้งานอยู่--no-devคุณต้องทดสอบในพื้นที่ดังที่ฉันได้กล่าวไว้ในคำตอบ ฉันยังคงแนะนำไม่ได้ใช้--no-devเลย

— dave1010

ดังนั้นโดยทั่วไปคุณแนะนำนี้composer updateแล้วจะพัฒนาบางส่วนแล้วทำแล้วทำทดสอบปล่อยแล้วผลักดันการผลิตและการทำcomposer update --no-dev composer install --no-devปัญหาสองประการ: 1. ฉันไม่สามารถทดสอบการเปิดตัวโดยไม่ต้องพึ่งพาการพึ่งพา dev และ 2. ฉันไม่สามารถติดตั้งด้วยเช่น Git ในการผลิต

— สเวน

3

บนเซิร์ฟเวอร์ที่ใช้งานจริงฉันเปลี่ยนชื่อvendorเป็นvendor-<datetime>และระหว่างการปรับใช้จะมีผู้จำหน่ายสองราย

คุกกี้ HTTP ทำให้ระบบของฉันเลือกผู้ขายรายใหม่ autoload.phpและหลังจากการทดสอบฉันทำการสลับอะตอมมิก / ทันทีระหว่างพวกเขาเพื่อปิดใช้งาน dir ผู้ขายเก่าสำหรับคำขอในอนาคตทั้งหมดจากนั้นฉันจะลบ dir ก่อนหน้านี้ในอีกไม่กี่วันต่อมา

สิ่งนี้จะช่วยหลีกเลี่ยงปัญหาใด ๆ ที่เกิดจากแคชของระบบไฟล์ที่ฉันใช้ใน apache / php และยังอนุญาตให้ใช้โค้ด PHP ใด ๆ

แม้จะมีคำตอบอื่น ๆ ที่แนะนำให้ต่อต้าน แต่ฉันก็วิ่งเอง composer installบนเซิร์ฟเวอร์เนื่องจากนี่เร็วกว่า rsync จากพื้นที่จัดเตรียมของฉัน (VM บนแล็ปท็อปของฉัน)

--no-dev --no-scripts --optimize-autoloaderฉันใช้ คุณควรอ่านเอกสารสำหรับแต่ละคนเพื่อตรวจสอบว่าสิ่งนี้เหมาะสมกับสภาพแวดล้อมของคุณหรือไม่

— Abhi Beckert
แหล่งที่มา

2

ฉันคิดว่าเป็นกระบวนการอัตโนมัติที่ดีกว่า:

เพิ่มไฟล์ composer.lock ในพื้นที่เก็บข้อมูล git ของคุณตรวจสอบให้แน่ใจว่าคุณใช้composer.phar ติดตั้ง - no-devเมื่อคุณปล่อย แต่ในเครื่อง dev คุณคุณสามารถใช้คำสั่งแต่งโดยไม่ต้องกังวลนี้จะไม่ไปผลิต การผลิตจะยึดตามการอ้างอิงในไฟล์ล็อค

บนเซิร์ฟเวอร์คุณชำระเงินรุ่นหรือป้ายกำกับที่เฉพาะเจาะจงนี้และเรียกใช้การทดสอบทั้งหมดก่อนที่จะแทนที่แอปหากการทดสอบผ่านคุณดำเนินการปรับใช้

หากการทดสอบขึ้นอยู่กับการพึ่งพา dev เนื่องจากผู้แต่งไม่มีการพึ่งพาขอบเขตการทดสอบโซลูชันที่ไม่หรูหราสามารถทำการทดสอบด้วยการติดตั้ง dev dependencies ( ติดตั้ง composer.phar ) ให้ลบไลบรารีผู้ขายออกติดตั้ง composer.phar - ไม่มี-devอีกครั้งนี่จะใช้การอ้างอิงแคชดังนั้นจึงเร็วขึ้น แต่นั่นเป็นแฮ็คถ้าคุณรู้แนวคิดของขอบเขตในเครื่องมือสร้างอื่น ๆ

เป็นแบบอัตโนมัติและลืมส่วนที่เหลือไปดื่มเบียร์ :-)

PS .: ในความคิดเห็นร้อง @Sven ไม่ใช่ความคิดที่ดีที่จะไม่เช็คเอาท์ไฟล์ composer.lock เพราะมันจะทำให้การติดตั้งนักแต่งเพลงทำงานเป็นการอัพเดทผู้แต่ง

คุณสามารถทำได้โดยอัตโนมัติด้วยhttp://deployer.org/มันเป็นเครื่องมือง่ายๆ

— จิโอวานนี่ซิลวา
แหล่งที่มา

2

ไม่ได้กระทำและการตรวจสอบออกมาcomposer.lockจะทำให้การกระทำเช่นcomposer install composer updateดังนั้นเวอร์ชันที่คุณปรับใช้จึงไม่ใช่เวอร์ชันที่คุณพัฒนา สิ่งนี้มีแนวโน้มที่จะสร้างปัญหา (และอื่น ๆ ในแง่ของปัญหาความปลอดภัยที่เพิ่งแก้ไขเมื่อเร็ว ๆ นี้ด้วย "แทนที่" ในนักแต่งเพลง) คุณไม่ควรวิ่งcomposer updateโดยไม่ต้องตรวจสอบว่าไม่ได้ทำลายอะไร

— Sven

1

@Sven นี่เป็นวิธีที่แนะนำในความคิดเห็นเดียวกันเพื่อเรียกใช้การทดสอบหน่วยโดยอัตโนมัติก่อนการปรับใช้ แต่คุณพูดถูกก็ควรเก็บไฟล์ composer.lock ต่อไป

— Giovanni Silva

ตอนนี้มีเพียงสิ่งเดียวที่คุณต้องอธิบาย: คุณเรียกใช้การทดสอบบนเซิร์ฟเวอร์โดยไม่ต้องพึ่งพาการอ้างอิงเช่น PHPUnit ได้อย่างไร

— สเวน

จะดีมากถ้าการอ้างอิงการทดสอบและการปรับใช้ถูกวางไว้ด้วยกันในเครื่องมือเดียวเช่น Java Gradle หรือ SBT หรือแม้แต่ Maven (Maven ไม่ดีนัก) เครื่องมือ PHP หนึ่งที่ทำให้ phpunit ผู้แต่งและการปรับใช้ทำงานร่วมกันได้ หรือแม้แต่ปลั๊กอิน Gradle หรือ Scala SBT เพื่อสร้างสิ่งนี้เนื่องจากพวกเขาเป็นเครื่องมือสร้างที่ไม่เชื่อเรื่องพระเจ้าปลั๊กอินก็สามารถทำงานร่วมกับสินทรัพย์เช่นการลดจาวาสคริปต์และการรวบรวม sass, ลด css มีคนรู้อะไรไหม

— Giovanni Silva

1

แน่นอนว่าจะทำในเซิร์ฟเวอร์เพื่อทดสอบสภาพแวดล้อมจริง แต่ไม่ใช่โดยตรงในไซต์ vhost คุณสามารถทำได้ในโฟลเดอร์ชั่วคราวที่แยกจากกันและย้ายผลลัพธ์ไปยัง vhost เมื่อประสบความสำเร็จ

— Giovanni Silva