วิธีตั้งค่ากระบวนการพัฒนาฐานข้อมูลท้องถิ่นสำหรับทีมงานเว็บขนาดเล็ก

พื้นหลัง

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

ก่อนหน้านี้เราทำงานผ่าน FTP บนเซิร์ฟเวอร์ dev ด้วยฐานข้อมูล dev เดียว มัน "ทำงาน" ^*ในขณะที่ แต่เราจะย้ายเข้าไปอยู่ในทิศทางใหม่ดังนั้นจึงเป็นเวลาที่จะครบกำหนดกระบวนการของเรา

เราใช้ Percona Server 5.5 แต่นี่ควรเป็นฐานข้อมูลที่ไม่เชื่อเรื่องพระเจ้าโดยมีแนวคิดว่าจะรักษาต้นทุนให้ต่ำ

เป้าหมาย :

ฉันกำลังมองหาการสร้างกระบวนการการรวมอย่างต่อเนื่อง (CI) สำหรับการพัฒนาฐานข้อมูลโดยคำนึงถึงสิ่งต่อไปนี้:

1. นักพัฒนามีสำเนาของข้อมูลภายในเพื่อเรียกใช้รหัสการพัฒนาเทียบกับ
2. โครงสร้างฐานข้อมูลย้อนกลับไปยังชุดการแก้ไขก่อนหน้า
3. สามารถแยกการเปลี่ยนแปลงคุณสมบัติใหม่กับการเปลี่ยนแปลงแก้ไขการออกแบบสคีมา
4. สามารถแก้ไขโครงสร้างฐานข้อมูลในเครื่องเพื่อทำการทดสอบ

แนวคิดเริ่มต้น

ผมได้ร่างออกกระบวนการด้านล่างใช้ SVN และ LiquiBase #4แม้ว่ามันจะลบอย่างสมบูรณ์

