เป็นที่ยอมรับหรือไม่ที่จะปรับใช้เว็บแอปกับการผลิตโดยตรงจาก SVN


11

คำถาม

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

พื้นหลัง

สถานที่ทำงานของฉันมีวัฒนธรรมของการติดแท็กใน SVN และจากนั้นปรับใช้การวางจำหน่ายเหล่านั้นโดยตรงกับเว็บเซิร์ฟเวอร์ต่างๆที่ใช้svn coหรือsvn switchรวมถึงการผลิตโดยตรง

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

ฉันได้นำข้อกังวลของฉันไปใช้กับเจ้าหน้าที่ปฏิบัติงานที่รับผิดชอบในการปรับใช้โค้ดให้เข้ากับสภาพแวดล้อมต่างๆของเรา (การจัดเตรียมการเตรียมการการผลิต) ฯลฯ ข้อโต้แย้งของพวกเขาค่อนข้างมากว่ามันใช้งานได้ค่อนข้างดี

แก้ไข:

สิ่งที่ฉันหมายถึงเกี่ยวกับการสร้างและปรับใช้:

ตัวอย่างเช่นหากผู้พัฒนาต้องการเพิ่มการตั้งค่า web.config สำหรับสภาพแวดล้อมเฉพาะ โดยทั่วไปแล้ว Web.config จะไม่ถูกเก็บไว้ใน svn ดังนั้นไฟล์เหล่านี้จะถูกอัปเดตด้วยตนเองโดยไม่มีสคริปต์การสร้างอัตโนมัติในรูปแบบใด ๆ ดังนั้นหากพวกเขาหายไปหรือ OPS ลืมเพิ่มเขตข้อมูลลงใน web.config สำหรับรุ่นแล้วคุณมีปัญหา

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

วิธีสร้างและปรับใช้ปัจจุบัน

สำหรับโครงการที่สงสัยว่าผู้พัฒนาสร้างการเผยแพร่ด้วยตนเองโครงการอื่น ๆ จะมีขั้นตอนการสร้างอัตโนมัติด้วย NANT หรือ MSBuild ซึ่งก็โอเค

การย้ายฐานข้อมูลสำหรับโครงการส่วนใหญ่ผ่านสคริปต์ DB หรือสคริปต์การย้ายข้อมูล (Migrator.NET) หรือแพคเกจ CMS

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

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

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

อย่าเข้าใจฉันผิดงานนี้ทำงานได้ดี อย่างไรก็ตามฉันต้องการลองและผลักดันการสร้างและปรับใช้อัตโนมัติ ฉันเคยใช้สิ่งนี้กับ Rails และ Capistrano และสำหรับโครงการส่วนตัวที่ใช้ Cygwin, Nant และ SSH

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

หรือไม่มีข้อโต้แย้งที่ถูกต้องจริงกับการใช้ SVN โดยเฉพาะเพื่อปรับใช้กับการผลิต?


คุณสามารถอธิบายรายละเอียดเกี่ยวกับ "โดยไม่ใช้สคริปต์การสร้างและปรับใช้หรือรูปแบบบางอย่างหรือการปรับใช้อัตโนมัติที่คุณสูญเสียการตั้งค่าสภาพแวดล้อมการรวม"?
talonx

@talonx - ตัวอย่างเช่นหากผู้พัฒนาต้องการเพิ่มการตั้งค่า web.config สำหรับสภาพแวดล้อมเฉพาะ โดยทั่วไป web.config จะไม่ถูกเก็บไว้ใน svn และดังนั้นไฟล์เหล่านี้จะได้รับการอัปเดตด้วยตนเองโดยไม่มีสคริปต์การสร้างอัตโนมัติในรูปแบบใด ๆ ดังนั้นหากพวกเขาสูญหายหรือ OPS ลืมเพิ่มเขตข้อมูลลงใน web.config คุณมีปัญหา บิลด์สคริปต์ที่บอกว่าใช้ XMLPoke เพื่อสร้าง web.config ที่เหมาะสมสำหรับสภาพแวดล้อมเฉพาะนั้นเหมาะสมที่สุดเมื่อคุณมีสคริปต์เวอร์ชันที่ทำเอกสารการเปลี่ยนแปลงทั้งหมดที่จำเป็นสำหรับแต่ละสภาพแวดล้อมของคุณ
Justin Shield

