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

คำถาม

มีเหตุผลที่ถูกต้องหรือไม่ที่จะไม่ใช้ 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 โดยเฉพาะเพื่อปรับใช้กับการผลิต?

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

ข้อดี:

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

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

จุดด้อย:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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