Suy nghĩ về phát triển bằng máy ảo [đã đóng]

Tôi sẽ làm việc như một người lãnh đạo phát triển cho một công ty khởi nghiệp và tôi đã đề nghị chúng tôi sử dụng máy ảo để phát triển. Tôi không nói về mỗi nhà phát triển có máy tính để bàn có máy ảo để thử nghiệm / phát triển, ý tôi là có giá đỡ máy chủ nơi tất cả các máy ảo được quản lý và nhà phát triển làm việc từ microPC (ChromeOS có ai không?) Hoặc thậm chí từ xa từ nhà của họ máy vi tính.

Đối với tôi, lợi ích là thực tế là nó cực kỳ có thể mở rộng, rẻ hơn về lâu dài, dễ quản lý hơn và chúng tôi sử dụng phần cứng tiềm năng tối đa của nó. Về nhược điểm, tôi không thể nghĩ ra bất kỳ trình chiếu cụ thể nào ngoài việc chúng tôi sẽ cần ai đó thiết lập / duy trì thiết lập đã nói.

Tôi đã hy vọng rằng một số bạn có thể có một thiết lập tương tự tại nơi làm việc của bạn và có thể cân nhắc với ý kiến ​​của bạn. Cảm ơn.

Bạn đang hy vọng tiết kiệm được gì, như là một phần của ngân sách phát triển? Dường như với tôi rằng bạn đang lo lắng về một epsilon. Chi phí máy móc cho các nhà phát triển ít hơn 5% tổng chi phí để giữ chân một nhà phát triển. Do đó, câu hỏi quan trọng duy nhất là "nó có tiết kiệm thời gian cho các nhà phát triển không?" Nó có thể, nếu họ không phải dành thời gian cài đặt và nâng cấp phần mềm phát triển. Hoặc nó có thể tốn thời gian, nếu mạng ngừng hoạt động, hoặc máy chủ ngừng hoạt động, hoặc, rất có thể, nếu khả năng đáp ứng trên mạng là thiếu ít bit nhất. Sự phát triển hiện đại phụ thuộc vào tương tác gõ phím bằng cách gõ phím với IDE hoặc ít nhất là một trình soạn thảo rất thông minh. Trì hoãn sự tương tác đó thậm chí vài chục mili giây sẽ phá hủy năng suất của nhà phát triển. Ngoài ra còn có chi phí cho các nhà phát triển để học cách làm việc mới này.

Đây không phải là sự phản đối đối với máy ảo, mà là sự phản đối tiềm năng đối với sự phát triển từ xa.

Tôi nghĩ rằng bạn đang khôn ngoan và ngốc nghếch.

Trước hết, chi phí máy là không đáng kể so với chi phí của một nhà phát triển. Bạn nên làm việc tối đa hóa năng suất, không giảm thiểu chi phí máy.

Thứ hai, độ trễ (không phải băng thông) là chìa khóa cho nhiều tác vụ lập trình - đặc biệt là chỉnh sửa văn bản. Đối với mỗi đô la / pound / euro bạn tiết kiệm được cho máy móc cho các nhà phát triển của mình, bạn sẽ dành ít nhất mười lần nâng cấp mạng để duy trì năng suất thậm chí là hiệu quả - và thậm chí sau đó, họ có thể sẽ làm việc hiệu quả hơn nếu bạn tiết kiệm bằng cách cung cấp chúng với Pentium III mà bạn tìm thấy trong một thùng rác ở đâu đó.

Tôi cũng nghĩ rằng có một lợi ích đáng kể trong việc các nhà phát triển của bạn sử dụng một môi trường ít nhất là gần với mức mong đợi của người dùng cuối mục tiêu. Bất kể các mục tiêu hiệu suất chính thức trong một thông số kỹ thuật và như vậy, hầu hết các lập trình viên đều dựa khá nhiều vào cách mã "cảm nhận" khi họ kiểm tra nó. Khi họ sử dụng một môi trường hoàn toàn khác với người dùng cuối, họ có thể sẽ lãng phí thời gian vào những chuyện nhỏ nhặt trong khi hoàn toàn nhìn ra những vấn đề lớn.

Hấp dẫn như một môi trường đồng nhất âm thanh từ quan điểm hỗ trợ và như vậy, bạn thường nên khuyến khích càng nhiều sự đa dạng trong các máy của nhà phát triển càng tốt. Các nhà phát triển hiếm khi cần nhiều hỗ trợ và biết ngay lập tức khi bạn có mã sẽ thất bại với chip đồ họa, CPU, bộ điều hợp mạng, v.v., hơn là hoàn trả khoản đầu tư tối thiểu.

