ความคิดเกี่ยวกับการพัฒนาโดยใช้เครื่องเสมือน [ปิด]

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

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

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

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

สิ่งเหล่านี้ไม่ใช่การคัดค้านไปยัง VMs แต่เป็นการคัดค้านที่อาจเกิดขึ้นกับการพัฒนาทางไกล

ฉันคิดว่าคุณเป็นคนขี้ฉลาดและเป็นคนโง่

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

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

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

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

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

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

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

ประโยชน์จะเป็น:

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

มีปัญหาร้ายแรงหลายอย่างที่ทำให้ฉันคิดว่าฉันจะไม่ใช้สิ่งนี้ในปีหน้า

• ความจำเพาะของโซลูชั่นระยะไกล สิ่งที่เกี่ยวกับการทำงานอย่างห่างไกลโดยใช้หน้าจอคอมพิวเตอร์หลายหน้าพร้อมกัน? ฉันหมายถึงมันง่ายไหม ชัดเจนหรือไม่ ปุมลัดที่ฉันใชเปดทํางานรายวันเมื่อทำงานระยะไกลหรือไม ผมไม่แน่ใจ. ถ้าฉันกด Ctrl + Shift + Esc เพื่อดูรายการโปรแกรมที่กำลังทำงานอยู่ โอ้ใช่มันไม่ทำงานดังนั้นตอนนี้ฉันต้องจำไว้ว่าทำมันในวิธีที่แตกต่าง

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

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

• ต้นทุนฮาร์ดแวร์ หากเป็นเซิร์ฟเวอร์เดียวและเซิร์ฟเวอร์เดียวจะมีค่าใช้จ่ายเท่าใด ถ้าคุณมีสมมุติว่ายี่สิบนักพัฒนา RAM 64 GB บนเซิร์ฟเวอร์จะเพียงพอหรือไม่ ไม่แน่ใจ โซลูชัน quad-core ที่มี CPU สองตัวจะเพียงพอหรือไม่ อีกครั้งฉันมีข้อสงสัย มิฉะนั้นคุณคิดอย่างไรเกี่ยวกับ เมฆบางประเภท หรือคุณมีโซลูชันที่ปรับขนาดได้ซึ่งทำงานบนเซิร์ฟเวอร์หลายเครื่อง? คุณพร้อมที่จะจ่ายค่า Windows Server (ถ้าคุณใช้ Windows) ต่อเครื่องหรือไม่?

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

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

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

เราใช้อินสแตนซ์ amazon ec2 ตามความต้องการเป็นเครื่องพัฒนา สิ่งนี้ไม่เกี่ยวกับต้นทุน เรามี "กลุ่มนักพัฒนา" ที่ทำงานในหลายโครงการและเราต้องการความสามารถในการย้ายข้ามโครงการอย่างรวดเร็ว

โดยทั่วไป VM จะช่วยประหยัดเวลาในการตั้งค่าเริ่มต้น แต่ในระยะยาวมันเสียเวลาเนื่องจากการสูญเสียผลผลิต ค่าใช้จ่ายไม่ใช่แกนเนื่องจากต้นทุนของนักพัฒนาซอฟต์แวร์นั้นมากกว่าต้นทุนของเครื่องจักร

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

ในหนึ่งในโครงการของเราเรา refactored รหัสเพื่อลดความซับซ้อนของการตั้งค่าเริ่มต้นเป็น "รหัสดาวน์โหลดและเรียกใช้ maven" ด้วยการเปลี่ยนแปลงนี้มันเป็นเรื่องง่ายสำหรับนักพัฒนาใหม่ที่จะเริ่มทำงานในโครงการและตอนนี้ไม่มีใครใช้อิมเมจ amazon VM เราต้องการเลียนแบบสิ่งนี้ในโครงการอื่นเช่นกัน แต่ต้องใช้เวลา จนถึงตอนนี้เรามีภาพ ec2 ของเรา

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

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

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

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

การพัฒนาบนเครื่องเสมือนสามารถทำงานได้ค่อนข้างดี แต่ถ้าทำถูกต้อง:

• การใช้ VMs ช่วยให้คุณมีคอมพิวเตอร์เครื่องเดียวสำหรับทีมของคุณมากกว่าหนึ่งรายการต่อนักพัฒนาไม่ได้หมายความว่าเป็นความคิดที่ดี
• การเริ่มระบบใหม่ไม่ควรต้องเปิดตั๋วสนับสนุนพร้อมเวลาตอบกลับ 24 ชั่วโมง
• การพัฒนา VMs ไม่ควรอยู่ในดาต้าเซ็นเตอร์ 5,000 ไมล์ห่างจากนักพัฒนา
• แม้ว่า VMs อาจได้รับการจัดการโดยผู้พัฒนาและไม่ได้รับการสนับสนุนซึ่งไม่ได้หมายความว่าพวกเขาไม่สามารถเข้าถึงบริการเครือข่ายเช่นการควบคุมแหล่งที่มา
• การเชื่อมต่อเดสก์ท็อประยะไกลควรเป็นแบบมาตรฐานไม่ใช่แอปเพล็ต "ความปลอดภัยสูง" แบบกำหนดเองที่แปลงคำพูดใด ๆ ที่พิมพ์ลงใน umlauts
• รับ VM ใหม่หรือสร้างใหม่ที่มีอยู่ควรใช้เวลานาทีไม่ใช่สัปดาห์

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

ฉันทำงานกับ VM แต่ไม่แนะนำสำหรับโครงการหลักของคุณ

เหตุผลที่ฉันใช้ VMs สำหรับการพัฒนาเป็นเพราะฉันต้องสนับสนุนโครงการดั้งเดิม (เช่น VB6, .NET 1.1 ฯลฯ ) และฉันไม่ต้องการสกปรกเครื่องหลักของฉันโดยต้องติดตั้ง VS2003 / 2005 / vb6 / etc ... มันใช้ได้ดี แต่ก็มีปัญหาเป็นระยะ ๆ ที่นี่และที่นั่น

นอกจากนี้การโต้ตอบจะช้าลง VMs ใช้เวลาสักครู่ในการเริ่ม / ปิดไม่มีเอฟเฟกต์ UI ดั้งเดิม (เช่น Aero ใน Win7) ฯลฯ ...

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

กฎการพัฒนาอันดับ 1 คือการทำให้นักพัฒนาซอฟต์แวร์ของคุณมีความสุข คุณจะพบว่าใกล้เป็นไปไม่ได้ที่จะทำกับ VMs ระยะไกล การสนับสนุนหลายจอภาพนั้นขาด ๆ หาย ๆ ความล่าช้าของเครือข่ายและการข้ามเป็นไปอย่างลำบากและประหยัดค่าใช้จ่ายน้อยที่สุด

ทำงานบน VMs ได้แน่นอน แต่อนุญาตให้ใช้ VM ท้องถิ่นได้เช่นกันและทำให้คอมพิวเตอร์ที่มีอยู่จริงเป็นสัตว์ร้ายที่รวดเร็วเช่นกัน

ฉันโทรคมนาคม 100% และระหว่าง ISP ส่วนบุคคลและ VPN - แม้จะมีความน่าเชื่อถือสูง - พวกเขามีการส่งสัญญาณมากพอที่จะทำให้ฉันบ้าถ้าฉันไม่สามารถทำงานในโหมดออฟไลน์

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

ทีมของฉันติดตั้งการกำหนดค่า "เซิร์ฟเวอร์ช้า / VM VM" สำหรับทีมนักพัฒนา 20 คนเรามีโปรเซสเซอร์ 8 ตัว, เซิร์ฟเวอร์ RAM 256GB ที่เชื่อมต่อผ่านไฟเบอร์กับ SAN ที่รวดเร็วมาก มันมีราคาแพง แต่ถูกกว่าการให้เวิร์คสเตชั่นที่มีประสิทธิภาพใกล้เคียงกัน สำหรับทีมเล็ก ๆ (นักพัฒนา 4 คน) ฉันไม่แน่ใจว่าการประหยัดจากขนาดจะช่วยให้คุณประหยัดได้จริง

VMs สำหรับการพัฒนามีค่าดู แต่ค่าใช้จ่ายทางการเงินเป็นเหตุผลที่ผิด

สิ่งนี้ได้รับการกล่าวถึงอย่างสั้น ๆ ในการจัดส่ง Expert .NET ของ Marc Holmes โดยใช้ NAnt & CruiseControl.net - กล่าวโดยย่อว่าอาร์กิวเมนต์สำหรับการพัฒนาบน VM คือมันไม่สนับสนุนลักษณะของงานใด ๆ คุณทำ VM ของคุณในตอนเริ่มต้นของทุกโปรเจ็กต์และถ้าคุณไม่ต้องการเครื่องมือเฉพาะจริง ๆ มันจะไม่ทำให้คุณสะดุด สิ่งนี้จะลดความเป็นไปได้ที่การเปลี่ยนแปลงที่คุณทำจะทำให้เครื่องของใคร ๆ นักพัฒนาอาจร้องไห้เมื่อนำของเล่นของพวกเขาไป - แต่ท้ายที่สุดการพึ่งพาเครื่องมือเป็นจุดอ่อนและสิ่งใดก็ตามที่คุณไม่สามารถทำได้อย่างง่ายดายในสภาพแวดล้อมที่สะอาดคือกลิ่น

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