ขอบคุณ บางทีคุณสามารถแก้ไขคำถามของคุณเพื่อชี้แจงจุดนี้
talonx

พวกเขาเพียงต้องการเช็คเอาต์แหล่งที่มาหรือมีขั้นตอนแบบแมนนวลหลังจากเช็คเอาต์ (การรวบรวมบรรจุภัณฑ์การกำหนดค่า ... ) หรือไม่
เดวิด

คำตอบ:


7

จากประสบการณ์ของฉันมีทั้งข้อดีและข้อเสีย:

ข้อดี:

  • บางครั้งคุณทำการแก้ไขด่วนอย่างเร่งด่วนบนเซิร์ฟเวอร์ที่ใช้งานจริงจากนั้นคุณสามารถตรวจสอบได้ทันทีจากที่นั่น (แม้ว่าในทางทฤษฎีเหตุผลด้านความปลอดภัยเป็นความคิดที่ดีที่จะใช้การเข้าถึง repo แบบอ่านอย่างเดียวจากเซิร์ฟเวอร์ที่ใช้งานจริง)

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

จุดด้อย:

  • ระบบของคุณอาจไม่เสถียรในระหว่างsvn upการอัปเดตและ DB ของคุณ สำหรับเว็บไซต์ที่มีอัตราการเข้าชมสูงหมายความว่าผู้ใช้บางรายจะได้รับข้อความแสดงข้อผิดพลาดหน้าเว็บที่หักหรือหน้าว่างที่ดีที่สุด นั่นคือสิ่งที่เรามักจะเห็นในบริการสังคมต่างๆ อย่างไรก็ตามการบริการที่ดีจะใช้ "atomically" ในแง่ที่ทำให้ระบบเข้าสู่โหมดการบำรุงรักษาตลอดระยะเวลาของการอัปเดต ( คุณยากจน reddit! )

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

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

  • ความปลอดภัย: ใครบางคนที่เข้าถึงเซิร์ฟเวอร์ที่ใช้งานจริงของคุณได้รับสิทธิ์หรือไม่นอกจากนี้ยังสามารถเข้าถึง repos ของคุณผลิตภัณฑ์อื่น ๆ ได้เช่นกันและอาจเข้าถึงการเขียนด้วย! ภาพรวมการเปิดเซิร์ฟเวอร์ SVN ภายในของคุณสู่โลกภายนอกเป็นความคิดที่ไม่ดี แหล่งเก็บข้อมูลต้นทางของคุณควรอยู่หลังไฟร์วอลล์ของ บริษัท ระยะเวลา

  • จะมีการอัปเดตสคริปต์อยู่แล้วเช่นสำหรับการปรับปรุงโครงสร้างฐานข้อมูลการจัดการ cronjobs ฯลฯ ดังนั้นทำไมไม่มีสคริปต์ที่ทำได้ทั้งหมด - ie ดึงรีลีสล่วงหน้าก่อนบรรจุล่าสุดสลับไปยังโหมดการบำรุงรักษาแหล่งอัปเดตรันสคริปต์เฉพาะรีลีสเป็นต้น

แก้ไข:สำหรับผู้ที่ยังอยู่ในโครงการ SVN อย่าลืมสิ่งนี้ในการกำหนดค่า apache ของคุณ:

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

1
+1: การโต้แย้งที่ยอดเยี่ยม ฉันอาจจะขายมันในด้านความปลอดภัยและความเสี่ยงของการมีพื้นที่เก็บข้อมูลที่ถูกบุกรุก แน่นอนเหตุผลที่ดีในการส่งเสริมการสนทนาต่อต้านการใช้ SVN สำหรับการผลิตปรับใช้
Justin Shield

