การปรับใช้ Dev, Stage และ Production สำหรับเว็บไซต์ WordPress?


41

ดังนั้นฉันจึงต้องมี dev / stage / production iterations (ผ่านเซิร์ฟเวอร์ที่แยกต่างหาก) สำหรับเว็บไซต์ WordPress ฉันใช้ git ตามปกติ แต่สิ่งนี้เห็นได้ชัดว่าจะไม่ทำงานกับไซต์ WordPress เนื่องจากการพึ่งพาฐานข้อมูลหลัก การกำหนดค่าของ ... ดีเกือบทุกอย่าง

ดังนั้นคำถามของฉันคือคุณจะทำยังไง? ฉันมี Google ที่รวดเร็วและเห็นว่ามีปลั๊กอินไม่กี่นี่เป็นวิธีเดียวหรือไม่ สิ่งใดที่ทำงานได้ดีที่สุดในแง่ของการใช้งานง่ายความเร็วความน่าเชื่อถือ ui ฯลฯ


pantheon.ioมีการทดสอบและใช้ชีวิตสำหรับโดเมนเดียว พวกเขาใช้คอมไพล์สำหรับไฟล์และถ่ายโอนฐานข้อมูลระหว่างกันด้วยการคลิกเพียงครั้งเดียว ทดลองใช้ฟรีและจ่ายเฉพาะเมื่อคุณ 'สด' - youtube.com/watch?v=KpGTDeqwgX4
jgraup

คำตอบ:


27

ฉันมีเซ็ตอัพฉันค่อนข้างภูมิใจและมันทำงานได้ดีมากสำหรับทีมของฉัน

โครงสร้างทั่วไป

ฉันเก็บการติดตั้งทั้งหมดภายใต้คอมไพล์ การเปลี่ยนแปลงทั้งหมดไม่ว่าจะเป็นการอัปเดตระบบการเพิ่ม / อัปเดตปลั๊กอินการเพิ่ม / อัปเดตธีมไปตามเวิร์กโฟลว์เดียวกัน การเปลี่ยนแปลงสามารถย้อนกลับได้ทันที ฉันมีการใช้งานเซิร์ฟเวอร์ (เดสก์ทอป P4 เก่า) ที่ทำงานgitosisแต่คุณสามารถได้อย่างง่ายดายเพียงใช้ GitHub หรือgitolite ในคอมไพล์ฉันมีสองสาขา "พิเศษ" masterและdevelop(อธิบายเพิ่มเติมด้านล่าง) เซิร์ฟเวอร์การผลิตและการจัดเตรียมของฉันใช้ระบบคลาวด์

สภาพแวดล้อมการพัฒนา

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

การจัดเตรียมสภาพแวดล้อม

เมื่อความมุ่งมั่นถูกผลักจากdevelopสาขาสู่ gitosis พวกมันจะถูกปรับใช้โดยอัตโนมัติไปยังเซิร์ฟเวอร์การแสดงละครของเรา ฐานข้อมูลการแสดงละครเป็นทาสของฐานข้อมูลการผลิต

สภาพแวดล้อมการผลิต

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

ปัญหา wp-config.php

คุณต้องการแตกต่างwp-config.phpจากเซิร์ฟเวอร์หนึ่งไปอีกเซิร์ฟเวอร์ แต่คุณต้องการให้อยู่ภายใต้การควบคุมเวอร์ชัน วิธีแก้ปัญหาของฉันคือใช้.gitignoreเพื่อละเว้นwp-config.phpและเก็บเวอร์ชัน staging และ production เป็นไฟล์ที่มีชื่อต่างกัน จากนั้นในแต่ละเซิร์ฟเวอร์ผม symlink wp-config.php -> wp-config-production.phpเช่น จากนั้นผู้ใช้แต่ละคนจะรักษาฐานข้อมูลของตนเองไว้ด้วยข้อมูลประจำตัวของตนเองพร้อมการตั้งค่า wp-config.php ของตนเอง (ไม่ได้ติดตาม)

หมายเหตุอื่น ๆ

ฉันใช้Rackspace Cloudซึ่งเป็นปรากฎการณ์และราคาไม่แพง ฉันสามารถใช้เซิร์ฟเวอร์ staging และเซิร์ฟเวอร์ผลิตเหมือนกันได้ ฉันยังเขียนปลั๊กอินตอนนี้ที่ใช้ API ของพวกเขาเพื่อให้ฉันสามารถควบคุมบริการของฉันได้จากภายใน WordPress มันยอดเยี่ยมมาก