ข้อเสียที่อาจเกิดขึ้น

• ถ้าโฮสต์ VM ล่ม ... คุณทั้งหมดถูกโฮส หากคุณเคยมีทีมงาน 20 คนตะโกน "GAH! HOST NOT RESPONDING !?" ในเวลาเดียวกัน ... มันไม่สนุก
• หากคุณอนุญาตสแนปชอต ... ผู้ที่กินทรัพยากรหมดเร็ว 20 คน * 10-20 สแนปชอตแต่ละภาพทำให้มีพื้นที่ HDD จำนวนมาก (หรืออย่างน้อยก็เพียงพอที่จะทำให้เกิดปัญหา)
• หากคุณประสบปัญหาเกี่ยวกับการใช้ทรัพยากรบนโฮสต์อีกครั้งทุกคนประสบกับความเจ็บปวด

IME เป็นวิธีแก้ปัญหาที่ดีและใช้งานได้ แต่คุณต้องการฮาร์ดแวร์ที่เหมาะสมในโฮสต์และเมื่อสิ่งเลวร้ายเกิดขึ้นพวกเขาก็เกิดขึ้นกับทุกคน

สิ่งนี้ล้มเหลวหนึ่งในเกณฑ์ที่สำคัญที่สุดของการทดสอบ Joel

ฉันตรวจสอบให้แน่ใจว่านักพัฒนาซอฟต์แวร์ทั้งหมดของฉันมีอย่างน้อย i3 หรือแล็ปท็อปหรือเดสก์ท็อปที่ดีกว่าที่มี RAM มากที่สุดเท่าที่จะทำได้

8GB เป็นสิ่งที่ฉันมุ่งมั่น

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

นักพัฒนาต้องการเครื่องจักรที่เร็วที่สุดใน บริษัท พร้อมกับสิทธิ์ RAM และรูทส่วนใหญ่ในเครื่องของพวกเขา ตอนจบของเรื่อง.

ฉันเคยทำงานกับ VMs มาก่อนเพื่อการพัฒนาทั้ง VM ท้องถิ่น (ทำงานบนพีซีท้องถิ่น) และรีโมทระยะไกล คนในท้องถิ่นมีมากดีกว่าที่จะทำงานกับกว่าคนที่ห่างไกล

Remote VMs ที่เราเชื่อมต่อด้วยโดย RDP มีความล่าช้าเล็กน้อยระหว่างทุกการกดแป้นพิมพ์และการกระทำ เป็นไปได้ที่จะพัฒนาภายใต้เงื่อนไขดังกล่าวในช่วงเวลาสั้น ๆ แต่การออกไปข้างนอกในแต่ละวันมันน่าผิดหวังมาก

ฉันพัฒนาอย่างมีความสุขภายใต้ VM ท้องถิ่นบน VMWare เพราะฉันต้องการเรียกใช้ Flash Builder บนเครื่อง Linux และค่อนข้างมีความสุขกับมันตราบใดที่มีหน่วยความจำเพียงพอ - มันค่อนข้างใช้งานได้

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

ในงานสุดท้ายของฉันเราทำอย่างนั้น:

เราใช้ Windows Terminal Server ซึ่งนักพัฒนาซอฟต์แวร์ทุกคนมีบัญชี นักพัฒนายังคงมีพีซีปกติ (เพราะพวกเขาอยู่ที่นั่นแล้ว) แต่พีซีก็วิ่งไคลเอนต์ RDP เท่านั้น

เราทำการพัฒนา Java ดังนั้นซอฟต์แวร์ที่ใช้โดยที่ Java คอมไพเลอร์ + IDE (ส่วนใหญ่เป็น Eclipse) รวมถึงเว็บเบราว์เซอร์เครื่องมือค้นหา DB ไคลเอนต์ควบคุมเวอร์ชันและสำนักงาน sw (OpenOffice.org ในกรณีของเรา)

เราไม่พบปัญหาจริงใด ๆ และประสิทธิภาพค่อนข้างดี

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

ดังนั้นข้อแม้คือ: ประเมินประสิทธิภาพโดยเร็วที่สุดและวางแผนฮาร์ดแวร์และการใช้งานให้เหมาะสม

