ปรับปรุงกลยุทธ์การปรับใช้ของเรา


12

เรามีแอพอีคอมเมิร์ซที่เราพัฒนาที่ บริษัท ของเรา แอปพลิเคชั่น LAMP มาตรฐานที่เราได้พัฒนาขึ้นและลงเป็นเวลาประมาณ 3 ปี เราพัฒนาแอปพลิเคชันบนโดเมนการทดสอบที่นี่เราเพิ่มคุณสมบัติใหม่และแก้ไขข้อบกพร่อง ฯลฯ การติดตามข้อผิดพลาดและการพัฒนาคุณสมบัติของเรานั้นได้รับการจัดการภายในโซลูชันการโค่นล้มการโฮสต์ (unfuddle.com) เนื่องจากมีการรายงานข้อบกพร่องเราทำการแก้ไขเหล่านี้ในโดเมนการทดสอบแล้วทำการเปลี่ยนแปลง svn เมื่อเรามีความสุขข้อผิดพลาดได้รับการแก้ไข เราปฏิบัติตามขั้นตอนเดียวกันนี้ด้วยการเพิ่มคุณสมบัติใหม่

เป็นมูลค่าชี้ให้เห็นว่ามีสถาปัตยกรรมทั่วไปของระบบและแอปพลิเคชันของเราทั่วเซิร์ฟเวอร์ของเรา ทุกครั้งที่มีการพัฒนาคุณลักษณะใหม่เราจะเผยแพร่การอัปเดตนี้ไปยังไซต์ทั้งหมดโดยใช้แอปพลิเคชันของเรา (เซิร์ฟเวอร์ที่เราควบคุมอยู่เสมอ) แต่ละไซต์ที่ใช้ระบบของเราใช้ไฟล์เดียวกันเป็นหลักในอัตรา 95% ของโค้ดเบส เรามีสองสามโฟลเดอร์ภายในแต่ละไซต์ที่มีไฟล์ที่เรียกว่าไซต์ - ไฟล์ css / รูปภาพ ฯลฯ นอกจากนั้นความแตกต่างระหว่างแต่ละไซต์นั้นถูกกำหนดโดยการตั้งค่าการกำหนดค่าต่างๆภายในฐานข้อมูลแต่ละไซต์

นี่จะเป็นการปรับใช้จริง เช่นเดียวกับเมื่อเราพร้อมที่จะเปิดตัวการอัปเดตบางประเภทเราเรียกใช้คำสั่งบนเซิร์ฟเวอร์ที่เปิดเว็บไซต์ทดสอบอยู่ สิ่งนี้ดำเนินการคำสั่ง copy (cp -fru / testsite / / othersite /) และผ่านแต่ละ vhost บังคับให้อัปเดตไฟล์ตามวันที่แก้ไข เซิร์ฟเวอร์เพิ่มเติมแต่ละตัวที่เราโฮสต์นั้นมี vhost ที่เราทำการเชื่อมโยง codebase ที่ใช้งานจริงแล้วเราจะทำซ้ำขั้นตอนการคัดลอกบนเว็บไซต์ทั้งหมดบนเซิร์ฟเวอร์นั้น ในระหว่างขั้นตอนนี้เราจะย้ายไฟล์ที่เราไม่ต้องการถูกเขียนทับย้ายกลับไปเมื่อการคัดลอกเสร็จสิ้น สคริปต์การเปิดตัวของเรามีฟังก์ชั่นอื่น ๆ อีกมากมายเช่นการใช้คำสั่ง SQL เพื่อแก้ไขแต่ละฐานข้อมูลการเพิ่มฟิลด์ / ตารางใหม่เป็นต้น

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

การเพิกเฉยวิธีการในปัจจุบันของเราจะเป็นการดีหากได้ยินว่าคนอื่น ๆ เข้าใกล้ปัญหาเดียวกัน