Điểm mấu chốt: nếu bạn đang viết mã dự định (ít nhất là chủ yếu) sẽ được sử dụng trong môi trường máy chủ ảo hóa, bạn chỉ cần cung cấp mã đó cho nhà phát triển của mình. Nếu bạn đang thực hiện nó để thử nghiệm, thì nó cũng có thể (nhưng không nhất thiết) có ý nghĩa cho sự phát triển. Tương tự như vậy, nếu bạn cần (hoặc ít nhất là có) một máy chủ và mạng được chỉ định quá mức nghiêm trọng, thì có thể có lợi khi tận dụng điều đó bằng cách sử dụng những gì bạn đã có sẵn.

Tuy nhiên, trong hầu hết các trường hợp điển hình, dường như điều này có khả năng đưa ra nhiều vấn đề hơn nó giải quyết.

Đó là một trong những ý tưởng của tôi trong quá khứ: có một máy chủ hiệu suất cao có tất cả các phần mềm cần thiết và một loạt các máy tính để bàn hiệu suất thấp sẽ chỉ được sử dụng để kết nối với máy chủ thông qua Remote Desktop.

Những lợi ích sẽ là:

• Các bản sao lưu vững chắc. Một số nhà phát triển có thể không muốn sao lưu máy tính để bàn của họ thường xuyên, vì vậy một giải pháp trung tâm sẽ đáng tin cậy hơn,
• Khả năng, cho mọi nhà phát triển, để làm việc từ bất cứ đâu. Bằng cách này, tôi cũng có nghĩa là làm việc từ bất kỳ PC nào trong công ty. Hãy nói vào buổi sáng, nhà phát triển muốn điều kiện làm việc im lặng. Anh ấy đi đến phòng riêng của mình và làm việc ở đó. Sau đó, anh ấy muốn làm một số lập trình cặp hoặc làm việc trong một môi trường xã hội nhiều hơn. Anh ta tắt máy tính để bàn của mình, đi đến một phòng khác có mười máy tính và kết nối từ đó. Không "Tôi phải tải lại tất cả các ứng dụng của mình".

Vâng, có một số vấn đề nghiêm trọng với điều đó, khiến tôi nghĩ rằng tôi sẽ không bao giờ sử dụng thứ như thế này trong những năm tới.

• Tính đặc hiệu của các giải pháp từ xa. Điều gì về làm việc xa bằng cách sử dụng một số màn hình máy tính cùng một lúc? Ý tôi là, nó có dễ không? Có rõ ràng không? Các phím tắt tôi sử dụng hàng ngày có được bật khi làm việc ở xa không? Tôi không chắc lắm. Nếu tôi nhấn Ctrl + Shift + Esc để xem danh sách các chương trình hiện đang chạy thì sao? Ồ vâng, nó không hoạt động, vì vậy bây giờ tôi phải nhớ làm theo cách khác.

• Hiệu suất đạt. Tôi không chắc chắn sẽ không có hiệu suất giảm ở tất cả. Và hãy nhớ rằng, một lập trình viên sử dụng máy tính chậm là một lập trình viên không hạnh phúc. Và công ty làm cho các lập trình viên của họ không hài lòng với các điều kiện tào lao sẽ không bao giờ sản xuất phần mềm chất lượng cao.

• Tác động cao hơn của một thảm họa. Bạn sẽ lưu trữ giải pháp trên một máy chủ dự phòng? Bạn có mạng dự phòng trong công ty của bạn? Giả sử bộ định tuyến bị hỏng và không dư thừa. Nó có nghĩa là tất cả các nhà phát triển hiện không thể làm việc. Ở tất cả. Bởi vì họ không cài đặt phần mềm cục bộ. Bởi vì họ thậm chí không có mã nguồn: nó trên máy chủ. Vì vậy, mọi người dừng lại và bạn đang trả tiền cho tất cả những người đó mỗi giờ chỉ để chờ bộ định tuyến được thay thế.

• Chi phí phần cứng. Nếu đó là một và một máy chủ duy nhất, nó sẽ có giá bao nhiêu? Nếu bạn có, giả sử, hai mươi nhà phát triển, liệu 64 GB RAM trên máy chủ có đủ không? Không chắc lắm. Giải pháp lõi tứ với hai CPU là đủ? Một lần nữa, tôi có một số nghi ngờ. Nếu không, bạn nghĩ gì về? Một số loại đám mây? Hay bạn có một giải pháp có thể mở rộng hoạt động trên một số máy chủ? Bạn đã sẵn sàng trả chi phí Windows Server (nếu bạn sử dụng Windows) cho mỗi máy chưa?

