เป็นวิธีปฏิบัติที่ดีที่สุดในการปรับใช้โครงการไปยังไฟล์เซิร์ฟเวอร์ด้วยไฟล์ด้วยตนเองหรือไม่?

26

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

deployment server devops

— Jake Muller
แหล่งที่มา

12

ไม่มีแม้แต่ "แบบฝึกหัดเดียวสำหรับทุกสถานการณ์" จากระยะไกลสำหรับงานนี้

— whatsisname

26

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

3

ที่เกี่ยวข้อง: en.wikipedia.org/wiki/…

— Jens Schauder

9

ฉันสงสัยว่า OP กำลังถามคำถามนี้เพราะเขารู้คำตอบอยู่แล้วและที่ทำงานของเขาคือ Doing It Wrong (tm) และ OP กำลังพยายามรวบรวมหลักฐานเพื่อให้เป็นกรณีสำหรับการเปลี่ยนแปลงวิธีที่พวกเขาทำสิ่งต่าง ๆ

— user1936

2

เราทำอย่างนี้ในสหัสวรรษที่สอง ควรจะดี! ;)

— Don Branson

103

แนวปฏิบัติที่ดีที่สุดคืออะไร การปรับใช้สิ่งประดิษฐ์โครงการหนึ่งด้วยตนเองในแต่ละการปรับใช้หรือทำไฟล์โดยการปรับใช้ไฟล์?

ทั้ง

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

"เพื่อสรุปผลสรุปของสรุป: ผู้คนมีปัญหา" (ดักลาสอดัมส์)

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

— Phill W.
แหล่งที่มา

17

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

— Neil

20

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

— BurnsBA

39

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

— GManNickG

8

@JohnHamilton: ต้องคำนึงถึงต้นทุนของระบบอัตโนมัติต่อความเสี่ยงของข้อผิดพลาดระหว่างการปรับใช้ด้วยตนเอง

— Robert Harvey

7

คุณไม่จำเป็นต้องมีเจนกินส์ด้วยซ้ำ เพียงสคริปต์เช็คอินที่มีคำสั่ง scp มากมาย (หรือสิ่งที่คุณใช้เมื่ออัปโหลดด้วยตนเอง) เป็นการปรับปรุง

— user253751

14

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

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

— อมร
แหล่งที่มา

หากจำนวนเซิร์ฟเวอร์ทั้งหมดเป็น 2 หรือน้อยกว่าคู่มือนั้นมีความเสี่ยงน้อยกว่าอัตโนมัติ อัตโนมัติต้องการการตรวจสอบข้อผิดพลาดอย่างกว้างขวาง ฉันไม่เคยเห็นวิธีแก้ปัญหาอัตโนมัติที่น่ารำคาญ

— Joshua

3

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

— amon

ฉันมีประสบการณ์มากมายทั้งสองทาง สิ่งที่ฉันทำสำหรับการปรับใช้ด้วยตนเองคือการติดตั้ง xcopy ดังนั้นจึงไม่มีขั้นตอนที่จะลืมบางสิ่ง

— Joshua

9

วิธีปฏิบัติที่ดีที่สุดคือการใช้กระบวนการอัตโนมัติบางประเภท

โปรดระมัดระวังในการตรวจสอบว่าไม่มีเหตุผลพิเศษสำหรับวิธีการ 'file by file' ซึ่งคุณต้องคำนึงถึง

— Ewan
แหล่งที่มา

1

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

— Jake Muller

4

คำถามที่ดีที่สุดที่จะถามคือ "ทำไมเราถึงทำแบบนี้?" ฉันไม่สามารถคิดเหตุผลได้ แต่ฉันรู้ว่า บริษัท บางแห่งชอบที่จะถือไกด้วยตนเองเหมือนที่เคย

— Ewan

8

@ JakeMuller สิ่งที่คุณควรอ่านระหว่างบรรทัดของคำตอบนี้คือการตัดสินใจโดยการให้เหตุผลเกี่ยวกับสถานการณ์ที่ไม่ยึดติดกับสิ่งที่ใครบางคนที่ไม่มีความรู้ได้ประกาศคำตอบที่ถูกต้องเสมอ

— Blrfl

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

— bdsl

6

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

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

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

— Blueriver
แหล่งที่มา

1

แนวทางปฏิบัติที่ดีที่สุดคือการวิเคราะห์ต้นทุน / ผลประโยชน์สำหรับการปรับใช้เฉพาะสำหรับ บริษัท ของคุณ

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

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

— Cort Ammon - Reinstate Monica
แหล่งที่มา

1

มีเฉดสีเทามากมายระหว่างการคัดลอกไฟล์ต่อไฟล์แบบแมนนวลและการส่งต่อเนื่อง

เริ่มต้นด้วยการลดความซับซ้อนของกระบวนการปรับใช้ตัวอย่างเช่นโดยใช้ไฟล์ zip, บรรจุภัณฑ์สไตล์ rpm, infrastruture เป็นเครื่องมือการจัดการรหัส (เช่นหุ่นเชิดหรือพ่อครัว) หรือแม้แต่สคริปต์ง่ายๆที่คัดลอกไฟล์ให้คุณจาก การจัดเตรียมพื้นที่บนเซิร์ฟเวอร์ ftp

กระบวนการปรับใช้ที่มีขั้นตอนแบบแมนนวลมีแนวโน้มที่จะมีข้อผิดพลาดมากขึ้น (และทำให้ล้มเหลว) - เหมือนที่คนอื่น ๆ พูดเอาองค์ประกอบของมนุษย์ออกไป

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

— vikingsteve
แหล่งที่มา

0

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

— Edu Garcia
แหล่งที่มา