Haruskah mesin pengembangan berada di dalam VM? [Tutup]

Posting ini oleh Rob Conery (note the slug) mengatakan bahwa lingkungan pengembangan harus dijalankan di dalam mesin virtual. Saya mengerti apa yang dia katakan dan cenderung setuju, tetapi masih merasa sedikit tidak nyaman. Sekarang virtualisasi sudah sangat matang sehingga bahkan sistem produksi berjalan di dalam kecepatan VMs cukup banyak bukan masalah, tetapi ketika saya mengatakan sesuatu yang mengganggu saya di sini.

Apa pendapat Anda tentang virtualisasi mesin pengembangan Anda? Sudahkah Anda melakukannya? Jika Anda melakukannya, apakah ada jebakan atau gotcha di sepanjang jalan?

Pengalaman saya dalam mengembangkan VM di lingkungan perusahaan adalah bahwa karena virtualisasi banyak inti penuh dengan kesulitan, sulit untuk mendapatkan jenis kinerja yang dibutuhkan oleh banyak mesin pengembangan usaha.

Mendapatkan loop dalam kode-compile-test secepat mungkin membutuhkan mesin terbaik - kompilasi dan menjalankan tes jelas berjalan lebih cepat pada mesin dengan lebih banyak core, karena aktivitas-aktivitas tersebut dapat dengan mudah dijalankan dengan cara bersamaan * .

Sampai OS pengembangan arus utama dapat menangani jumlah core yang tersedia menjadi tidak stabil, dan sampai perangkat lunak virtualisasi secara cerdas dapat menawarkan semacam kontrak "hingga inti N", mesin pengembangan tervirtualisasi tidak akan menawarkan pengembalian produktivitas yang sama dengan perangkat fisik.

EDIT: Ini hanya menceritakan perasaan pribadi saya tentang pengembangan menggunakan VM yang didikte perusahaan, yang sering dilarang untuk memotong biaya perangkat keras, yang cenderung berjalan di server. Menjalankan VM lokal tampaknya sebagian besar berlebihan asalkan Anda menegakkan disiplin kontrol sumber yang baik, kecuali proyek Anda secara khusus mengharuskan Anda untuk mengembangkan kode untuk beberapa OS.

*: maksud saya subtugas di dalam tahap kompilasi dan tahap pengujian dapat dijalankan secara bersamaan, TIDAK menyusun dan menguji secara bersamaan :)

Saya melakukan semua pengembangan pribadi saya di VM. Saya memiliki beberapa pengaturan VM untuk berbagai lingkungan dan berfungsi dengan baik.

Saya punya laptop dell studio 15 (quad I7 2.8ghz, ram 8gb, ati grafis) menjalankan win 7 ultimate 64bit dengan virtualbox terpasang. Saya memiliki semua VM saya menjalankan drive usb 500GB eksternal velcroed ke laptop.

VM 0 - Win 7 64bit clean install sebagai template dasar

VM 1 - Win 7 64bit (2 cpu, 4gb ram, 120gb hd) dengan Visual Studio 2008 toolset

VM 2 - Win 7 64bit (2 cpu, 4gb ram, 120gb hd) dengan Visual Studio 2010 toolset

VM 3 - Win 7 64bit (2 cpu, 2gb ram, 120gb hd) dengan Eclipse Java toolset

Kecuali jika saya melakukan sesuatu yang membutuhkan IO sangat tinggi, saya merasa kinerjanya baik dan saya tidak akan tahu saya berada di dalam VM jika seseorang baru saja menyerahkan laptop saya dan berkata mulai mengembangkan.

Saya ingin menambahkan bahwa beberapa jenis pengembangan jauh lebih sulit (jika bukan tidak mungkin) melalui mesin virtual.

Saya kebetulan bekerja di perusahaan tempat kami menawarkan paket perangkat lunak yang berintegrasi dengan sejumlah perangkat periferal USB yang berbeda (mis. Webcam, printer label, pembaca strip magnetik, dll ...). Bahkan jika saya memetakan port USB ke server tervirtualisasi, saya perhatikan ada masalah aneh dan tidak dapat dijelaskan dengan driver perangkat vendor pihak ketiga.

Seperti yang saya katakan, saya pikir situasi ini TIDAK TIDAK bekerja pada mesin pengembangan yang sudah dievaluasi, namun ini adalah salah satu yang belum kita ketahui, jadi kita mempertahankan stasiun kerja fisik untuk lingkungan yang berbeda di laboratorium.

Di perusahaan kami, kami sekarang menggunakan VM untuk pengembangan dan pengujian. Meskipun ada beberapa kelemahan untuk menggunakan VM, manfaatnya jauh melebihi mereka.