• Chi phí điện. Nếu bạn làm việc hoàn toàn từ xa, điều đó có nghĩa là bạn tiêu tốn gần một lượng điện năng phía máy chủ như thể bạn đang làm việc cục bộ, cộng với lượng điện năng bị lãng phí bởi máy cục bộ và mạng.

• Giấy phép. Tôi không chắc mình phải đặt nó như một lợi ích hay một vấn đề, nhưng tôi cảm thấy chi phí cấp phép phần mềm trong trường hợp này sẽ cao hơn nhiều.

Và một lần nữa, hãy nghĩ về tất cả các chi phí quản lý, hỗ trợ, triển khai, bảo trì. Với một giải pháp tùy chỉnh như thế này, nó có thể dễ dàng trở nên khổng lồ, không kể rằng mỗi khi có điều gì đó thất bại, bạn sẽ thấy mọi nhà phát triển NOPing xung quanh, chờ đợi để có thể tiếp tục công việc của mình.

Chúng tôi sử dụng các phiên bản amazon ec2 theo yêu cầu làm máy phát triển. Điều này không có gì để làm với chi phí. Chúng tôi có một "nhóm các nhà phát triển" làm việc trên một số dự án và chúng tôi cần khả năng di chuyển nhanh chóng qua các dự án.

Nói chung, VM tiết kiệm thời gian thiết lập ban đầu. Nhưng lâu dài, nó lãng phí thời gian do mất năng suất. Chi phí là một trục không, bởi vì chi phí dành cho nhà phát triển lớn hơn nhiều so với chi phí máy.

Chi phí năng suất bao gồm - thời gian để bắt đầu một hình ảnh VM (vài phút), khả năng phản hồi kém và các hạn chế về tài nguyên / bộ nhớ. Đây không phải là nhiều ban đầu, nhưng theo thời gian họ cảm thấy khó chịu.

Trên một trong các dự án của chúng tôi, chúng tôi đã cấu trúc lại mã để đơn giản hóa thiết lập ban đầu thành "tải mã và chạy maven". Với thay đổi này, thật đơn giản để một nhà phát triển mới bắt đầu làm việc với dự án - và bây giờ không ai sử dụng hình ảnh VM của amazon. Chúng tôi đang tìm cách mô phỏng điều này trên các dự án khác, nhưng nó sẽ mất thời gian. Cho đến khi, chúng ta có hình ảnh ec2 của chúng tôi.

Hãy cẩn thận ở đây. Gần đây tôi đã được triển khai cho một khách hàng nơi mọi người trong bộ phận CNTT có VM của họ vì lý do tương tự - để cho phép họ có các PC cấp thấp hơn trên bàn và sau đó từ xa vào VM và thực hiện công việc bình thường của họ.

Trải nghiệm ở đó không đẹp. Ít nhất một lần mỗi tuần chúng tôi đã chạy rất chậm vì nhiều lý do. Nói chung, chúng tôi có thể biết khi nào ai đó trong nhóm đang chạy một bộ gói SSIS chuyên sâu về bộ xử lý. Cuối cùng họ đã chuyển một vài người trong chúng ta sang các máy chủ khác nhau, điều này giúp ích cho một số người, nhưng hiệu suất không bao giờ đúng.

Tôi nghĩ rằng nếu bạn sẽ làm điều đó - hãy chăm chỉ vào sức mạnh máy chủ, nhu cầu xử lý của bạn, số lượng máy bạn sẽ phục vụ, v.v. Nó có thể giúp bạn tiết kiệm một số tiền, nhưng nếu không được triển khai chính xác, có thể gây ra RẤT NHIỀU đau đầu.

Xin lưu ý: đây KHÔNG phải là ngọn lửa của kiến ​​trúc VM - chỉ là một cảnh báo cho những người đang tìm hiểu về nó - hãy chắc chắn rằng bạn có những con vịt của bạn liên tiếp trước khi thực hiện.

Phát triển trên các máy ảo có thể hoạt động khá độc đáo, nhưng chỉ khi được thực hiện đúng:

