การประสานฐานข้อมูลระหว่าง dev / การ staging และการผลิต


36

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

บอกว่าฉันมีเว็บไซต์ WordPress อยู่ ฉันเอาทุกอย่างไปทำซ้ำมันในสภาพแวดล้อมการพัฒนาของเรา ฉันเริ่มทำการเปลี่ยนแปลง 1 สัปดาห์ต่อมาฉันพร้อมที่จะปรับใช้การอัปเดตของฉัน ในระหว่างนี้ฐานข้อมูลในไซต์การผลิตมีการเปลี่ยนแปลง (โพสต์ใหม่ความคิดเห็นใหม่ ฯลฯ ) ฉันจะซิงโครไนซ์การเปลี่ยนแปลงระหว่างการผลิตและการพัฒนาในช่วงการเปิดตัวและเป็นไปได้ที่จะทำให้กระบวนการนี้เป็นอัตโนมัติ (อย่างน้อยค่อนข้าง) หรือไม่



ลองใช้ปลั๊กอินนี้wordpress.org/extend/plugins/duplicator
Gopal Bhattacharjee

คำตอบ:


10

อาจมีวิธีที่ดีกว่าที่ฉันหายไป แต่ฉันจะให้ตัวเลือกแก่คุณ 2 แบบ:

1. ใช้ XML ส่งออกเพื่อส่งบทความและความคิดเห็นใหม่ของคุณ จากนั้นใช้ผู้นำเข้า WordPressเพื่อนำเข้าโพสต์และความคิดเห็นใหม่กลับสู่ฐานข้อมูล dev

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

ในระหว่างนี้มีการเปลี่ยนแปลงการผลิต (โพสต์ใหม่ความคิดเห็นใหม่ ฯลฯ )

วิธีนี้จะช่วยแก้ปัญหาการนำเนื้อหาที่เปลี่ยนแปลงไปมาใช้

2. ใช้คำสั่งINSERT IGNORE INTO MySql เพื่อเพิ่มตารางใหม่จาก dev หรือคำสั่งREPLACEเพื่อเขียนทับแถวที่ซ้ำกันในตารางเดียวกัน