Sebelum kami mulai menggunakan VM, kami memiliki masalah dengan menyiapkan mesin pengembangan untuk pengembang baru. Tugas pertama untuk pengembang baru dalam tim biasanya menyiapkan mesin pengembangan sendiri. Kami adalah perusahaan kecil dan kami tidak selalu memiliki tenaga untuk membantu anggota tim baru menyiapkan mesin mereka. Ini menyebabkan masalah yang berbeda: kadang-kadang bug hanya dapat direproduksi di mesin mereka atau mereka tidak dapat mereproduksi sama sekali, aplikasi tidak dapat membangun dengan benar dll. Juga ada masalah bahwa beberapa pengembang senior kami sedang mengerjakan beberapa proyek pada lingkungan kerja yang tidak selalu kompatibel.

Ketika kami beralih ke VM, semuanya berubah. Sekarang hanya satu orang yang bertanggung jawab untuk mengatur lingkungan di VM dengan segala sesuatu yang berkaitan dengan proyek. Setelah selesai, semua anggota tim diberikan salinan VM. Ini mengurangi waktu untuk mengatur lingkungan untuk setiap anggota tim baru (menyalin VM seharusnya tidak lebih dari 1 jam). Ini juga memungkinkan kita untuk bekerja pada beberapa lingkungan kerja secara paralel.

Kelemahan untuk menggunakan VM: kecepatan. Hit kinerja pada VM terlihat. Pada workstation yang lebih lambat dapat membuat pengembangan hampir mustahil. Jika Anda memiliki workstation yang baik (quad core, 8 + GB RAM, SSD) Anda mungkin tidak akan melihatnya.

Seperti yang disebutkan orang lain, itu tergantung pada beberapa hal:

• Seperti apa lingkungan Anda?
• Apakah Anda memiliki hak akses yang memadai untuk melakukan pengembangan?
• Apakah HW Anda siap mati?

Lingkungan Hidup

Menggunakan VM dapat membantu jika Anda mengerjakan beberapa versi proyek; berbagai proyek; atau menargetkan OS yang berbeda dari yang biasa Anda jalankan (host OS). Saya melakukan banyak pekerjaan SharePoint dan dapat menjalankan mesin yang berbeda untuk berbagai versi rilis sangat membantu karena saya hanya dapat memulai mesin yang berbeda dan memiliki perasaan yang baik untuk keadaan GAC / database. Juga jika Anda perlu menargetkan lingkungan aplikasi * nix tetapi memiliki mesin Windows maka Anda masih dapat melakukan pengembangan dalam VM (ini adalah bagaimana saya belajar Ruby di rumah meskipun saya biasanya melakukan .NET dev work). Saya biasanya menganjurkan ketika melakukan pengujian pengembangan / pengembangan ASP.NET pada versi IIS yang sama bahwa aplikasi pada akhirnya akan berjalan di bawah (rasional yang sama ini berlaku untuk lingkungan target server lain). Tergantung pada versi OS mungkin ada beberapa perbedaan kecil tapi kritis. Catatan ini tidak menyiratkan Anda harus kode ke versi IIS / OS tertentu tetapi mari kita jujur ​​itu benar-benar harus benar-benar bekerja di mana Anda akan menyebarkannya tidak hanya pada mesin lokal Anda.

VM juga (tergantung dari perangkat lunak yang digunakan) memungkinkan Anda untuk mengambil snapshot dari kondisi mesin saat ini dan / atau mengkloningnya. Ini bisa sangat berharga ketika membuat prototipe sesuatu dan Anda tidak perlu khawatir tentang apa yang terjadi di GAC / Registry / dll. Saya juga menemukan mereka sangat berharga dalam menyiapkan demo klien sebelumnya. Karena lingkungan demo berada dalam VM, saya dapat terus bekerja hingga menunjukkan kepada klien apa yang telah kami selesaikan karena saya bekerja di mesin yang berbeda .

Hak-hak yang memadai

Ini umumnya berlaku untuk orang-orang yang bekerja untuk perusahaan dengan serangkaian kebijakan hak akses yang agak tegang. Jika Anda tidak dapat memiliki admin yang tidak dikekang di mesin Anda, ini akan menjadi saat yang tepat untuk bekerja di VM. Biasanya kekuatan hanya khawatir tentang mengunci OS host Anda, tamu bisa terbuka lebar (izin izin). Saya telah mengalami masalah aneh dengan profil roaming, hak admin lumpuh, dan menjalankan VS 2010; menggunakan VM memungkinkan saya untuk menghindari masalah ini.

Apakah HW Anda siap mati?

Ini intinya adalah baik gambar VM Anda berada di server dan remote Anda ke mereka ATAU Anda menjalankannya secara lokal. Jika Anda menjalankan di server maka kekhawatiran terbesar mungkin akan ada terlalu banyak VM yang berjalan pada perangkat keras yang sama. Secara lokal Anda pada dasarnya menginginkan banyak RAM dan untuk meminimalkan seberapa sering Anda kelebihan buffer R / W untuk hard drive Anda. Untuk pengembangan LOB / SharePoint / ASP.NET dasar saya telah menemukan bahwa minimal 8 GB RAM dan konfigurasi hard drive ganda berfungsi dengan baik dalam praktiknya (menjalankan i5 tapi saya juga sudah bekerja dengan Core 2). Hard drive kedua membuat perbedaan terbesar dalam kinerja.