• Chỉ vì sử dụng máy ảo cho phép bạn có một máy tính cho toàn bộ nhóm chứ không phải một máy tính cho mỗi nhà phát triển không có nghĩa đó là một ý tưởng hay
• Khởi động lại không nên yêu cầu mở một vé hỗ trợ với thời gian phản hồi 24 giờ
• Phát triển các máy ảo không phải ở trong một trung tâm dữ liệu 5000 dặm từ các nhà phát triển.
• Mặc dù VM có thể được quản lý bởi các nhà phát triển và do đó không được hỗ trợ, điều đó không có nghĩa là họ sẽ không thể truy cập các dịch vụ mạng như kiểm soát nguồn.
• Kết nối máy tính từ xa phải là tiêu chuẩn, không phải là một số applet "bảo mật cao" tùy chỉnh có thể chuyển đổi bất kỳ trích dẫn nào được nhập vào ô.
• Nhận một VM mới hoặc xây dựng lại một máy ảo hiện có sẽ mất vài phút chứ không phải vài tuần

Tôi đã thấy tất cả những vấn đề này và đặc biệt không thích làm việc với chúng. Tuy nhiên tôi cũng có một thiết lập VM tại nhà mà tôi sử dụng tùy ý. Điều đó chạy nhanh hơn cài đặt cục bộ và cho phép những thứ như môi trường riêng biệt cho các dự án khác nhau và xây dựng lại nhanh khi môi trường không ổn định.

Tôi làm việc với máy ảo, nhưng tôi không đề xuất nó cho dự án chính của bạn.

Lý do tôi sử dụng máy ảo để phát triển là vì tôi phải hỗ trợ các dự án cũ (ví dụ VB6, .NET 1.1, v.v.) và tôi không muốn làm bẩn máy chính của mình bằng cách cài đặt VS2003 / 2005 / vb6 / etc ... Nó hoạt động tốt, nhưng có những vấn đề không liên tục ở đây và đó.

Ngoài ra, tương tác chậm hơn, VM mất một chút thời gian để bắt đầu / tắt máy, không có hiệu ứng UI gốc (như Aero trong Win7), v.v ...

Bất cứ điều gì bạn sẽ tiết kiệm về mặt tiền bạc, bạn sẽ lãng phí và hơn thế nữa bởi những rắc rối bạn sắp áp đặt cho nhóm của mình. Thêm vào đó, như một người nào đó ở đây đã đề cập, không hỗ trợ đa màn hình. Tôi cần ít nhất 3 màn hình để có năng suất cao nhất có thể.

Nguyên tắc phát triển số 1 là giữ cho các nhà phát triển của bạn hài lòng. Bạn sẽ thấy rằng gần như không thể thực hiện được với các máy ảo từ xa. Hỗ trợ đa màn hình là không chính xác, độ trễ và lỗi mạng là rắc rối và tiết kiệm chi phí thường là tối thiểu.

Chắc chắn cũng hoạt động trên máy ảo, nhưng cũng cho phép máy ảo cục bộ và biến máy tính vật lý thành một con thú cực kỳ nhanh.

Tôi làm việc từ xa 100% và giữa ISP cá nhân của tôi và VPN - mặc dù có độ tin cậy cao - họ có đủ các cú đánh khiến tôi phát điên nếu tôi không thể làm việc ở chế độ ngoại tuyến.

Tôi thường chỉ cần quay nhiều hình ảnh VirtualBox và làm việc từ chúng. Sao chép vài trăm MB qua dây không quá tốn thời gian nếu bạn cần một cái mới cục bộ.

Nhóm của tôi đã thực hiện thành công cấu hình "PC chậm / máy chủ VM nhanh". Đối với một nhóm gồm 20 nhà phát triển, chúng tôi đã có bộ xử lý 8, RAM 256GB được kết nối qua cáp quang với SAN rất nhanh. Nó đắt tiền, nhưng rẻ hơn so với việc cung cấp cho mỗi nhà phát triển một máy trạm có hiệu suất tương tự. Đối với một nhóm nhỏ (4 nhà phát triển) Tôi không chắc quy mô kinh tế sẽ phát huy và thực sự giúp bạn tiết kiệm mọi thứ.

VM để phát triển là đáng xem xét, nhưng chi phí tài chính là lý do sai .