TL; DR:ฉันทำไปหลายงานแล้วตอนนี้ฉันชอบมันมาก

ค่าใช้จ่ายเป็นเหตุผลที่ผิดที่จะมุ่งเน้น นี่คือบางส่วนที่ดีกว่า

เหตุผล

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

ความท้าทาย

ความท้าทายอันดับหนึ่งคือการพัฒนาทางไกลโดยเฉพาะถ้าคุณต้องผ่านเกตเวย์หรือเซิร์ฟเวอร์กระโดด มันทำให้เป็นเรื่องยากโดยเฉพาะอย่างยิ่งหากนักพัฒนาไม่ได้กลม (พวกเขามีความรู้ด้านวิศวกรรมระบบความรู้ด้านระบบเครือข่ายและอื่น ๆ )

มีการพัฒนาระยะไกลหลายรูปแบบ แต่โดยทั่วไปแล้วพวกมันจะต้มถึง 2 ความแตกต่างหลัก

• เรียกใช้เครื่องมือในการพัฒนาของคุณในสภาพแวดล้อมระยะไกลและใช้โปรโตคอลเช่นไคลเอนต์ RDP ไคลเอนต์ X11 ระยะไกล ฯลฯ
• เรียกใช้เครื่องมือในการพัฒนาของคุณในพื้นที่และใช้โปรโตคอลเพื่อซิงค์หรือดำเนินการบนเซิร์ฟเวอร์ระยะไกลอย่างโปร่งใสมักใช้ ssh เป็นเลเยอร์การขนส่ง

เครื่องมือ

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

• Secure Shell:การตั้งค่าการพัฒนาระยะไกลที่ประสบความสำเร็จส่วนใหญ่ใช้ ssh ในระดับที่สูงขึ้นโดยใช้การล็อกอินแบบไม่ใช้รหัสผ่าน (ใช้การตรวจสอบความถูกต้องของคีย์), มัลติฮ็อปโปร่งใส (แก้ปัญหาเซิร์ฟเวอร์กระโดด) และตัวเลือกการกำหนดค่าอื่น ๆ หมายเหตุ: ฉันมักจะมีปัญหาในการใช้งาน SSH ที่ไม่ใช่ของ OpenSSH
• หน้าจอ GNU / TMUX:เทอร์มินัลมัลติเพล็กเซอร์ หน้าจอเป็นหลานของพวกเขาและยังคงแข็งแกร่ง แต่ฉันคิดว่าคนส่วนใหญ่เริ่มเปลี่ยน (หรือเริ่มต้น) บน TMUX
• Vim / Emacs : การ์ดเก่า แต่ทั้งคู่ทำงานได้ดีสำหรับการพัฒนาทางไกลในรูปแบบที่ต่างกัน มันเป็นกลุ่มดังนั้นสิ่งที่จำเป็นต้องมีก็คือเชลล์ในขณะที่ Emacs สามารถเรียกใช้ในพื้นที่และใช้ TRAMP สำหรับการพัฒนาจากระยะไกล

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

สิ่งนี้จะขึ้นอยู่กับว่าคุณมีพลังงานในการติดตั้ง VMware มากน้อยเพียงใดหากคุณใส่พูลย่อยที่มีลำดับความสำคัญต่ำคุณจะมีเครื่องจักรช้าขึ้นอยู่กับกิจกรรมของพูลย่อยอื่น ๆ

ฮาร์ดแวร์ราคาถูกโปรแกรมเมอร์มีราคาแพง

เหตุใดคุณจึงต้องการให้โปรแกรมเมอร์ของคุณผิดหวังด้วยการให้เครื่องพัฒนาช้า ค่าใช้จ่ายในการอัพเกรด pales ฮาร์ดแวร์เมื่อเทียบกับผลประโยชน์ด้านประสิทธิภาพที่จะได้รับ

ขอเครื่องจักรที่ดีกว่านี้ อย่างน้อยที่สุดขอ ram 4 gb การเพิ่มแท็บเล็ต 2gb อีกครั้งจะได้รับในเวลาน้อยกว่าหนึ่งสัปดาห์

การขาดการสนับสนุนสองหน้าจอเป็นตัวจัดการข้อตกลงมาตลอด ฉันไม่สามารถจินตนาการได้ว่าการพัฒนาที่สำคัญจะทำงานบนหน้าจอเดียว

ตอนนี้พวกมันใช้สำหรับการทดสอบ / ปรับใช้ / เล่นซอดังนั้นฉันไม่คิดว่าพวกเขาควรจะตกจากสแต็ค

