ฉันจะจัดการการพัฒนาความร่วมมือในเว็บไซต์ Drupal ได้อย่างไร

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

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

• ขั้นตอนใดที่เราสามารถทำได้เพื่อผสานการเปลี่ยนแปลงฐานข้อมูลของเราได้อย่างง่ายดาย

• วิธีที่เราควรรุ่นฐานข้อมูล (วางไฟล์การถ่ายโอนข้อมูลในคอมไพล์วิธีที่ดีที่จะทำ)?

• มีโมดูลใดบ้างที่สามารถช่วยแก้ไขปัญหาเหล่านี้ได้บ้าง

• หรือเราทำงานกับสำเนาของไซต์เดียวกันหรือไม่? (โปรดอย่าเลย)

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

เป็นการเปลี่ยนเวิร์กโฟลว์ แต่คุณควรคุ้นเคยกับการทำงานกับดัมพ์สดของ DB สด มีสามวิธีในการรับการเปลี่ยนแปลงในฐานข้อมูล

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

ถ้าคุณสามารถ. วันละหลายครั้งรับดัมพ์ใหม่และทดสอบบิลด์ของคุณคุณควรมีปัญหาการรวมน้อย

ฉันตอบคำถามที่คล้ายกันและฉันจะปรับเล็กน้อยเพื่อตอบคำถามของคุณที่นี่ คำแนะนำหลักของฉันคือคุณมีเซิร์ฟเวอร์การพัฒนา / การเตรียมการซึ่งการเปลี่ยนแปลงรหัสจะถูกตรวจสอบโดยใช้ระบบการรวมอย่างต่อเนื่องเป็นประจำ (เช่นทุก 5 นาที) ดังนั้นในเครื่องท้องถิ่นของคุณคุณจะทำงานเพียงครั้งเดียวในการขอรายงานข้อผิดพลาด / ฟีเจอร์ครั้งเดียวให้แน่ใจว่าได้แยกงานนี้จากคนอื่นอย่างชัดเจนว่าคนอาจทำงานและสื่อสารกับเพื่อนร่วมทีมของคุณว่าคุณกำลังทำงานอยู่ การติดตามบั๊กอื่น ๆ นั้นยอดเยี่ยมสำหรับเรื่องนี้) จากนั้นคุณทำการเปลี่ยนแปลงเป็นประจำและพวกเขาจะถูกดึงลงไปที่เซิร์ฟเวอร์ dev / การจัดเตรียมเช่นเดียวกับเพื่อนร่วมทีมของคุณ เป็นการดีที่คุณมีการทดสอบหน่วยในระบบการรวมอย่างต่อเนื่องของคุณ (ขอแนะนำ luntbuild หรือ QuickBuild สำหรับสิ่งนี้โดยวิธีการ แต่ฮัดสันยังใช้งานได้) ระบบ CI หรือการทดสอบสามารถรับความขัดแย้งใด ๆ ที่คุณอาจแนะนำโดยอัตโนมัติทันทีที่คุณตรวจสอบในรหัสของคุณ หากคุณต้องการเปลี่ยนแปลงเนื้อหา (ไม่ใช่รหัส) คุณสามารถทำได้บนเซิร์ฟเวอร์ dev / staging

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

1) ปรับใช้โดยวางฐานข้อมูลการผลิตและนำเข้า mysqldump ของฐานข้อมูลการพัฒนา หรือเรียกใช้ regex find / replace ก่อนหน้านี้ในลิงก์สัมบูรณ์แบบ hard-coded ใด ๆ ที่อ้างอิง URL dev ใน SQL dump หลังจากนำเข้า dev db ไปยัง prod ให้เรียกใช้คำสั่ง SQL (โดยทั่วไปผ่านสคริปต์) โดยอัตโนมัติเพื่อเปลี่ยนการตั้งค่าที่แตกต่างกันสำหรับ prod กว่า dev (เช่นคุณอาจมีตารางตัวแปรในการตั้งค่าการเชื่อมต่อสำหรับการเชื่อมต่อกับระบบภายนอกที่คุณต้องการ เปลี่ยนเป็นชี้ไปที่ระบบภายนอกที่แยงแทนที่จะเป็นรุ่น dev)

