Một máy phát triển có nên nằm trong VM không? [đóng cửa]

Bài đăng này của Rob Conery (lưu ý con sên) nói rằng môi trường phát triển nên được chạy bên trong một máy ảo. Tôi thấy những gì anh ấy nói và có xu hướng đồng ý, nhưng vẫn cảm thấy hơi khó chịu. Bây giờ ảo hóa đã trưởng thành đến mức ngay cả các hệ thống sản xuất chạy bên trong tốc độ VM cũng không phải là vấn đề, nhưng như tôi nói điều gì đó làm phiền tôi ở đây.

Những gì bạn có trên ảo hóa máy phát triển của bạn? Bạn đã làm như vậy? Nếu bạn đã làm, bất kỳ cạm bẫy hoặc gotchas dọc đường?

Kinh nghiệm của tôi khi phát triển máy ảo trong môi trường doanh nghiệp là do ảo hóa nhiều lõi gặp nhiều khó khăn, rất khó để có được hiệu năng mà nhiều máy phát triển doanh nghiệp cần.

Để vòng lặp bên trong kiểm thử biên dịch mã trở nên nhanh nhất có thể đòi hỏi các máy tốt nhất có thể - biên dịch và chạy thử nghiệm rõ ràng chạy nhanh hơn trên các máy có nhiều lõi hơn, vì các hoạt động đó có thể được thực hiện khá dễ dàng theo cách đồng thời * .

Cho đến khi các hệ điều hành phát triển chính có thể xử lý số lượng lõi khả dụng là không ổn định và cho đến khi phần mềm ảo hóa có thể cung cấp một số loại hợp đồng "lên đến lõi N" một cách thông minh, các máy phát triển ảo sẽ không cung cấp loại lợi nhuận tương tự như các thiết bị vật lý.

EDIT: Điều này chỉ kể lại cảm xúc cá nhân của tôi về việc phát triển bằng cách sử dụng các máy ảo do công ty quản lý, thường bị cấm để cắt giảm chi phí phần cứng, có xu hướng chạy trên máy chủ. Chạy một máy ảo cục bộ dường như hầu như không cần thiết, miễn là bạn thi hành kỷ luật kiểm soát nguồn tốt, trừ khi dự án của bạn đặc biệt yêu cầu bạn phát triển mã cho nhiều HĐH.

*: theo ý tôi, các nhiệm vụ bên trong các giai đoạn biên dịch và các giai đoạn thử nghiệm có thể được chạy đồng thời, KHÔNG được biên dịch và kiểm tra đồng thời :)

Tôi làm tất cả sự phát triển cá nhân của tôi trong VM. Tôi có một số thiết lập VM cho các môi trường khác nhau và nó hoạt động tốt.

Tôi có một máy tính xách tay dell studio 15 (quad I7 2.8ghz, ram 8gb, đồ họa ati) đang chạy win 7 Ultimate 64bit với cài đặt hộp ảo. Tôi có tất cả các máy ảo của mình đang chạy một ổ USB 500gb bên ngoài được chuyển sang máy tính xách tay.

VM 0 - Cài đặt sạch Win 7 64 bit làm mẫu cơ sở

VM 1 - Win 7 64 bit (2 cpu, ram 4gb, 120gb hd) với bộ công cụ Visual Studio 2008

VM 2 - Win 7 64 bit (2 cpu, ram 4gb, 120gb hd) với bộ công cụ Visual Studio 2010

VM 3 - Win 7 64 bit (2 cpu, ram 2gb, 120gb hd) với bộ công cụ Java Eclipse

Trừ khi tôi đang làm một cái gì đó đòi hỏi IO rất cao, tôi cảm thấy rằng hiệu suất là tốt và tôi sẽ không biết tôi đang ở trong máy ảo nếu ai đó vừa đưa cho tôi máy tính xách tay và nói bắt đầu phát triển.

Tôi muốn thêm rằng một số loại phát triển nhất định khó khăn hơn nhiều (nếu không nói là không thể) thông qua các máy ảo hóa.

