วิธีการถ่ายโอนไฟล์ไปยังการผลิต?


9

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

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

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

คำตอบ:


7

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

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

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


ดังนั้นการมี repo บนเซิร์ฟเวอร์ที่ใช้งานจริงก็โอเคใช่ไหม เมื่อฉันพูดว่าระบบอัตโนมัติฉันหมายถึงว่าในกรณีที่ไม่มี repo บนเซิร์ฟเวอร์ที่ใช้งานจริง (กล่าวอีกนัยหนึ่งจะมีการทดสอบและให้ความช่วยเหลือแก่ผู้ซื้อ แต่ไม่ใช่การผลิต ) แน่นอนการทดสอบของมนุษย์ไม่สามารถเป็นไปโดยอัตโนมัติมันไม่ใช่สิ่งที่ฉันตามมา
Tamás Szelei

1
@ Tamás: มันอาจโอเคที่จะเช็คเอาต์ repo ที่ได้รับความนิยมในเซิร์ฟเวอร์ของคุณถ้านั่นคือสิ่งที่คุณหมายถึง (apache (หรือเว็บเซิร์ฟเวอร์ที่ดีอื่น ๆ ) ทำให้มันง่ายที่จะทำให้ไฟล์ git ที่เกี่ยวข้องไม่สามารถเข้าถึงได้จากภายนอก แต่คุณได้อย่างง่ายดายเพียงแค่ทำให้"ส่งออก"ของมัน มีจุดของการมีไฟล์ใน webroot ของคุณที่ไม่ได้อยู่ที่นั่น
back2dos

เอ่อ -... แล้วคุณจะรู้ได้อย่างไรว่าอะไรคือข้อบกพร่องที่ไม่ทราบความรุนแรงที่ไม่ทราบว่ามันคืออะไร... ไม่ทราบ ?
Spoike

@Spike ฉันคิดว่า back2dos เป็นเพียงการสนับสนุนการทดสอบอย่างละเอียดโดยใช้รุ่นที่แก้ไขแล้วซึ่งไม่มีการแก้ไข "quick n dirty" ที่ยังไม่ได้ทดสอบ
สูงสุด

@Spoike: ใน 24-48 ชม. คุณสามารถเปลี่ยนบั๊กที่ไม่รู้จักจำนวนมากให้กลายเป็นบั๊กที่รู้จัก นอกจากนี้ใน 5 นาทีคุณสามารถเปลี่ยนบั๊กที่รู้จักให้เป็นบั๊กที่ไม่รู้จักจำนวนมาก สิ่งนี้เรียกว่าการแก้ไขด่วน
back2dos

2

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

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


1

ขึ้นอยู่กับว่าคุณใช้แพลตฟอร์มใดมีเครื่องมือมากมายที่อาจเหมาะสมสำหรับคุณที่จะใช้งานการผลิตอัตโนมัติ ฉันทำงานใน. NET shop ดังนั้นเราจึงใช้ NAnt (แม้ว่า MSBuild เป็นตัวเลือกที่ดีกว่าทุกวันนี้) Java มี Ant และสิ่งอื่น ๆ ทับทิมมีหลายอย่างเช่นเรค จากนั้นมีแพลตฟอร์มการรวมอย่างต่อเนื่องเช่น TeamCity และ Hudson ที่สามารถใช้สำหรับการจัดการการเผยแพร่เช่นกัน

ฉันไม่เคยเห็นหรือได้ยินว่ามีรหัส prod โดยตรงใน repo control source แยกต่างหาก แต่มันก็ใช้ได้ดี เช่นเดียวกับ back2dos กล่าวว่ากุญแจสำคัญคือการทำให้เป็นอัตโนมัติ เรามีสคริปต์สร้างของเราออกแบบมาเพื่อตรวจสอบจากการควบคุมแหล่งสร้างและผลักดันไปยังสภาพแวดล้อมการแสดงละครสำหรับการทดสอบ จากนั้นเมื่อเราชอบวิธีจัดเตรียมการทำงานสคริปต์จะคัดลอกจาก QA ไปยัง Prod

คำแนะนำของฉันคือดูที่เครื่องมือและเลือกจากนั้นออกแบบกระบวนการที่จะทำงานได้ดีกับเครื่องมือที่เลือก อย่าพยายามคิดค้นล้อใหม่มากเกินไป - นี่เป็นปัญหาที่แก้ไขได้มาก

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