ไดเรกทอรีแคช, ไดเรกทอรีอัปโหลดไฟล์ ฯลฯ จะถูกเพิ่มไปยัง. gitignore หากคุณต้องการคุณสามารถตั้งค่างาน cron เพื่อตรวจสอบการอัปโหลดเป็นประจำและผลักดันพวกเขาไปที่ gitosis แต่นั่นไม่จำเป็นสำหรับฉัน

ต้นแบบ / โครงสร้างการพัฒนาเป็นชุดที่จะเลียนแบบบางส่วนรูปแบบการแตกแขนงของวินเซนต์ Driessen ฉันยังใช้ส่วนขยายgit git-flowและฉันขอแนะนำอย่างนั้นเช่นกัน

ฉันมีนักพัฒนา 10 คนหรือมากกว่าที่ทำงานโครงสร้างนี้มานานกว่าหนึ่งปีแล้วและมันก็เป็นความฝันที่จะได้ทำงานด้วย เชื่อถือได้ปลอดภัยรวดเร็วใช้งานได้และคล่องตัวคุณไม่สามารถขออะไรได้อีกมากมาย!


ฉันกำลังจะตั้งค่าการติดตั้ง wp ในลักษณะที่คล้ายกัน (แต่เราใช้ svn) และฉันต้องการยืนยันกระบวนการของคุณสำหรับการอัปเดตปลั๊กอินและ wp: ทำการอัปเดตและตรวจสอบบน dev, ยอมรับการเปลี่ยนแปลง ขึ้นอยู่กับชีวิต โดยสรุปคุณไม่เคยทำการอัพเดทการติดตั้ง wp บนเซิร์ฟเวอร์จริงที่คุณนำมาเปลี่ยนแปลงผ่านการอัพเดตใน repo หรือไม่?
paullb

1
สิ่งที่เกี่ยวกับการเปลี่ยนแปลงฐานข้อมูลที่ทำโดยรูทีนการอัพเดท สิ่งเหล่านี้ส่งผลกระทบต่อฐานข้อมูลการผลิตอย่างไร
paullb

เวิร์กโฟลว์นั้นถูกต้อง @paullb และคุณไม่ต้องกังวลกับการอัพเดทฐานข้อมูล วิธีการทำงานของ WordPress การอัพเดทจะถูกเรียกใช้หลังจากตรวจพบการเปลี่ยนแปลงดังนั้นการทำงานแบบเดียวกับการอัปเดตด้วยตนเอง
Matthew Boynes

@ MatthewBoynes สวัสดี คุณยังคงใช้เวิร์กโฟลว์นี้สำหรับการพัฒนาของคุณหรือไม่ ถ้าเป็นเช่นนั้นฉันจะใช้เวิร์กโฟลว์นี้กับโครงการของฉัน ขอบคุณ :)
khakiout

ฉันทำไม่ได้ แต่เพียงเพราะมันไม่สามารถใช้ได้กับโปรเจ็กต์ที่ฉันกำลังทำงานอยู่ซึ่งโฮสต์บน WordPress.com VIP เป็นส่วนใหญ่ ถ้ามันใช้ได้ฉันจะยังคงใช้มัน (และอันที่จริง บริษัท ที่ฉันเคยทำงานก่อนหน้านี้จะยังคงใช้มันต่อไป)
Matthew Boynes

4

ครั้งแรกฉันคิดว่ามันสำคัญที่จะต้องพิจารณาสิ่งที่คุณกำลังจะควบคุมเวอร์ชัน ฉันจะแนะนำกับการวางไดเรกทอรี WP ทั้งหมดภายใต้ VC ฉันคิดว่ามันเหมาะสมที่จะวาง wp-content / themes / YourThemeName ภายใต้ VC สำหรับไซต์ขนาดใหญ่ที่มีปลั๊กอินที่ซับซ้อนจำนวนมากฉันสามารถเห็นเคสรวมถึง wp-content / plugins ด้วย หากคุณจำเป็นต้องทำอย่างแน่นอนคุณสามารถรวม wp-content / uploads คำตอบด้านล่างจะเปลี่ยนไปเล็กน้อยขึ้นอยู่กับสิ่งที่คุณควบคุมเวอร์ชัน

ระบุว่านี่คือสิ่งที่ฉันใช้:

Local: ตั้งค่า LAMP stack บนเครื่องของคุณ ใช้ URL เดียวกับเว็บไซต์พัฒนาของคุณ ใช้รายการไฟล์ VirtualHosts และ. โฮสต์เพื่อจำลองสภาพแวดล้อมการพัฒนาจากมุมมอง URL หากคุณเป็นเพียง VC'ing ชุดรูปแบบของคุณพิจารณาใช้ SSHFS เพื่อเชื่อมโยงไปยัง wp-content / plugins, wp-content / uploads พิจารณาใช้ฐานข้อมูลในการติดตั้งการพัฒนาของโครงการเว้นแต่ว่าคุณกำลังยกของหนัก

การพัฒนา: ชำระเงินสำเนาที่ใช้งานได้ของ Repo ของคุณลงในสภาพแวดล้อม WP ของคุณ ติดตั้ง POST-COMMIT Hook ใน SVN เพื่ออัปเดต repo นี้ในการส่งข้อมูลแต่ละครั้ง สิ่งนี้จะทำให้มันตรงกัน (พิจารณาว่าเป็นการรวมกันอย่างต่อเนื่องของคนจน)

การผลิต: ตรวจสอบแท็กเวอร์ชันที่มีชื่อซึ่งแทนตัวเลือกสุดท้าย เมื่อคุณต้องการใช้เวอร์ชันใหม่ให้สลับแท็กและอัพเดต repo


สภาพแวดล้อมแบบ dev เหมาะอย่างยิ่งสำหรับการทดสอบการสร้างในเวลากลางคืนและ wordpress git ได้รับการอัปเดตโดยอัตโนมัติทุก ๆ 30 นาทีนอกเหนือจากการกระจายอำนาจและทำงานได้ดีขึ้นสำหรับทีมฉันไม่รู้จักใครที่ย้ายไป git / hg ที่กลับไปแล้ว เพื่อใช้ svn
Wyck

1
เพียงแค่อยากรู้ว่าเหตุผลของคุณที่ไม่วางไดเรกทอรี WP ทั้งหมดภายใต้การควบคุมเวอร์ชัน ดูเหมือนว่าคอขวดในเวิร์กโฟลว์ การใส่ WP ใน repo จะให้ devs codebase และ WP รุ่นเดียวกันทั้งหมด นอกจากนี้ยังช่วยให้สอดคล้องกันในสภาพแวดล้อม ดูลิงค์ของ Wyck (ตามคำตอบของเขา) เพื่อกำหนดไฟล์ wp-config
Brian Fegter

2

เราเพิ่งค้นพบRAMP หมายเหตุ: นี่เป็นเพียงส่วนหนึ่งของกระบวนการทั้งหมด แต่การซิงค์ฐานข้อมูลเนื้อหาระหว่างเซิร์ฟเวอร์อาจเป็นส่วนที่ยากที่สุดของมัน


2

ฉันทำสิ่งนี้ด้วย git และ mercurial เพียงแค่ให้แน่ใจว่าคุณใช้ repo ส่วนตัว

ตัวเลือกที่ 1.

ปัญหาเพียงอย่างเดียวคือ config.php ซึ่งคุณสามารถบอกให้คอมไพล์ไม่สนใจการกดหรือก่อนเริ่มต้น

ใช้.gitignoreหรือgit update-index --assume-unchanged config.php(อ่านข้อมูลเกี่ยวกับคำสั่งที่ไม่เปลี่ยนแปลงก่อนใช้งาน)

ตัวเลือก 2

ใช้เงื่อนไขใน config.php ที่ตรวจสอบ url และใช้ข้อมูลประจำตัวที่ถูกต้องตามบรรทัด "ถ้าเซิร์ฟเวอร์ url = dev จากนั้นใช้ข้อมูลประจำตัว A ใช้ข้อมูลอื่น B" เป็นต้น

มาร์คอธิบายสิ่งนี้ดีกว่าhttp://markjaquith.wordpress.com/2011/06/24/wordpress-local-dev-tips/

PS คุณสามารถเซิร์ฟเวอร์ไฟล์โดยตรงจาก repo ระยะไกลแทนการมี "ไฟล์เซิร์ฟเวอร์" แบบดั้งเดิม (วิดีโอน่าเบื่อจริง ๆ ที่ฉันทำเกี่ยวกับhttp://www.youtube.com/watch?v=8ZEiFi4thDIนี้)

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.