Tôi tình cờ làm việc tại một công ty nơi chúng tôi cung cấp các gói phần mềm tích hợp với một số thiết bị ngoại vi USB khác nhau (Ví dụ: webcam, máy in nhãn, đầu đọc sọc từ, v.v.). Ngay cả khi tôi ánh xạ các cổng USB đến một máy chủ ảo hóa, tôi đã nhận thấy những vấn đề kỳ lạ và không thể giải thích được với trình điều khiển thiết bị của nhà cung cấp bên thứ ba.

Như tôi đã nói, tôi không nghĩ rằng tình huống này đảm bảo KHÔNG làm việc trên các máy phát triển được virut hóa, tuy nhiên đó là một trong những điều mà chúng tôi chưa tìm ra, do đó chúng tôi duy trì các máy trạm vật lý cho các môi trường khác nhau trong phòng thí nghiệm.

Trong công ty của chúng tôi, chúng tôi hiện đang sử dụng VM để phát triển và thử nghiệm. Mặc dù có một số hạn chế khi sử dụng VM nhưng lợi ích của chúng vượt xa chúng.

Trước khi chúng tôi bắt đầu sử dụng VM, chúng tôi đã gặp vấn đề với việc thiết lập các máy phát triển cho các nhà phát triển mới. Nhiệm vụ đầu tiên cho nhà phát triển mới trong nhóm thường là thiết lập bộ máy phát triển của riêng mình. Chúng tôi là một công ty nhỏ và chúng tôi không có nhân lực để giúp các thành viên mới trong nhóm thiết lập máy của họ. Điều này dẫn đến các vấn đề khác nhau: đôi khi lỗi chỉ có thể tái tạo trên máy của họ hoặc họ không thể sao chép được, ứng dụng không thể xây dựng chính xác, v.v. Ngoài ra còn có một vấn đề là một số nhà phát triển cao cấp của chúng tôi đang làm việc trên nhiều dự án trên môi trường làm việc không phải lúc nào cũng tương thích.

Khi chúng tôi chuyển sang VM, mọi thứ đã thay đổi. Bây giờ chỉ có một người chịu trách nhiệm thiết lập môi trường trong VM với mọi thứ liên quan đến dự án. Khi anh ta kết thúc, tất cả các thành viên trong nhóm được cung cấp bản sao của VM. Điều này giúp giảm thời gian thiết lập môi trường cho mọi thành viên nhóm mới (sao chép VM không nên mất hơn 1h). Nó cũng cho phép chúng ta làm việc trên nhiều môi trường làm việc song song.

Hạn chế của việc sử dụng VM: tốc độ. Hiệu năng đạt được trên VM có thể nhìn thấy. Trên các máy trạm chậm hơn nó có thể làm cho sự phát triển gần như không thể. Nếu bạn có một máy trạm tốt (lõi tứ, RAM 8 + GB, SSD), bạn có thể sẽ không nhận thấy điều đó.

Như những người khác đã đề cập, nó phụ thuộc vào một số điều:

• Môi trường của bạn trông như thế nào?
• Bạn có đủ quyền truy cập để phát triển không?
• Là CTNH của bạn lên để hít?

Xung quanh

Sử dụng VM có thể giúp ích nếu bạn đang làm việc trên nhiều phiên bản của một dự án; nhiều dự án; hoặc nhắm mục tiêu một hệ điều hành khác với hệ điều hành bạn thường chạy (hệ điều hành máy chủ). Tôi làm rất nhiều công việc SharePoint và có thể chạy một máy khác cho các phiên bản phát hành khác nhau rất hữu ích vì tôi có thể khởi động một máy khác và có cảm giác tốt về trạng thái của cơ sở dữ liệu GAC /. Ngoài ra nếu bạn cần nhắm mục tiêu môi trường ứng dụng * nix nhưng có máy Windows thì bạn vẫn có thể phát triển trong máy ảo (đây là cách tôi học Ruby ở nhà mặc dù tôi thường làm .NET dev hoạt động). Tôi thường ủng hộ khi thực hiện kiểm tra / phát triển ASP.NET trên cùng một phiên bản IIS mà ứng dụng cuối cùng sẽ chạy theo (điều này cũng hợp lý áp dụng cho các môi trường đích máy chủ khác). Tùy thuộc vào phiên bản HĐH, có thể có một số khác biệt nhỏ nhưng quan trọng. Lưu ý rằng điều này không có nghĩa là bạn nên mã hóa một phiên bản cụ thể của IIS / OS nhưng hãy trung thực, nó thực sự phải hoạt động khi bạn sẽ triển khai nó không chỉ trên máy cục bộ của mình.