ก่อนที่จะใช้ MySql ทำการสำรองข้อมูลของฐานข้อมูลทั้งสองและย้ายฐานข้อมูล gz ไปยังเซิร์ฟเวอร์ที่ใช้งานจริงและอัปโหลดดัมพ์ (เปลี่ยนชื่อของ dev หากเป็นเหมือนการใช้งานจริง

INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`

ฉันไม่สะดวกกับคำสั่ง MySql ดังนั้นฉันจะไปกับตัวเลือก 1


สังเกตุเห็นว่าการเอ็กซ์พอร์ต XML มีจำนวนโพสต์เช่นในบล็อกของฉันโพสต์ 10,000 โพสต์ฉันไม่สามารถใช้ได้
edelwater

@edelwater ใช่ขึ้นอยู่กับการตั้งค่าเซิร์ฟเวอร์สำหรับ max_execution_time (โดยปกติ 30 วินาที) สำหรับการส่งออกขนาดใหญ่มากค่านี้จะต้องตั้งค่าที่สูงขึ้น (1-2 นาทีหรือมากกว่า)
2328 mike

2

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

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


2
จุดดี! อย่างไรก็ตามหากการผลิตมีการเปลี่ยนแปลงบางอย่างในพื้นที่เนื้อหาล้วน (โพสต์ความคิดเห็น) และ dev มีการเปลี่ยนแปลงในการพูดการตั้งค่าและการตั้งค่า (เช่นเพิ่ม 5 ปลั๊กอินและ tweaked การตั้งค่าของพวกเขา) คุณจะดำเนินการเปลี่ยนแปลงการตั้งค่าเหล่านั้นอย่างไร เวลาในการพัฒนาและหนึ่งในการผลิต)?
อเล็กซ์

นั่นคือคำถามจริงไม่ใช่หรือฉันไม่มีคำตอบ
Curtismchale

-1 บางครั้งเราจำเป็นต้องทำให้ข้อมูลตรงกัน พิเศษสำหรับการโพสต์ / หน้าidจากฐานข้อมูล
Francisco Corrales Morales

2

ทันทีที่คุณสัมผัสหัวข้อการเปลี่ยนแปลงแบบขนานคุณจะสัมผัสกับส่วนของการจัดการการกำหนดค่า ด้วยรูปแบบมากมายชุมชนของตัวเอง (http://www.cmcrossroads.com/) และเครื่องมือไม่มากนักสำหรับการจัดการเวอร์ชัน (เช่น svn / git) แต่สำหรับการสนับสนุนการจัดการการกำหนดค่า (รูปแบบ) เช่น clearcase (พื้นที่ที่แตกต่างกันโดยสิ้นเชิง)

ในกรณีนี้มันยังคงเป็นสถานการณ์ที่ง่ายและคุณจะพบว่ามันทำงานได้กับข้อ จำกัด บางอย่างและงานที่ต้องทำด้วยตนเองและบางรายการ

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

หากคุณต้องการทำสิ่งนี้ให้เป็นมืออาชีพมากขึ้น:

a) จดรายการของรายการกำหนดค่าทั้งหมดที่คุณพบซึ่งอาจเป็นรหัส WordPress เอง, ปลั๊กอินจากภายนอก, เนื้อหา, ข้อมูลเมตาและตัดสินใจว่าสิ่งใดที่คุณต้องการนำมาใช้ภายใต้ "การจัดการ" แบบใดที่สำคัญ

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

c) สำหรับการทำงานแบบขนานก่อนอื่นให้อธิบายว่า CI ใดที่คุณต้องการจัดการตัดสินใจว่าการไหลนั้นมาจากการพัฒนาไปสู่การผลิตหรือถ้าจำเป็นจริง ๆ ที่ต้องทำทั้งสองวิธี

d) สำหรับ CI แต่ละประเภทภายใต้ (a) เขียนความละเอียด เช่นสำหรับทั้งหมดที่เป็นข้อความ (หรือข้อความที่ส่งออกเช่นไฟล์ php แต่ข้อความธรรมดาในไฟล์ XML) สามารถรวมกันได้ นี่ไม่มีปัญหาจริงๆ แต่คุณต้องมีเครื่องมือผสานที่ดี เช่นด้วย ClearCase คุณจะได้รับ 3 วิธีในการผสานสถานการณ์ต่อไปนี้: 1) การผสานเล็ก ๆ น้อย ๆ : มันจะทำสิ่งเหล่านี้โดยอัตโนมัติ 2) อัตโนมัติเล็กน้อย: มันจะทำสิ่งเหล่านี้โดยอัตโนมัติ แต่คุณต้องตรวจสอบมัน 3) เป็นข้อขัดแย้งเช่นใน 1 บรรทัดมีการเปลี่ยนแปลงหลายอย่าง ส่วนที่ไม่สำคัญคือส่วนที่น้อยที่สุดที่คุณต้องดูแลด้วยตนเองเครื่องมือการผสานที่ดีจะนำคุณไปสู่สิ่งนี้เช่นที่อยู่ใน clearcase (ซึ่งรวมถึงการรวมคำและที่คุณสามารถเชื่อมโยงในการรวมเชิงพาณิชย์หรือไม่ใช่เชิงพาณิชย์อื่น ๆ ชนิด) Furtermore หากคุณระบุไฟล์ภายใต้ (a) ที่ควรคัดลอกเท่านั้นพฤติกรรมของพวกเขาจะไม่ถูกรวมเข้าด้วยกัน แต่จะถูกคัดลอกเพียงวิธีเดียวในการเขียนทับเวอร์ชันอื่นโดยไม่ต้องรวม (เช่นปลั๊กอินที่คุณไม่ได้แก้ไข) หลายประเภทเหล่านี้เป็นไปได้ที่มีพฤติกรรมแตกต่างกัน แต่เขียนความสัมพันธ์ระหว่าง CI

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

ดังนั้น ... เพื่อแก้ปัญหานี้คุณต้องใช้เครื่องมือการจัดการเวอร์ชันที่รองรับสตรีมที่แตกต่างกัน แต่ละสตรีมจะแทนส่วนหนึ่ง (สิ่งนี้อาจซับซ้อนมากขึ้นอยู่กับความต้องการของคุณ แต่ในกรณีนี้ฉันคิดว่ามันง่ายมาก)

หากตอนนี้คุณสามารถจัดการให้มีกระแสข้อมูลเหล่านี้ภายใต้การติดตั้ง WordPress ของคุณและซิงค์กับเนื้อหาของฐานข้อมูล ฯลฯ ... จากนั้นคุณสามารถทำการผสานในเครื่องมือ CM / versioning แล้วส่งออกกลับในสภาพแวดล้อมอื่น

สิ่งคือ ... คุณต้องเขียนสิ่งนี้ก่อน นี่ไม่ใช่การแฮกทางเทคนิค มันเป็นรูปแบบเริ่มต้นของการจัดการการกำหนดค่าดังนั้นไม่มีอะไรแปลกที่นี่ แต่คุณต้องจดไว้ คุณอาจพบว่าปลั๊กอินที่ติดตั้งทำการเปลี่ยนแปลงในฐานข้อมูลด้วยข้อมูลบางอย่างที่แตกต่างในสภาพแวดล้อมอื่นดังนั้นคุณต้องมีขั้นตอนเพิ่มเติมเกี่ยวกับเรื่องนี้

ในทางเทคนิคแล้วทุกอย่างเป็นไปได้ที่จะตรวจสอบhttp://www.cmcrossroads.com/forumsสำหรับสถานการณ์ที่ซับซ้อนกว่าหลายสิบหรือหลายร้อยเท่า แต่มักจะใช้วิธีการเดียวกันและใช้รูปแบบ CM ชุดเดียวกัน

กล่าวโดยย่อ: วางเลเยอร์การจัดการเวอร์ชันไว้ด้านล่างทำการผสานและจัดการข้อขัดแย้งจากนั้นนำเข้าในสภาพแวดล้อมเป้าหมาย คิดกลยุทธ์การสตรีมที่เหมาะสมที่นี่และจดบันทึก ดำเนินการจัดการ CM weeny bit ที่เล็ก นั่นจะเป็นวิธีแก้ปัญหาอย่างมืออาชีพหรืออาจจะติดตั้งโปรแกรมคัดลอก db สคริปต์และอื่น ๆ ...


2

ฉันเพียงแค่ทำโพสต์เกี่ยวกับวิธีการที่ฉันประสานข้อมูลการผลิตเพื่อการแสดงละครของเราตรวจสอบโพสต์บล็อกของฉันเกี่ยวกับมันที่: http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database รินผลิตเพื่อการแสดงละคร-enviorment /

หากคุณต้องการซิงโครไนซ์รหัสและสิ่งอื่น ๆ ด้วยฉันขอแนะนำให้สร้างที่เก็บ git หรือ mercurial ด้วยไฟล์ละเว้นที่เกี่ยวข้อง

หากคุณต้องการทำการอัพเดทที่แตกต่างเพื่อแยงจากการแสดงละครฉันเดาว่าการสร้างสคริปต์การโยกย้ายเป็นวิธีที่ปลอดภัยที่สุดและดีที่สุด

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