Catatan: Saya tidak memiliki statistik untuk mendukung hal ini tetapi saya perhatikan bahwa Virtual PC memiliki kecenderungan untuk berkinerja lebih rendah dibandingkan dengan VMWare dan Virtual Box. Saya tidak dapat berbicara dengan Hyper-V karena saya belum pernah menggunakannya. Saya tidak akan terkejut jika menggunakan Virtual PC (sebagai perampokan awal untuk menggunakan VM) membuat pengembang lesu menggunakan perangkat lunak virtualisasi.

Seperti biasa: itu tergantung. Misalnya, saya tentu tidak akan merekomendasikannya untuk pengembangan real-time atau game komputer terkait.

Pengalaman pribadi saya: Saya memiliki iMac akhir 2009, dan saya menemukan bahwa Visual Studio 2010 pada dasarnya tidak dapat digunakan di Parallels Desktop, sampai-sampai menekan tombol di editor kode memerlukan waktu beberapa detik untuk mendaftar. Windows di SQL Server Management Studio akan mengubah fokus dan mengalihkan fokus secara acak. Saya baru saja berakhir dengan boot camp.

Tentu saja, proyek baru saya akan melibatkan aplikasi iOS dengan alat konfigurasi berbasis Windows, jadi mungkin terlalu menyakitkan untuk tidak menggunakan virtualisasi, tetapi jika teknologi virtualisasi desktop belum cukup bergerak dalam setahun terakhir ini, Saya mungkin akan mengatur desktop lain di sini.

Ketika datang untuk menguji aplikasi server, itu adalah situasi yang berbeda, saya sangat senang untuk virtualisasi itu, tetapi saya perlu responsif dalam aplikasi pengembangan saya.

Saya telah menggunakan VM untuk pengembangan dan pada umumnya tidak jauh berbeda dengan pengembangan di komputer saya sendiri. Jika Anda menggunakan Kontrol Sumber dengan benar, tidak ada banyak perbedaan.

Perbedaan utama adalah bahwa jika Anda offline karena alasan apa pun Anda tidak memiliki mesin pengembangan yang tersedia untuk Anda, jadi tidak terlalu bagus jika Anda sering bepergian atau bekerja dari rumah. Juga saya tidak pernah menemukan cara menjalankan beberapa monitor pada Remote Desktop, tetapi saya yakin itu adalah kegagalan saya daripada masalah dengan prinsipnya. Saya biasanya menggunakan monitor utama saya untuk pengembangan dan menyimpan yang kedua untuk mesin desktop saya dengan email, browser, dan sebagainya.

Saya akan menambahkan bahwa jika Anda bekerja dengan cara di mana Anda perlu memeriksa kode Anda bekerja pada platform yang berbeda - terutama hal-hal seperti mengembangkan installer - maka dapat menjalankan VM untuk versi OS yang berbeda sangat berguna.

Saya menggunakannya di perusahaan sebelumnya. Beberapa kontrol pihak ketiga tidak berdampingan dengan versi lain oleh perusahaan yang sama. Saya juga menggunakan pasangan untuk menguji dan men-debug sistem operasi lain (XP vs Vista vs 7). Satu virtual memiliki VB6 dan VS2003 untuk produk yang lebih tua. Ya, pada mesin pengembang tipikal bisa lambat dan rumit, tapi saya punya beberapa hard drive cadangan yang saya "donasikan" dan meletakkan virtual pada hard drive mereka sendiri pada pengontrol drive mereka sendiri. Saya adalah orang terakhir yang terus menggunakan virtual, dan untuk beberapa bug, hanya saya yang bisa menggunakannya (karena masalah sistem operasi dan komponen).

Beberapa orang terbakar menginstal perangkat lunak beta, dan beberapa beta dari MS tidak dapat dihapus, sehingga mereka terpaksa menggunakan virtual sampai mereka memformat ulang hard drive mereka.

Untuk pengembangan dalam virtual, saran saya adalah untuk mendapatkan sesuatu dengan min 8GB RAM. 16 atau lebih akan lebih baik, karena Anda akan menemukan studio visual yang dilengkapi kebutuhan virtual sekitar 1,5GB RAM host untuk berjalan pada kecepatan di atas "glasial". Juga, dapatkan banyak hard drive saat membeli komputer. Untuk drive yang Anda pilih dari tumpukan perangkat keras cadangan Anda, cari yang setidaknya berukuran 2x VHD yang akan Anda jalankan.