Điều này đã được đề cập ngắn gọn trong Expert .NET Delivery của Marc Holmes khi sử dụng NAnt & CruiseControl.net - tóm lại, lập luận cho việc phát triển trên VM là nó không khuyến khích bất kỳ khía cạnh nào của công việc không phụ thuộc vào cấu hình cụ thể của nhà phát triển. Bạn khởi động máy ảo của mình khi bắt đầu mọi dự án và trừ khi bạn thực sự cần một công cụ cụ thể, nó sẽ không tiếp tục hoạt động. Điều này giảm thiểu khả năng những thay đổi bạn thực hiện sẽ phá vỡ máy của bất kỳ ai trừ máy của bạn. Các nhà phát triển có thể khóc khi lấy đồ chơi của họ - nhưng cuối cùng, sự phụ thuộc vào các công cụ là một điểm yếu và bất cứ điều gì bạn không thể làm bằng trực giác trong một môi trường sạch sẽ là một mùi.

Lưu ý rằng tôi không nhất thiết phải tin vào các đối số được trình bày ở trên. Tôi hiểu và ở một mức độ nhất định phù hợp với họ, nhưng tôi đang tạo ra chúng để tranh luận, để tạo ra cuộc thảo luận.

Hạn chế tiềm năng

• Nếu máy chủ VM ngừng hoạt động ... tất cả các bạn đều bị hos. Nếu bạn đã từng có một nhóm gồm 20 người hét lên "GAH! HOST KHÔNG TRẢ LỜI!?" đồng thanh ... nó không vui
• Nếu bạn cho phép ảnh chụp nhanh ... những thứ đó sẽ ăn hết tài nguyên một cách nhanh chóng. 20 người * 10-20 ảnh chụp nhanh mỗi lần tạo ra nhiều dung lượng ổ cứng (hoặc ít nhất là đủ để bắt đầu gây ra sự cố).
• Nếu bạn gặp phải vấn đề với việc sử dụng tài nguyên trên máy chủ, một lần nữa, mọi người đều trải qua nỗi đau.

IME, đó là một giải pháp tốt và nó hoạt động, nhưng bạn cần một số phần cứng tốt trên máy chủ và khi điều tồi tệ xảy ra, chúng xảy ra với mọi người.

Điều này thất bại một trong những tiêu chí quan trọng nhất của bài kiểm tra Joel.

Tôi chắc chắn rằng tất cả các nhà phát triển của tôi đều có ít nhất một máy tính xách tay hoặc máy tính để bàn i3 hoặc tốt hơn với nhiều RAM nhất có thể.

8GB là những gì tôi phấn đấu.

Nó làm cho chúng hiệu quả hơn và chúng thực sự có thể chạy Virtual Box trên các máy cục bộ của chúng để phát triển và thử nghiệm, thay vì tốn kém để duy trì máy chủ. Họ có thể chụp nhanh Hộp ảo cài đặt những thứ điên rồ và kiểm tra các trình duyệt và trình cài đặt khác nhau và mọi thứ và sau vài giây sẽ quay lại cấu hình tốt đã biết mà không cần liên hệ với các dịch vụ "CNTT".

Các nhà phát triển cần các máy nhanh nhất trong công ty, với hầu hết các quyền RAM và quyền root trên các máy cục bộ của họ. Kết thúc câu chuyện.

Tôi đã làm việc trên các máy ảo trước đây để phát triển, cả máy ảo cục bộ (chạy trên PC cục bộ) và máy ảo từ xa. Những người địa phương đã nhiều đẹp hơn để làm việc với hơn những người ở xa.

Các máy ảo từ xa, được RDP kết nối với chúng tôi, có một độ trễ nhỏ giữa mỗi lần nhấn phím và hành động. Có thể phát triển trong những điều kiện như vậy trong một thời gian ngắn nhưng ngày này qua ngày khác, nó trở nên rất bực bội.

Tôi vui vẻ phát triển theo máy ảo cục bộ trên VMWare vì tôi cần chạy Flash Builder trên máy Linux và khá hài lòng với nó miễn là nó có đủ bộ nhớ - nó hoàn toàn có thể sử dụng được.

Chúng tôi làm điều đó cho các máy từ xa của chúng tôi và nó hoạt động khá tốt. Hầu như hiếm khi làm việc tại nhà (thông thường chỉ để khắc phục khẩn cấp ở đây và đó), vì vậy chúng tôi chỉ sử dụng các netbook khá thấp, được điều khiển từ xa cho các máy tính để bàn tốc độ của chúng tôi tại văn phòng. Chúng chắc chắn vẫn chậm hơn (có thể bị giới hạn bởi mạng nhiều hơn bất cứ thứ gì), nhưng làm việc cho các nhiệm vụ ngắn mọi lúc mọi nơi. Điều này thực sự sẽ không được chấp nhận đối với một con ngựa làm việc toàn thời gian, tuy nhiên, vì VM có thể thường xuyên gây ra một chút độ trễ mà ngay cả với phần cứng tốt nhất, IMHO, có một chút mất tập trung.