2

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

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

สำหรับการอ้างอิงให้ดูที่Joelพูดถึงว่ากระบวนการสร้างคลิกเดียวช่วยให้คุณประหยัดได้อย่างไรในระยะสั้นถึงปานกลาง


0

ตรวจสอบให้แน่ใจว่าคุณมีการควบคุมการเช็คอินที่เหมาะสมบน SVN ตัวอย่างเช่นพิจารณาเรื่องนี้ -

  • มีการเช็คอินคุณสมบัติสำหรับการเปิดตัว
  • รหัสถูกปรับใช้ในการจัดเตรียม QA ทำงานของมัน
  • ข้อบกพร่องได้รับการแก้ไขการทดสอบรอบอื่น (แต่มันทำงานในทีมของคุณ)
  • เช่นเดียวกันสำหรับ pre-prod
  • ปรับใช้กับการผลิต

หากใครบางคนทำการเช็คอินโดยไม่ได้ตั้งใจหลังจากขั้นตอนก่อนการผลิตมีความเสี่ยงที่จะทำลายบางสิ่งบางอย่าง หากสิ่งนี้ถูกควบคุม - ไม่อนุญาตให้มีการเช็คอินระหว่าง pre-prod ยกเว้นการแก้ไขข้อผิดพลาด - ฉันไม่เห็นความเสี่ยงใด ๆ

อัปเดต: คุณมีปัญหาเกิดขึ้นหากคุณไม่เช็คอินไฟล์กำหนดค่าของคุณ ฉันไม่สามารถให้คำแนะนำใด ๆ สำหรับสิ่งนี้นอกจาก "ได้โปรดและรวดเร็ว!"


ไฟล์การกำหนดค่าจะถูกตรวจสอบในบางสิ่งบางอย่างเช่น web.config-default ปัญหาที่ใหญ่ที่สุดของเรื่องนี้คือมันง่ายที่จะลืมอัปเดตไฟล์ที่มีเวอร์ชันใน SVN หากคุณเพิ่มคุณสมบัติเนื่องจากไม่จำเป็นต้องมีการปรับใช้โดยตรง ไฟล์เหล่านี้เกือบจะล้าสมัยแล้วและก็ต่อเมื่อคุณพบว่าคุณต้องการไฟล์แล้วคุณก็กำลังตรวจสอบเพื่อค้นหาว่ามีอะไรแตกต่างกันระหว่างไฟล์ที่มีเวอร์ชันและไฟล์ที่ไม่ใช่เวอร์ชัน นอกจากนี้คุณไม่ต้องการอัปเดตเวอร์ชันต่อสภาพแวดล้อมใน SVN ด้วยเหตุผลเดียวกัน
Justin Shield

วิธีการเกี่ยวกับการทำให้การดำเนินการใช้ไฟล์ config จาก svn ก่อนการปรับใช้?
talonx

0

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

แต่เมื่อโครงการมีอายุประมาณหนึ่งปีมูลค่าการลงทุนในเครื่องมือการปรับใช้ เหตุผลง่ายๆคือ

  • ธุรกิจเติบโตดังนั้นคุณวางแผนที่จะโฮสต์บนเซิร์ฟเวอร์มากกว่าหนึ่งแห่ง
  • อาจมีข้อผิดพลาดในสภาพแวดล้อมเฉพาะและคุณไม่มีที่ที่จะทำซ้ำข้อบกพร่อง ไม่มีวิธีง่ายๆในการตั้งค่าโดยไม่มีกระบวนการ tar-untar-forget_about_home_for_a_week
  • บางคนมีแนวโน้มที่จะทำลายการสร้าง ผู้ทำลายการสร้าง

หากคุณต้องการโน้มน้าวใจพวกเขาขอให้พวกเขาตั้งค่าเซิร์ฟเวอร์อื่นสำหรับการทดสอบภายในหรือ QA

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