VM cũng (tùy thuộc vào phần mềm được sử dụng) cho phép bạn chụp ảnh nhanh về trạng thái máy hiện tại và / hoặc sao chép chúng. Điều này có thể là vô giá khi tạo mẫu một cái gì đó và bạn không phải lo lắng về những gì đang xảy ra trong GAC / Registry / v.v. Tôi cũng thấy chúng rất có giá trị trong việc thiết lập bản demo cho khách hàng trước thời hạn. Vì môi trường demo nằm trong máy ảo, tôi có thể tiếp tục làm việc cho đến khi hiển thị cho khách hàng những gì chúng tôi đã hoàn thành vì tôi đang làm việc trong một máy khác .

Đủ quyền

Điều này thường áp dụng cho những người làm việc cho một công ty có bộ chính sách khá mạnh mẽ về quyền truy cập. Nếu bạn không thể có quản trị viên trong máy của mình, đây sẽ là thời điểm tốt để làm việc trong máy ảo. Thông thường, các quyền hạn chỉ lo lắng về việc khóa hệ điều hành máy chủ của bạn, khách có thể mở rộng (quyền khôn ngoan). Tôi đã gặp phải các vấn đề kỳ lạ với hồ sơ chuyển vùng, quyền quản trị bị tê liệt và chạy VS 2010; sử dụng VM cho phép tôi tránh những vấn đề này.

Là CTNH của bạn lên để hít?

Điều này giúp giảm bớt hình ảnh VM của bạn trên máy chủ và điều khiển từ xa vào chúng HOẶC bạn chạy chúng cục bộ. Nếu bạn đang chạy trên máy chủ thì mối quan tâm lớn nhất có lẽ là sẽ có quá nhiều VM chạy trên cùng một phần cứng. Về cơ bản, về cơ bản bạn muốn có nhiều RAM và để giảm thiểu tần suất bạn làm quá tải bộ đệm R / W cho ổ cứng. Để phát triển LOB / SharePoint / ASP.NET cơ bản, tôi đã thấy rằng tối thiểu 8 GB RAM và cấu hình ổ cứng kép hoạt động tốt trong thực tế (chạy i5 nhưng tôi cũng đã làm việc với Core 2). Ổ cứng thứ hai tạo ra sự khác biệt lớn nhất về hiệu suất.

Lưu ý: Tôi không có bất kỳ số liệu thống kê nào để sao lưu điều này nhưng tôi nhận thấy rằng Virtual PC có xu hướng hoạt động kém hơn so với cả VMWare và Virtual Box. Tôi không thể nói chuyện với Hyper-V vì tôi đã không làm việc với nó. Tôi sẽ không ngạc nhiên nếu sử dụng Virtual PC (như một bước đột phá ban đầu khi sử dụng VM) đã khiến các nhà phát triển sử dụng phần mềm ảo hóa.

Như thường lệ: nó phụ thuộc. Ví dụ, tôi chắc chắn sẽ không đề xuất nó cho bất kỳ sự phát triển liên quan đến trò chơi máy tính hoặc thời gian thực nào.