• สร้างสาขา 'การพัฒนา' จากลำตัว
• เซิร์ฟเวอร์ db 'กลางพัฒนา' จะปิดสาขา 'พัฒนา'
• นักพัฒนาท้องถิ่นถูกตั้งค่าให้เป็นทาสของสาขาการพัฒนา (แสดง#1ไว้ด้านบน)
• liquibase การแก้ไขมีความมุ่งมั่นอย่างสม่ำเสมอเพื่อให้สาขาการพัฒนาที่ดำเนินการหลังกระทำเบ็ดเพื่อปรับปรุงการพัฒนาฐานข้อมูลกลาง (ซึ่งจะหยดลงไปยังเครื่องท้องถิ่นทำงานเป็นทาสไปยังเซิร์ฟเวอร์ของการพัฒนานี้) (liquibase ให้#2ด้านบน)
• เมื่อฟีเจอร์หรือสคีมาการแก้ไขพร้อมที่จะไปยัง QA, DBA (ฉัน) จะรวมการเปลี่ยนแปลงที่เหมาะสมจากสาขาการพัฒนาเข้าสู่ลำต้น การกระทำนี้จะสร้างสคริปต์ sql เพื่อใช้กับเซิร์ฟเวอร์ฐานข้อมูลการแสดงละคร
• เซิร์ฟเวอร์ Staging ควรสะท้อนถึง TRUNK ซึ่งควรมีโครงสร้างเหมือนกับการผลิตรวมถึงการเปลี่ยนแปลงที่อยู่ใน QA
• หลังจากรันสคริปต์ sql บนเซิร์ฟเวอร์ staging ให้ทำ QA บางอย่างเกี่ยวกับการเปลี่ยนแปลง
• หากทุกอย่างดูดีให้แท็กโครงสร้าง สิ่งนี้จะสร้างสคริปต์. sql เพื่อให้ทำงานในการผลิตด้วยตนเองโดย DBA (สำหรับชั่วโมงที่มีการใช้งานไม่มากหากจำเป็น)

กระบวนการนี้ต้องการให้นักพัฒนาทั้งหมดหมดสาขา 'การพัฒนา' เดียวกันซึ่งหมายความว่ามีสกีมาฐานข้อมูลเพียงเวอร์ชันเดียวในเวลาใดก็ตาม (ไม่แน่ใจว่าฉันต้องการสิ่งนี้)

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

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

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

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

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

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

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

ฉันทำอะไรลงไป

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

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

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

ทางเลือกหนึ่งสำหรับการปรับใช้สภาพแวดล้อมการพัฒนาคือการสำรองข้อมูลของฐานข้อมูลการผลิตที่ได้รับการแก้ไขเป็นเวอร์ชันที่เหมาะสมและทำให้พร้อมใช้งานสำหรับ devs เพื่อกู้คืนสู่สภาพแวดล้อมการพัฒนา

ทำให้ง่ายต่อการแผ่ออก:เช่นเดียวกับกระบวนการสร้าง CI ใด ๆ ฐานข้อมูลควรปรับใช้จากสคริปต์เดียว ตั้งค่าเพื่อให้สามารถเชื่อมต่อฐานข้อมูลแบบ Paramaterised หรือสคริปต์เป็นตำแหน่งที่เป็นอิสระและสามารถเรียกใช้ผ่านการเชื่อมต่อได้

สคริปต์การแก้ไข:คุณจะต้องย้อนกลับและอาจย้อนกลับสคริปต์จากแต่ละเวอร์ชันที่วางจำหน่าย

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

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

• สร้างสภาพแวดล้อมการอ้างอิงด้วยรูปแบบพื้นที่เก็บข้อมูลที่คุณสร้างขึ้นทดสอบ

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

• รันสคริปต์แก้ไขจากสภาพแวดล้อมการทดสอบควัน

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

สิ่งที่ฉันชอบเกี่ยวกับกระบวนการนี้

นี่เป็นบิตเฮฟวี่เวทเล็กน้อยและได้รับการออกแบบมาสำหรับการปรับใช้ในสภาพแวดล้อมการผลิตที่ค่อนข้างเป็นระบบราชการและทึบแสง อย่างไรก็ตามมันมีจุดแข็งดังต่อไปนี้:

• นักพัฒนาสามารถแก้ไขจุดที่พวกเขาต้องการ

• สามารถรองรับหลายสาขาและลำธารของการพัฒนา

• สคริปต์การปรับใช้เองสามารถถูกทดสอบซ้ำได้ สิ่งนี้มีประโยชน์มากในการปิดการใช้งาน bunfights เนื่องจากสามารถทำซ้ำได้

• เครื่องมือเปรียบเทียบสคีมาจัดทำ QA ในการปรับใช้เอง

• การทดสอบจะทำกับสิ่งที่คาดว่าจะได้รับการปล่อยตัวเสมอและสิ่งนี้จะตรวจจับปัญหาที่เกิดจากสภาพแวดล้อมที่ไม่ซิงค์กัน

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

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

• สภาพแวดล้อมมีราคาถูกและใช้งานง่ายโดยไม่ต้องกระโดดผ่านห่วง

• นักพัฒนาถูกบังคับให้สร้างระบบที่คล้อยตามขั้นตอนการสร้างและการปรับใช้อย่างง่าย

• นักพัฒนาถูกบังคับให้เรียนรู้งานการบริหารฐานข้อมูลขั้นพื้นฐาน แต่สภาพแวดล้อมการทดสอบและการผลิตนั้นได้รับการหุ้มฉนวนจากข้อผิดพลาดที่ไม่มีข้อผิดพลาด

มันตอบสนองความต้องการของคุณอย่างไร

1. นักพัฒนามีสำเนาของข้อมูลในตัวเครื่องเพื่อเรียกใช้รหัสการพัฒนาเทียบกับ
   
   สคริปต์การปรับใช้หรืออิมเมจ DB หมายความว่าพวกเขาสามารถตั้งค่าสภาพแวดล้อมจากเวอร์ชันใด ๆ ที่มีให้

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

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

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