เพื่อสรุป ...

  • วิธีที่ดีที่สุดในการสร้างไฟล์ในเซิร์ฟเวอร์หลายเครื่องยังคงซิงค์กับ svn อย่างไร
  • เราจะป้องกันการเรพลิเคตไฟล์ได้อย่างไร? symlink / อย่างอื่น?
  • เราควรจัดโครงสร้าง repo ของเราอย่างไรเพื่อให้เราสามารถพัฒนาคุณสมบัติใหม่ ๆ และแก้ไขปัญหาเก่า
  • เราควรเรียกใช้การเปิดตัว / การย้อนกลับอย่างไร

ขอบคุณล่วงหน้า

แก้ไข:

เมื่อเร็ว ๆ นี้ฉันได้อ่านสิ่งที่ดีมากมายเกี่ยวกับการใช้PhingและCapistranoสำหรับงานประเภทนี้ ใครช่วยให้ข้อมูลเพิ่มเติมเกี่ยวกับพวกเขาและพวกเขาจะดีสำหรับงานประเภทนี้?

คำตอบ:


6

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

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

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

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

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

ฉันสมมติว่าเมื่อคุณพูดถึง LAMP คุณกำลังใช้ PHP หรือภาษาสคริปต์อื่นซึ่งไม่ต้องการกระบวนการรวบรวม นั่นหมายความว่าคุณอาจพลาดกระบวนการที่เรียกว่าการผสานอย่างต่อเนื่อง สิ่งนี้โดยทั่วไปหมายถึงว่ารหัสของคุณกำลังถูกทดสอบอย่างต่อเนื่องเพื่อให้แน่ใจว่ายังอยู่ในสถานะ releasable ทุกครั้งที่มีคนตรวจสอบในรหัสใหม่กระบวนการใช้และเรียกใช้กระบวนการสร้างและการทดสอบ ด้วยภาษาที่รวบรวมคุณมักจะใช้สิ่งนี้เพื่อให้แน่ใจว่ารหัสยังคงรวบรวม ในทุก ๆ ภาษาคุณควรใช้โอกาสทดสอบหน่วย (รหัสของคุณอยู่ในหน่วยที่สามารถทดสอบได้หรือไม่) และการทดสอบแบบรวม สำหรับเว็บไซต์เครื่องมือที่ดีในการทดสอบการทดสอบการรวมระบบคือซีลีเนียม ใน Java builds ของเราเรายังวัดความครอบคลุมโค้ดและเมทริกโค้ดเพื่อดูความคืบหน้าเมื่อเวลาผ่านไป เซิร์ฟเวอร์ CI ที่ดีที่สุดที่เราพบสำหรับ Java คือ Hudson แต่สิ่งที่เหมือนกับ buildbot อาจทำงานได้ดีกว่าสำหรับภาษาอื่น คุณสามารถสร้างแพ็คเกจโดยใช้เซิร์ฟเวอร์ CI ของคุณ


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

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

ผมเห็นบทความในวันนี้เกี่ยวกับการใช้ฮัดสันข้าง PHP และพิงค์ - toptopic.wordpress.com/2009/02/26/php-and-hudson
robjmills

1

เราเริ่มใช้ Puppet (ผลิตภัณฑ์เรือธงของ Reductive Labs) มันเป็นเฟรมเวิร์กที่ใช้ทับทิมสำหรับการทำงาน sys-admin อัตโนมัติ ฉันอยู่ที่ puppetcamp เมื่อสองสามสัปดาห์ก่อนและนี่คือลิงค์วิดีโอ:

Luke Kanies นำเสนอ - บทนำหุ่นกระบอก

นอกจากนี้หากคุณต้องการดูการนำเสนอทั้งหมดที่ทำใน puppetcamp ในซานฟรานซิสโกนี่คือลิงค์:

งานนำเสนอเกี่ยวกับวิธีที่คนอื่นใช้ Puppet

สนุก.

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