Ở công việc cuối cùng của tôi, chúng tôi đã làm khá chính xác điều đó:

Chúng tôi đã sử dụng Windows Terminal Server, nơi mọi nhà phát triển đều có tài khoản. Các nhà phát triển vẫn có PC thông thường (vì họ đã ở đó), nhưng PC chỉ chạy máy khách RDP.

Chúng tôi đã phát triển Java, vì vậy phần mềm được sử dụng trong đó trình biên dịch Java + IDE (chủ yếu là Eclipse), cộng với trình duyệt web, công cụ truy vấn DB, máy khách kiểm soát phiên bản và đôi khi là văn phòng sw (OpenOffice.org trong trường hợp của chúng tôi).

Chúng tôi đã không gặp phải bất kỳ vấn đề thực sự, và hiệu suất là khá tốt.

Vấn đề thực sự duy nhất là bạn thực sự cần phải cẩn thận để không làm phiền người khác trong một số tình huống, bởi vì bạn đang chia sẻ một hệ thống. Khi các hoạt động CNTT cần thiết để thực hiện các bản sao tệp lớn hoặc chạy sao lưu trên máy chủ, hiệu suất sẽ giảm đối với mọi người. Khi chúng tôi xác định và giải quyết vấn đề này (bằng cách sao chép với mức độ ưu tiên thấp hoặc qua đêm), mọi thứ đều hoạt động tốt.

Vì vậy, cảnh báo là: Đánh giá hiệu suất càng sớm càng tốt, và lập kế hoạch cho phần cứng và việc sử dụng nó cho phù hợp.

TL; DR: Tôi đã thực hiện nó ở nhiều công việc và bây giờ tôi thích nó.

Chi phí là lý do sai để tập trung vào. Dưới đây là một số những người tốt hơn.

Lý do

• Tính nhất quán của nền tảng trong các môi trường khác nhau (dev, test và sản xuất).
  • Tại sao: Nó loại bỏ hoàn toàn một vectơ khiếm khuyết, khiếm khuyết từ sự khác biệt nền tảng trong các môi trường khác nhau.
• Cho phép thay đổi hệ thống như nâng cấp xảy ra đầu tiên trong vms phát triển, được xác minh, cuộn lên để kiểm tra, được xác minh và đưa vào sản xuất; tất cả dễ dàng hơn nhiều với sự phát triển (và thử nghiệm) vms.
  • Tại sao: Kiểm soát. Tôi có thể chụp nhanh, khôi phục, xác định các vùng đồng bằng, thực hiện thay đổi trên một máy chủ và tuyên truyền thành công bằng cách nhân đôi vm, v.v.
• Đôi khi các hệ thống bạn phát triển chỉ có sẵn trên một mạng được bảo mật. Ngoài ra, máy chủ mà phần mềm của bạn sẽ chạy trên chỉ có thể có quyền truy cập hạn chế hoặc các đặc điểm mạng khác nhau.
  • Tại sao: VM phát triển có thể nằm trên Vlan có quyền truy cập vào hệ thống hoặc dịch vụ bị khóa. Ngoài ra, nếu máy chủ dev có quyền truy cập hạn chế như máy chủ thử nghiệm và sản xuất, sẽ không bao giờ có câu hỏi về việc vô tình mã hóa một yêu cầu trên một đặc tính mạng hoặc quyền truy cập không khả dụng.

Thử thách

Thách thức số một là phát triển từ xa, đặc biệt nếu bạn phải đi qua một cổng hoặc máy chủ nhảy. Điều này gây khó khăn, đặc biệt là nếu các nhà phát triển không làm tròn tốt (họ có một số kiến ​​thức kỹ thuật hệ thống, kiến ​​thức mạng, v.v.).

Có nhiều biến thể của sự phát triển từ xa, nhưng chúng thường có tới 2 điểm khác biệt chính.

• Chạy các công cụ phát triển của bạn trong môi trường từ xa và sử dụng các giao thức như máy khách RDP, máy khách X11 từ xa, v.v.
• Chạy các công cụ phát triển của bạn cục bộ và sử dụng các giao thức để đồng bộ hóa hoặc thực thi trong suốt trên máy chủ từ xa, thường sử dụng ssh làm lớp vận chuyển.