2) ใช้โมดูลคุณสมบัติตามที่ระบุไว้โดย budda สำหรับการตั้งค่าผู้ดูแลระบบและใช้โมดูลการส่งออกโหนดสำหรับการส่งออก / นำเข้าเนื้อหาร่วมกับโมดูลลบทั้งหมด ดังนั้นเวิร์กโฟลว์คือ:

ใช้ node_export และคุณสมบัติเพื่อส่งออกโหนด / คุณสมบัติไปยังไฟล์ทางเลือก (และหวังว่า) การควบคุมเวอร์ชันโหลดไฟล์บนระบบ prod ใช้อินเตอร์เฟส drush หรือ admin เพื่อโหลดคุณสมบัติใช้ drush delete-all หรือ interface interface เพื่อลบโหนดทั้งหมดของประเภทที่คุณต้องการนำเข้า ใช้ drush ne-import หรือส่วนต่อประสานผู้ดูแลระบบเพื่อนำเข้าโหนดจากไฟล์โหนดที่คุณส่งออก One note ฉันขอแนะนำให้ใช้เวิร์กโฟลว์มาตรฐานโดยที่เนื้อหามีทิศทางเดียวเท่านั้น Dev -> Prod หรือ Prod -> Dev (ฉันชอบอันนี้)

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

แม้ว่านี่จะเป็นคำถามเก่าที่มีคำตอบที่ยอมรับ แต่ฉันเชื่อว่ายังมีที่ว่างสำหรับอีกคำถามหนึ่ง

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

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

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

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

ในการถ่ายโอนข้อมูล:

mysqldump --all-databases --opt -u root -p > DUMP.sql

ในการกู้คืน:

mysql -u root -p < DUMP.sql

หากคุณไม่ได้เป็นเพียงฐานข้อมูลในเซิร์ฟเวอร์นั้นให้สคริปต์บางเวอร์ชันmysqldump(หรือเทียบเท่าหากคุณไม่ได้ใช้mysql ) ที่ทิ้งฐานข้อมูลของคุณเท่านั้น

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

โปรดทราบว่า Drupal 7 เก็บการตั้งค่าผู้ดูแลระบบทั้งหมดไว้ในฐานข้อมูล ซึ่งหมายความว่ามิเรอร์ฐานข้อมูลระหว่างเว็บไซต์การผลิต, การแสดงละครเว็บไซต์และเวิร์กสเตชันจะโยกย้ายการตั้งค่าโดยไม่ต้อง admim คุณสมบัติ

ตอนนี้สำหรับการแบ่งปันรหัส:

วิธีมาตรฐานในการแชร์รหัสระหว่างสมาชิกของทีมพัฒนาคือการใช้ระบบ SCM Drupal เกิดขึ้นจะเริ่มต้นได้รับการจัดการกับระบบเช่นชื่อคอมไพล์

Gitอนุญาตให้ใช้ที่เก็บข้อมูลโลคัลหรือรีโมต หากสมาชิกทีมอยู่ในพื้นที่ทางกายภาพเดียวกันคุณสามารถตั้งค่าที่เก็บในเครื่องบนเซิร์ฟเวอร์จัดเตรียมของคุณ หากพวกเขากระจายทางภูมิศาสตร์คุณสามารถตั้งค่าที่เก็บระยะไกล หากคุณไม่รังเกียจผู้อื่นที่อ่านรหัสของคุณภายใต้การพัฒนาคุณสามารถใช้Sandboxที่ Drupal.org เป็นที่เก็บข้อมูลระยะไกล นอกจากนี้คุณยังสามารถใช้พื้นที่โครงการบนGitHub GitHubไม่ได้เป็นเพียงแค่ที่เก็บข้อมูล แต่มาพร้อมกับเครื่องมือบางอย่างสำหรับการทำงานร่วมกันและอนุญาตให้ทั้งที่เก็บข้อมูลสาธารณะและส่วนตัว

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

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

มีบทเรียนมากมายเกี่ยวกับการเริ่มต้นใช้งานและการใช้git (GIYF) สองฉันจะแนะนำคือ: เว็บไซต์git-scmและPro Gitโดย Scott Chacon