หากคุณมีเมนเฟรมที่มีดิสก์ SSD 50 ตัวใน RAID10 และใช้งานเพียง 3-4 เครื่องบนเมนเฟรมนั้นก็อาจทำงานได้

มิฉะนั้นมันจะล้าหลัง, ล้าหลังจริงๆ (แม้ว่าในบางกรณีที่หายากการถ่ายภาพสแนปชอตสามารถชดเชยได้)

ฉันมีเครื่องเดสก์ท็อปที่เหมาะสมที่สำนักงานซึ่งฉันสามารถเชื่อมต่อจากแล็ปท็อปของฉันผ่าน VPN โดยใช้การแชร์หน้าจอ

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

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

ความหน่วงแฝงและการมองเห็นอสังหาริมทรัพย์เป็นตัวสังหารสองคนสำหรับฉัน

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

เราพัฒนาบน iMacs ซึ่งดีจริง ๆ แต่เว็บแอปพลิเคชันของเราทำงานบนสภาพแวดล้อม Linux ในการผลิต ปัญหานี้คือในที่สุดเราอาจพบปัญหาที่เกิดขึ้นบน Linux เท่านั้นและอาจแก้ไขปัญหาได้ยาก นั่นคือสิ่งที่พลังของเครื่องเสมือนมา แต่ฉันไม่ชอบความคิดในการใช้ VM 100% ของเวลา

ฉันเพิ่งเรียนรู้เกี่ยวกับ Vagrant (http://vagrantup.com/docs/getting-started/why.html) และ Chef สำหรับการทำงานกับ VirtualBox อย่างง่ายดาย Vagrant ช่วยให้คุณสามารถเริ่มต้น VM ได้อย่างง่ายดายเมื่อคุณต้องการและทำลาย VM เมื่อคุณไม่ต้องการ ดังนั้นฉันสามารถพัฒนาทุกอย่างได้โดยใช้ Mac จากนั้นเมื่อฉันพร้อมที่จะทดสอบโค้ดของฉันฉันสามารถเริ่มต้น VM เพื่อทดสอบมันและเก็บไว้นานเท่าที่ฉันต้องการ Vagrant ยังช่วยให้คุณสามารถแชร์ VMs กับเพื่อนร่วมงานของคุณได้อย่างง่ายดายเพื่อให้คุณมั่นใจได้ว่าคุณกำลังทำงานในสภาพแวดล้อมเดียวกัน

ฉันขอแนะนำให้ตรวจสอบ Vagrant เพื่อที่คุณจะได้ทราบอย่างน้อยตัวเลือกที่มีอยู่เมื่อมันมาถึงการพัฒนาและการทำงานกับ VMs

ฉันทำงานเกี่ยวกับโครงการดั้งเดิมที่เกี่ยวข้องกับ 5 เครื่องแต่ละเครื่องมีบทบาทในการคำนวณไปป์ไลน์ (เครื่อง 1 ส่งการร้องขอไปยังเครื่อง 2 ซึ่งจะส่งคำขอไปยังเครื่อง 3 ฯลฯ ) การปรับใช้การตั้งค่าบนเครื่องเสมือนช่วยให้เราประหยัดเวลาได้อย่างมากอย่างไรก็ตาม: 1. ระบบไม่สามารถเอาชนะได้เนื่องจาก devs ขี้เกียจ / ไม่มีเวลาที่จะรวมการทดสอบในการออกแบบ 2. มีการตั้งค่ามากเกินไปและฉันต้องใช้เวลาในการจัดเรียงเป็นกลุ่ม

ตอนนี้ฉันใช้เพราะฉันทำงานหลายโครงการพร้อมกัน ปัญหาหลักที่ฉันมีอยู่ในขณะนี้: 1. VMs ใช้เวลาในการบำรุงรักษานานเกินไป 2. VMs ใช้หน่วยความจำจำนวนมหาศาลในการรัน

kinda นี้ทำให้ VMs ใช้งานยากเมื่อคุณพยายามใช้เพื่อให้มีคำสั่ง เก็บหนึ่งเครื่องหลักด้วยอีเมลและข้อความของคุณพัฒนาบน dediacated VMs ทำให้ชีวิตของคุณเรียบร้อยและสะอาดด้วยค่าใช้จ่าย

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

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

ยังไม่แน่ใจว่านี่เป็นวิธีที่ถูกต้องหรือไม่ แต่เป็นที่ที่เรามุ่งหน้าไป