Công cụ

Có những công cụ sẽ giúp phát triển từ xa, và có những IDE tạo điều kiện cho nó. Bạn sẽ phải điều tra mức độ nào nó có khả năng phát triển từ xa, nhiều người không phải không chạy trên cùng một máy chủ mà mã đang được phát triển. Tuy nhiên, có những công cụ khác.

• Secure Shell: Hầu hết các thiết lập phát triển từ xa thành công đều sử dụng ssh ở mức độ lớn hơn, sử dụng thông tin đăng nhập không mật khẩu (sử dụng xác thực khóa), multihops trong suốt (giải quyết vấn đề máy chủ nhảy) và các tùy chọn cấu hình khác để cải thiện thời gian phản hồi. Lưu ý: Tôi luôn gặp sự cố khi sử dụng các triển khai SSH không phải OpenSSH.
• GNU Screen / TMUX: Bộ ghép kênh đầu cuối. Màn hình là cháu của họ và vẫn còn mạnh, nhưng tôi nghĩ hầu hết mọi người đã bắt đầu chuyển đổi (hoặc thậm chí bắt đầu) trên TMUX.
• Vim / Emacs : Người bảo vệ cũ, nhưng cả hai đều hoạt động tuyệt vời để phát triển từ xa theo những cách khác nhau. Đó là Vim vì vậy tất cả những gì nó cần là một vỏ, trong khi Emacs có thể chạy cục bộ và sử dụng TRAMP để phát triển từ xa.

Trên một chiến thuật hơi khác - bạn đã đưa cho người quản lý / kế toán của mình một bảng tính làm nổi bật chi phí sử dụng các máy chậm này chưa? Chỉ ra cho họ rằng một giải pháp VM (trừ khi được thực hiện đúng và không dễ) có thể chỉ đơn giản là đưa các nhà phát triển và do đó công ty vào cùng một chiếc thuyền.

Điều này sẽ phụ thuộc vào mức độ năng lực quản trị mà bạn có trong quá trình cài đặt VMware, nếu bạn được đưa vào một phân nhóm ưu tiên thấp thì bạn sẽ có các máy hoạt động chậm tùy thuộc vào hoạt động của các phân nhóm khác.

Phần cứng là rẻ, lập trình viên là đắt tiền.

Tại sao bạn muốn các lập trình viên của bạn thất vọng bằng cách cung cấp cho họ các máy phát triển chậm? Chi phí nâng cấp nhợt nhạt phần cứng so với lợi ích hiệu suất mà họ sẽ đạt được.

Yêu cầu máy móc tốt hơn. Ít nhất hãy yêu cầu 4 gb ram. Thêm một máy tính bảng 2gb khác sẽ kiếm được trong vòng chưa đầy một tuần.

Thiếu hỗ trợ màn hình kép luôn là kẻ giết người thỏa thuận. Tôi chỉ không thể tưởng tượng làm công việc phát triển quan trọng trên một màn hình.

Bây giờ, họ thực hiện rock để thử nghiệm / triển khai / đấu tranh, vì vậy tôi cũng không nghĩ họ nên rơi ra khỏi ngăn xếp.

Nếu bạn có một máy tính lớn với 50 đĩa SSD trong RAID10 và chỉ sử dụng 3-4 máy trên máy tính lớn đó, thì nó có thể hoạt động.

Nếu không, chúng là lag lag, thực sự lag (mặc dù trong một số trường hợp hiếm hoi, snapshoting có thể bù lại điều đó).

Tôi có một máy tính để bàn đàng hoàng tại văn phòng mà tôi có thể kết nối từ máy tính xách tay của mình qua VPN bằng cách chia sẻ màn hình.

Nó hoạt động trong số giờ hỗ trợ sự cố và thỉnh thoảng buộc phải làm việc từ xa. Nó chắc chắn tốt hơn so với việc duy trì một môi trường được cấu hình đầy đủ trên máy thứ hai hoặc để phát triển công cụ cần độ trễ thấp cho trung tâm dữ liệu qua mạng WAN.

Tuy nhiên, thật khó chịu khi làm việc theo cách đó trong thời gian dài. Đôi khi tôi phải lái xe đi làm vào nửa cuối của ngày một khi bất cứ điều gì khiến tôi ở nhà đã tránh đường.

Độ trễ và màn hình bất động sản là hai kẻ giết tôi.

