เป็นความคิดที่ดีหรือไม่ที่จะติดตั้ง Mercurial บนเซิร์ฟเวอร์ของคุณและดึงข้อมูล hg ไปใช้งาน?

ฉันเพิ่งเริ่มงานใหม่เมื่อเดือนที่แล้วและดูเหมือนว่าพวกเขาไม่มีการควบคุมซอร์สโค้ดของพวกเขา พวกเขาพึ่งพาการสำรองข้อมูลผู้ให้บริการโฮสต์ของพวกเขาใช้เวลาสำหรับพวกเขา

หลังจากพูดคุยกันเล็กน้อยฉันมั่นใจว่าเจ้านายของฉันว่าเราควรใช้การควบคุมแหล่งที่มาอย่างแน่นอนและหลังจากที่ฉันได้สัมมนาสั้น ๆ เกี่ยวกับเรื่องนี้ทีมทั้งหมดก็อยู่บนเรือ พวกเขารัก Mercurial

ดังนั้นตอนนี้นี่คือวิธีที่เราทำงาน:

º----------BitBucket
º---------/
º--------/

ตัวฉันและนักพัฒนาอื่น ๆhg pullจาก BitBucket ทำการเปลี่ยนแปลงของเราจากนั้นhg pushเป็น BitBucket

ตอนนี้สำหรับการปรับใช้บางคนจะต้อง FTP ไฟล์ล่าสุดไปยังเซิร์ฟเวอร์ที่ใช้งานจริง

ฉันคิดว่าจะติดตั้ง Mercurial บนเซิร์ฟเวอร์ของเราและใช้hg clone(ต่อมาhg pull) เพื่อปรับปรุงเวอร์ชันให้ทันสมัยอยู่เสมอ

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

นี่เป็นความคิดที่ดีหรือไม่? ข้อผิดพลาดที่อาจเกิดขึ้นที่ฉันอาจไม่เห็น? มีใครที่นี่ทำอะไรที่คล้ายกันบ้างไหม? คุณจะปรับใช้แอพพลิเคชันกรอบงาน PHP ขนาดใหญ่ได้อย่างไร (เรากำลังใช้ Moodle)

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

ปัญหาเดียวอาจเกิดขึ้นเมื่อคุณมีข้อมูลที่ละเอียดอ่อนในฐานรหัสของคุณ (เช่นคีย์ API ฯลฯ ) ที่คุณไม่ต้องการอัปโหลดไปยังเซิร์ฟเวอร์บุคคลที่สาม (ในกรณีของคุณที่จะเป็น Bitbucket) ในกรณีนี้สคริปต์ง่าย ๆ ที่ทำงานเมื่อคุณดึงข้อมูลจากที่เก็บเพื่อเรียกคืนข้อมูลที่สำคัญในตำแหน่งที่ถูกต้องจะช่วยแก้ปัญหานั้นได้

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

วิธีการปรับใช้อะตอมมิกคือโดยใช้ symlink สร้างไดเรกทอรีที่มีไฟล์ใหม่ เมื่อทุกอย่างพร้อมเปลี่ยน symlink สำหรับไดเรกทอรีที่ใช้ หากคุณรักษาเวอร์ชันเก่าไว้รอบตัวคุณคุณสามารถย้อนกลับได้อย่างง่ายดาย

ความเป็นไปได้อื่น(ในความคิดของฉันดีกว่า) : ใช้เซิร์ฟเวอร์การสร้าง / เซิร์ฟเวอร์รวมอย่างต่อเนื่อง

คำอธิบายสั้น ๆ : นี่คือเซิร์ฟเวอร์ (สามารถอยู่ในบ้านไม่จำเป็นต้องอยู่บนอินเทอร์เน็ต) ที่คุณตั้งค่าเพื่อตรวจสอบที่เก็บข้อมูลของคุณและเมื่อใดก็ตามที่มีการเปลี่ยนแปลงใหม่ใน repos เซิร์ฟเวอร์จะสร้างรหัสของคุณ( AFAIK นี้ไม่จำเป็นใน PHP)ทำการทดสอบหน่วยและปรับใช้รหัสของคุณไปยังเว็บเซิร์ฟเวอร์

สำหรับข้อมูลเพิ่มเติมตรวจสอบลิงก์เหล่านี้:

• บทความ Wikipedia เกี่ยวกับ CI
• คำถาม Stack Overflow: จุดประสงค์ของ“ Build Server” คืออะไร?

มีจำนวนมากของผลิตภัณฑ์ที่แตกต่างกันสำหรับ CI ออกมีแต่เพียงคนเดียวที่ผมเคยใช้เพื่อให้ห่างไกลTeamCity ติดตั้งง่ายมาก ... อันที่จริงแล้วมันเป็นอันแรกที่ฉันลองและฉันชอบมันมากจนติดกับมัน

ทางเลือกการแก้ปัญหาราคาถูก:

หากการตั้งค่าเซิร์ฟเวอร์บิลด์นั้นใช้ความพยายามมากเกินไปหรือหากคุณต้องการควบคุมได้มากขึ้นเมื่อมีการปรับใช้ไซต์ของคุณเพียงแค่ตั้งค่าไฟล์สคริปต์(Batch / Powershell บน Windows หรือสิ่งที่คล้ายกันบน Linux / Mac)ที่ดึง เวอร์ชันใหม่ล่าสุดจากที่เก็บของคุณและ FTP บนเซิร์ฟเวอร์ที่ใช้งานจริง