Trải nghiệm cá nhân của tôi: Tôi có một iMac cuối năm 2009 và tôi thấy rằng Visual Studio 2010 về cơ bản không thể sử dụng được trong Parallels Desktop, đến mức việc nhấn một phím trong trình chỉnh sửa mã chỉ mất vài giây để đăng ký. Windows trong SQL Server Management Studio sẽ làm mất nét và chuyển trọng tâm rõ ràng một cách ngẫu nhiên. Tôi vừa mới kết thúc với trại khởi động.

Tất nhiên, một dự án mới của tôi sẽ liên quan đến một ứng dụng iOS với công cụ cấu hình dựa trên Windows, vì vậy có thể quá đau đớn khi không sử dụng ảo hóa, nhưng nếu công nghệ ảo hóa máy tính để bàn đã không di chuyển đủ trong năm ngoái hoặc lâu hơn, Có lẽ tôi sẽ chỉ thiết lập một máy tính để bàn khác ở đây.

Khi nói đến việc thử nghiệm một ứng dụng máy chủ, đó là một tình huống khác, tôi hoàn toàn vui khi ảo hóa điều đó, nhưng tôi cần sự đáp ứng trong các ứng dụng phát triển của mình.

Tôi đã sử dụng máy ảo để phát triển và nói chung, nó không khác nhiều so với phát triển trên máy của riêng tôi. Nếu bạn đang sử dụng Kiểm soát nguồn đúng cách, sẽ không có nhiều khác biệt.

Sự khác biệt chính là nếu bạn ngoại tuyến vì bất kỳ lý do gì bạn không có sẵn máy phát triển, vì vậy sẽ không tuyệt vời nếu bạn đi du lịch hoặc làm việc ở nhà nhiều. Ngoài ra, tôi chưa bao giờ tìm ra cách chạy nhiều màn hình trên Remote Desktop, nhưng tôi chắc chắn đó là lỗi của tôi chứ không phải là vấn đề với nguyên tắc này. Tôi thường sử dụng màn hình chính để phát triển và giữ màn hình thứ hai cho máy tính để bàn của mình với email, trình duyệt, v.v.

Tôi sẽ nói thêm rằng nếu bạn đang làm việc theo cách bạn cần kiểm tra mã của mình hoạt động trên các nền tảng khác nhau - đặc biệt là những thứ như phát triển trình cài đặt - thì việc có thể chạy VM cho các phiên bản HĐH khác nhau rất tiện dụng.

Tôi đã sử dụng chúng tại công ty trước. Một số điều khiển của bên thứ ba không cùng tồn tại với các phiên bản khác của cùng một công ty. Tôi cũng đã sử dụng một vài để thử nghiệm và gỡ lỗi các hệ điều hành khác (XP vs Vista vs 7). Một ảo có VB6 và VS2003 cho các sản phẩm cũ. Vâng, trên máy của một nhà phát triển thông thường, nó có thể chậm và cồng kềnh, nhưng tôi đã có một vài ổ cứng dự phòng mà tôi "tặng" và đặt ảo trên ổ cứng của riêng họ trên bộ điều khiển ổ đĩa của riêng họ. Tôi là người cuối cùng tiếp tục sử dụng ảo và đối với một số lỗi, chỉ tôi mới có thể làm việc với chúng (do mối quan tâm về hệ điều hành và thành phần).

Một số kẻ đã bị cài đặt phần mềm beta và một số betas từ MS không thể bị xóa, vì vậy họ buộc phải sử dụng ảo cho đến khi họ định dạng lại ổ cứng.

Để phát triển ảo, lời khuyên của tôi là lấy một cái gì đó với RAM tối thiểu 8GB. 16 trở lên sẽ tốt hơn, vì bạn sẽ thấy bất kỳ phòng thu trực quan nào được trang bị nhu cầu ảo khoảng 1,5 GB RAM của máy chủ để chạy ở tốc độ trên "băng hà". Ngoài ra, nhận được nhiều ổ đĩa cứng khi mua máy tính. Đối với các ổ đĩa bạn chọn ra khỏi đống phần cứng dự phòng, hãy tìm những ổ có kích thước tối thiểu gấp đôi VHD bạn sẽ chạy.