Tôi không nghĩ rằng bạn muốn đi với một giải pháp VM từ xa. Kết nối mạng sẽ là nút cổ chai và thậm chí trên một kết nối nhanh, nó có thể đủ để gây ra sự thất vọng. Chúng tôi đang chuyển từ kỹ thuật này sang sử dụng môi trường phát triển địa phương.

Chúng tôi phát triển trên iMac, điều này thực sự tốt, nhưng các ứng dụng web của chúng tôi đang chạy trên môi trường Linux trong Sản xuất. Vấn đề với điều này là cuối cùng, chúng ta có thể gặp phải một vấn đề chỉ xảy ra trên Linux và có thể khó khắc phục sự cố. Đó là nơi sức mạnh của các máy ảo xuất hiện. Tuy nhiên, tôi thậm chí không thích ý tưởng sử dụng VM 100% thời gian.

Gần đây tôi đã biết về Vagrant (http://vagrantup.com/docs/getting-started/why.html) và Chef để làm việc với VirtualBox siêu dễ dàng. Vagrant cung cấp cho bạn khả năng dễ dàng khởi động VM khi bạn cần và phá bỏ VM khi bạn không. Vì vậy, tôi có thể làm tất cả sự phát triển của mình bằng máy Mac. Sau đó, khi tôi sẵn sàng kiểm tra mã của mình, tôi có thể khởi động máy ảo để kiểm tra mã và chỉ giữ nó miễn là tôi cần. Vagrant cũng cung cấp cho bạn khả năng dễ dàng chia sẻ VM với đồng nghiệp để tất cả các bạn có thể chắc chắn rằng bạn đang làm việc trong cùng một môi trường.

Tôi khuyên bạn nên kiểm tra Vagrant để bạn ít nhất nhận thức được các tùy chọn có sẵn khi phát triển và làm việc với máy ảo.

Tôi đã làm việc trong một dự án cũ liên quan đến 5 máy, mỗi máy có một vai trò trong một đường ống tính toán (máy 1 gửi yêu cầu đến máy 2, lần lượt sẽ gửi yêu cầu đến máy 3, v.v.). Tuy nhiên, việc triển khai cài đặt trên máy ảo đã giúp chúng tôi tiết kiệm rất nhiều thời gian: 1. Hệ thống không thể truy cập được do các nhà phát triển lười biếng / không có thời gian để kết hợp thử nghiệm trong thiết kế. 2. Quá nhiều thiết lập đã được triển khai và tôi cần tiêu tốn thời gian để sắp xếp chúng theo nhóm.

Bây giờ tôi sử dụng nó bởi vì tôi làm việc trên quá nhiều dự án cùng một lúc. Vấn đề chính tôi có bây giờ là: 1. Máy ảo đang tiêu tốn quá nhiều thời gian để duy trì. 2. Máy ảo đang tiêu tốn một lượng lớn bộ nhớ để chạy

Kiểu này làm cho máy ảo khó sử dụng khi bạn cố gắng sử dụng chúng để có thứ tự. Giữ một máy chính với email và văn bản của bạn, phát triển trên các máy ảo. Giữ cuộc sống của bạn gọn gàng và sạch sẽ với chi phí.

Như những người khác đã nêu, nó thực sự phụ thuộc vào vấn đề bạn đang cố gắng giải quyết với Máy tính để bàn VM và sau đó cân nhắc lợi ích của việc giải quyết vấn đề đó trước những bất lợi mà môi trường VM sẽ gặp phải.

Chúng tôi đang hướng tới một môi trường hỗn hợp, nơi tất cả các nhà phát triển trong nước của chúng tôi sẽ có máy móc vật lý truyền thống nhưng các nhà phát triển ngoài khơi (làm việc với một công ty gia công nhỏ ngay bây giờ) sẽ sử dụng máy tính để bàn ảo. Các vấn đề chúng tôi đang cố gắng giải quyết với máy tính để bàn từ xa có liên quan đến bảo mật và hiệu suất. Môi trường ảo rõ ràng sẽ cung cấp cho chúng tôi quyền kiểm soát lớn hơn từ góc độ bảo mật và để thực hiện, chúng tôi sẽ chỉ chuyển "pixel thay đổi" thay vì mã nguồn đầy đủ và phải triển khai các máy chủ proxy và như vậy.

Vẫn không chắc đây có phải là con đường đúng đắn hay không, nhưng đó là nơi chúng ta đang hướng đến.