โดยพื้นฐานแล้วมันเป็นเช่นเดียวกับการสร้างเซิร์ฟเวอร์ง่ายขึ้นเท่านั้น

ไม่ว่าคุณจะแก้ปัญหาในท้ายที่สุด ... อย่าลืมทำให้มันเป็นไปโดยอัตโนมัติ!

คุณต้องการปรับใช้ด้วยการคลิกเพียงครั้งเดียว / โดยพิมพ์คำสั่งเดียวเพื่อให้ทุกคนสามารถทำได้โดยไม่ต้องรู้อะไรเป็นพิเศษและไม่ทำผิดพลาด - แม้ในกรณีที่เกิดภัยพิบัติหรือภายใต้ความเครียด

เราทำสิ่งนี้หรือสิ่งที่คล้ายกับสิ่งนี้ nonatomic @johannes กล่าวถึงมุมเป็นประเด็นหนึ่ง แต่ในแง่ความเป็นจริงมันเกิดขึ้นเร็วมากมันควรจะโอเคและมีวิธีแก้ไขปัญหานี้ในขณะที่เขาชี้ให้เห็น

อาจมีความสำคัญมากกว่า non-atomicity นี้น่าจะเป็น "คุณจัดการการปรับปรุง schema ของฐานข้อมูลได้อย่างไร" - การปรับใช้รหัสที่ไม่ดีด้วยวิธีนี้ทำให้การแก้ไขนั้นง่าย ปัญหาใหญ่คือเมื่อคุณปรับใช้การปรับปรุงที่เปลี่ยนแปลงฐานข้อมูลที่คุณต้องการย้อนกลับ หรือถ้าคุณทำการอัปเดตที่ไม่ดีและข้อมูลที่เสียหาย

ปัญหาอื่น ๆ ที่เรามีกับเครื่องมือ DCVS (ตรงข้ามกับการใช้ SVN) คือตอนนี้คุณมีสำเนาของ codebase ทั้งหมดบนเครื่องที่ผู้โจมตีอาจคว้าได้ และที่ codebase DCVS สามารถรับขนาดค่อนข้างใหญ่ซึ่งอาจมีความสำคัญถ้าคุณจ่ายสำหรับการจัดเก็บและ / หรือสำรอง เรายังคงใช้ SVN สำหรับการปรับใช้ขั้นสุดท้ายด้วยเหตุผลเหล่านี้

มันเป็นความคิดที่ดี แต่โปรดจำไว้ดังต่อไปนี้:

• พยายามอย่าคอมมิทบนเซิร์ฟเวอร์ (ถึงแม้จะหาได้ยากในบางครั้งก็ตามเช่นติดตั้งปลั๊กอินหรือเพิ่มเนื้อหาเนื้อหา)
• ใช้เซิร์ฟเวอร์ staging หรือการปรับใช้ที่เก็บรองสำหรับการทดสอบ
• ระวังเสมอว่าhg update -Cจะไม่มีผลกับการผลิต (เช่นลบไฟล์สำคัญ)
• มีการผลิตและสาขาการพัฒนาปรับใช้สาขาการผลิตเท่านั้น
• ปฏิบัติต่อสินทรัพย์เป็นการสำรองข้อมูล (เช่นรูปภาพสำหรับเนื้อหา) และละเว้นข้อมูลผู้ใช้ (เช่นไฟล์แนบ / อัพโหลดแคชเป็นต้น)
• มีhg statusเอาต์พุตแบบคลีนเสมอบนเซิร์ฟเวอร์ (ซึ่งจะช่วยให้คุณแน่ใจว่าคุณไม่สนใจสิ่งต่าง ๆ เป็นแคช)
• อย่าปรับใช้ที่เก็บในเว็บโฟลเดอร์ ใช้ symlink จากนอกพื้นที่สาธารณะ (เช่น ln -s / myrepo / src / web / public_html / myapp)
• ระวังอย่าให้ไฟล์การกำหนดค่าเวอร์ชัน (โดยเฉพาะกับรหัสผ่านฐานข้อมูลหรืออื่น ๆ )
• อย่าใช้แทนการสำรองข้อมูลการผลิตนี่คือการสำรองข้อมูลการพัฒนาสำหรับรหัสการผลิตไม่ใช่ข้อมูลการผลิต

ในที่สุดฉันคิดว่าสิ่งที่มีค่าที่สุดสำหรับการเพิ่ม DVCS ในกระบวนการปรับใช้ของคุณคือสิ่งนี้จะเพิ่มความปลอดภัยให้กับการใช้งานของคุณบางครั้งแฮกเกอร์จะฉีดโค้ดที่เป็นอันตรายลงในสิ่งของของคุณและคุณก็ไม่มีวิธีตรวจจับได้ง่าย แจกจ่ายเป็นพิเศษเนื่องจากการกระจายไปยัง VCS ทำให้ง่ายต่อการตรวจสอบความสมบูรณ์ของไฟล์ของคุณ)

ผมเคยมีบางเว็บไซต์ hacked อากาศไม่กี่ครั้งมี Mercurial ช่วยให้ผมlitterallyยกเลิกการแฮ็กนี้โดยเพียงแค่การออกhg update -Cในเซิร์ฟเวอร์ (แน่นอนคุณอาจต้องการที่จะทำhg statusและได้รับไฟล์ที่ได้รับผลกระทบในการวิเคราะห์ในภายหลัง)