Pikiran tentang Pengembangan menggunakan Mesin Virtual [ditutup]

Saya akan bekerja sebagai pemimpin pengembangan untuk startup dan saya menyarankan agar kami menggunakan VM untuk pengembangan. Saya tidak berbicara tentang masing-masing pengembang memiliki desktop dengan VM untuk pengujian / pengembangan, maksud saya memiliki rak server di mana semua VM dikelola dan memiliki pengembang bekerja dari microPC (ChromeOS ada orang?) Secara lokal, atau bahkan jauh dari rumah mereka komputer.

Bagi saya, manfaatnya adalah fakta bahwa itu sangat terukur, lebih murah dalam jangka panjang, lebih mudah dikelola dan kami menggunakan perangkat keras potensi maksimalnya. Sedangkan untuk kontra, saya tidak bisa memikirkan showstoppers tertentu selain kita akan membutuhkan seseorang untuk setup / memelihara pengaturan tersebut.

Saya berharap bahwa beberapa dari Anda mungkin memiliki pengaturan yang sama di tempat kerja Anda dan dapat mempertimbangkan pendapat Anda. Terima kasih.

Apa yang ingin Anda simpan, sebagai bagian dari anggaran pembangunan? Tampak bagi saya bahwa Anda mengkhawatirkan epsilon. Biaya mesin untuk pengembang kurang dari 5% dari total biaya untuk menjaga pengembang tetap pada staf. Karena itu satu-satunya pertanyaan penting adalah "akankah itu menghemat waktu pengembang?" Bisa, jika mereka tidak perlu menghabiskan waktu menginstal dan memutakhirkan perangkat lunak pengembangan. Atau bisa memakan waktu, jika jaringan turun, atau server turun, atau, kemungkinan besar, jika respons di internet paling sedikit kurang. Perkembangan modern tergantung pada interaksi keystroke-by-keystroke dengan IDE, atau setidaknya editor yang sangat cerdas. Menunda interaksi bahkan oleh beberapa puluh milidetik menghancurkan produktivitas pengembang. Ada juga biaya bagi pengembang untuk mempelajari cara kerja yang baru ini.

Ini bukan keberatan terhadap VM, tetapi keberatan potensial untuk pengembangan jarak jauh.

Saya pikir Anda bersikap bijaksana dan bodoh.

Pertama-tama, biaya alat berat sepele dibandingkan dengan biaya pengembang. Anda harus berupaya memaksimalkan produktivitas, bukan meminimalkan biaya alat berat.

Kedua, latensi (bukan bandwidth) adalah kunci untuk banyak tugas pemrograman - terutama mengedit teks. Untuk setiap dolar / pound / euro yang Anda hemat pada mesin untuk pengembang Anda, Anda akan menghabiskan setidaknya sepuluh pada peningkatan jaringan untuk mempertahankan bahkan kesamaan produktivitas - dan bahkan kemudian, mereka mungkin akan lebih produktif jika Anda berhemat dengan memasok mereka dengan Pentium III yang Anda temukan di tempat sampah di suatu tempat.

Saya juga berpikir ada manfaat besar dalam membuat pengembang Anda menggunakan lingkungan setidaknya cukup dekat dengan yang diharapkan dari pengguna akhir target. Terlepas dari target kinerja resmi dalam spec dan semacamnya, sebagian besar programmer mendasarkan sedikit pada bagaimana kode "terasa" ketika mereka mengujinya. Ketika mereka menggunakan lingkungan yang sama sekali berbeda dari pengguna akhir, mereka cenderung membuang waktu untuk hal-hal sepele sambil benar-benar mengabaikan masalah besar.

Se semenarik lingkungan yang homogen terdengar dari sudut pandang dukungan dan semacamnya, Anda biasanya harus mendorong sebanyak mungkin variasi di mesin pengembang. Pengembang jarang membutuhkan banyak dukungan, dan mengetahui segera ketika Anda memiliki kode yang akan gagal dengan chip grafis yang berbeda, CPU, adaptor jaringan, dll., Lebih dari membayar investasi minimal.

Intinya: jika Anda menulis kode yang dimaksudkan (setidaknya terutama) untuk digunakan dalam lingkungan server tervirtualisasi, Anda hanya perlu menyediakannya untuk pengembang Anda. Jika Anda tetap melakukannya untuk pengujian, itu dapat (tetapi tidak harus) masuk akal untuk pengembangan juga. Demikian juga, jika Anda memerlukan (atau setidaknya memiliki) server dan jaringan yang terlalu banyak ditentukan, mungkin masuk akal untuk memanfaatkannya dengan menggunakan apa yang sudah Anda miliki.

Namun, dalam situasi yang paling khas, bagi saya tampaknya hal ini akan menimbulkan lebih banyak masalah daripada penyelesaiannya.

Itu adalah salah satu ide saya di masa lalu: memiliki server berkinerja tinggi yang memiliki semua perangkat lunak yang diperlukan, dan banyak PC desktop berkinerja rendah yang hanya akan digunakan untuk terhubung ke server melalui Remote Desktop.

Manfaatnya adalah:

• Cadangan solid. Beberapa pengembang mungkin tidak ingin membuat cadangan komputer desktop mereka secara teratur, jadi solusi sentral akan lebih andal,
• Kemungkinan, untuk setiap pengembang, untuk bekerja dari mana saja. Maksud saya ini juga berarti bekerja dari PC mana pun di perusahaan. Katakanlah di pagi hari, pengembang menginginkan kondisi kerja yang hening. Dia pergi ke kamarnya sendiri dan bekerja di sana. Kemudian dia ingin melakukan pemrograman berpasangan atau bekerja di lingkungan yang lebih sosial. Dia hanya mematikan PC desktopnya, pergi ke ruangan lain di mana ada sepuluh komputer, dan terhubung dari sana. Tidak "Saya harus memuat ulang semua aplikasi saya lagi".

Nah, ada beberapa masalah serius dengan itu, membuat saya berpikir bahwa saya tidak akan pernah menggunakan hal seperti ini di tahun-tahun mendatang.

• Kekhususan solusi jarak jauh. Bagaimana dengan bekerja jauh menggunakan beberapa layar komputer sekaligus? Maksud saya, apakah itu mudah? Apakah sudah jelas? Apakah pintasan yang saya gunakan setiap hari diaktifkan saat bekerja jauh? Saya tidak yakin. Bagaimana jika saya menekan Ctrl + Shift + Esc untuk melihat daftar program yang sedang berjalan? Oh ya, itu tidak berhasil, jadi sekarang saya harus ingat melakukannya dengan cara yang berbeda.

• Kinerja terpukul. Saya tidak yakin tidak akan ada penurunan kinerja sama sekali. Dan ingat, seorang programmer yang menggunakan komputer lambat adalah seorang programmer yang tidak bahagia. Dan perusahaan yang membuat pemrogram mereka tidak senang dengan kondisi buruk tidak akan pernah menghasilkan perangkat lunak berkualitas tinggi.

• Dampak bencana yang lebih tinggi. Apakah Anda akan meng-host solusi di server yang berlebihan? Apakah Anda memiliki jaringan yang berlebihan di perusahaan Anda? Katakanlah router turun, dan tidak berlebihan. Ini berarti bahwa semua pengembang sekarang tidak dapat bekerja. Sama sekali. Karena mereka tidak menginstal perangkat lunak secara lokal. Karena mereka bahkan tidak memiliki kode sumber: ada di server. Jadi semua orang berhenti, dan Anda membayar semua orang per jam hanya untuk menunggu router diganti.

• Biaya perangkat keras. Jika hanya satu dan satu server, berapa biayanya? Jika sudah, katakanlah, dua puluh pengembang, apakah 64 GB RAM di server sudah cukup? Tidak begitu yakin. Apakah solusi quad-core dengan dua CPU sudah cukup? Sekali lagi, saya ragu. Jika tidak, apa yang Anda pikirkan? Semacam awan? Atau apakah Anda memiliki solusi scalable yang berfungsi pada beberapa server? Apakah Anda siap membayar biaya Windows Server (jika Anda menggunakan Windows) per mesin?

• Biaya listrik. Jika Anda bekerja sepenuhnya dari jarak jauh, itu berarti Anda menghabiskan jumlah sisi server yang hampir sama dengan jika Anda bekerja secara lokal, ditambah jumlah daya yang terbuang oleh mesin lokal dan jaringan.

• Lisensi. Saya tidak yakin apakah saya harus menganggapnya sebagai manfaat atau masalah, tetapi saya merasa biaya lisensi perangkat lunak dalam kasus ini akan jauh lebih tinggi.

Dan sekali lagi, pikirkan semua biaya manajemen, dukungan, penyebaran, pemeliharaan. Dengan solusi khusus seperti ini, mungkin dengan mudah menjadi besar, tidak termasuk bahwa setiap kali sesuatu akan gagal, Anda akan melihat setiap pengembang NOP sekitar, menunggu untuk dapat melanjutkan pekerjaannya.

Kami menggunakan mesin amazon ec2 sesuai permintaan sebagai mesin pengembang. Ini tidak ada hubungannya dengan biaya. Kami memiliki "kumpulan pengembang" yang bekerja pada beberapa proyek, dan kami membutuhkan kemampuan untuk bergerak melintasi proyek dengan cepat.

Secara umum, VM menghemat waktu pengaturan awal. Tapi jangka panjang, itu membuang-buang waktu karena kehilangan produktivitas. Biaya bukan merupakan sumbu, karena biaya pengembang lebih dari biaya alat berat.

Biaya produktivitas termasuk - waktu yang diperlukan untuk memulai citra VM (beberapa menit), responsif yang buruk, dan kendala sumber daya / memori. Ini tidak banyak pada awalnya, tetapi seiring waktu mereka menjadi mengganggu.

Pada salah satu proyek kami, kami refactored kode untuk menyederhanakan pengaturan awal untuk "mengunduh kode dan menjalankan pakar". Dengan perubahan ini, mudah bagi pengembang baru untuk mulai mengerjakan proyek - dan sekarang tidak ada yang menggunakan gambar VM amazon. Kami mencari untuk meniru ini pada proyek lain juga, tetapi itu akan memakan waktu. Sampai saat itu, kami memiliki gambar EC2 kami.

SANGAT hati-hati di sini. Saya baru-baru ini dikerahkan ke pelanggan di mana semua orang di departemen TI memiliki VM mereka pada dasarnya untuk alasan yang sama - untuk memungkinkan mereka untuk memiliki PC ujung bawah di atas meja dan kemudian ke remote ke VM dan melakukan pekerjaan normal mereka.

Pengalaman di sana tidak cantik. Setidaknya sekali seminggu kami berlari sangat lambat karena berbagai alasan. Secara umum, kita dapat mengetahui kapan seseorang dalam tim menjalankan paket SSIS intensif prosesor. Mereka akhirnya memindahkan beberapa dari kami ke server yang berbeda, yang membantu beberapa, tetapi kinerja tidak pernah benar.

Saya pikir jika Anda akan melakukannya - lakukan uji tuntas Anda ke dalam daya server, kebutuhan pemrosesan Anda, berapa banyak mesin yang akan Anda sajikan, dll. Ini bisa menghemat uang, tetapi jika tidak diterapkan dengan benar, dapat menyebabkan BANYAK sakit kepala.

Harap dicatat: ini BUKAN nyala arsitektur VM - hanya peringatan untuk orang yang melihatnya - pastikan Anda memiliki bebek Anda secara berurutan sebelum diimplementasikan.

Pengembangan pada mesin virtual dapat bekerja dengan sangat baik, tetapi hanya jika dilakukan dengan benar:

• Hanya karena menggunakan VM memungkinkan Anda memiliki satu komputer untuk seluruh tim Anda daripada satu per pengembang tidak berarti bahwa itu adalah ide yang bagus
• Reboot tidak perlu membuka tiket dukungan dengan waktu respons 24 jam
• Pengembangan VM tidak boleh di pusat data 5000 mil dari pengembang.
• Meskipun VM dapat dikelola oleh pengembang dan karenanya tidak didukung, itu tidak berarti bahwa mereka seharusnya tidak dapat mengakses layanan jaringan seperti kontrol sumber.
• Sambungan desktop jarak jauh harus standar, bukan applet "keamanan tinggi" khusus yang mengubah kutipan apa pun yang diketikkan menjadi umlaut.
• Mendapatkan VM baru atau membangun kembali yang sudah ada seharusnya memakan waktu beberapa menit, bukan minggu

Saya telah melihat semua masalah ini, dan tidak terlalu menikmati bekerja dengan mereka. Namun saya juga memiliki setup VM di rumah yang saya gunakan sesuai pilihan. Itu berjalan lebih cepat daripada instalasi lokal dan memungkinkan hal-hal seperti lingkungan yang terpisah untuk proyek yang berbeda dan pembangunan kembali yang cepat ketika suatu lingkungan menjadi tidak stabil.

Saya bekerja dengan VM, tetapi saya tidak merekomendasikannya untuk proyek utama Anda.

Alasan saya menggunakan VM untuk pengembangan adalah karena saya harus mendukung proyek lawas (mis. VB6, .NET 1.1, dll ...) dan saya tidak ingin mengotori mesin utama saya dengan harus menginstal VS2003 / 2005 / vb6 / etc ... Itu berhasil OK, tapi ada masalah yang terputus-putus di sana-sini.

Selain itu, interaksinya lebih lambat, VM membutuhkan waktu untuk memulai / mematikan, tidak memiliki efek UI asli (seperti Aero di Win7), dll ...

Apa pun yang akan Anda hemat dalam hal uang yang akan Anda buang dan lebih lagi dengan kerumitan Anda akan memaksakan pada tim Anda. Plus, seperti seseorang di sini disebutkan, tidak ada dukungan multi-layar. Saya membutuhkan setidaknya 3 layar agar seproduktif mungkin.

Aturan pengembangan # 1 adalah untuk membuat pengembang Anda senang. Anda akan menemukan bahwa hampir tidak mungkin dilakukan dengan VM jarak jauh. Dukungan multi-monitor sangat buruk, lag dan blip jaringan merepotkan, dan penghematan biaya umumnya minimal.

Bekerja pada VM, tentu saja, tetapi memungkinkan untuk VM lokal juga, dan membuat komputer fisik menjadi binatang yang sangat cepat juga.

Saya telecommute 100%, dan antara ISP pribadi saya dan VPN - meskipun memiliki keandalan tinggi - mereka memiliki cukup banyak blip yang akan membuat saya gila jika saya tidak dapat bekerja dalam mode offline.

Saya biasanya hanya memutar berbagai gambar VirtualBox dan bekerja darinya. Menyalin beberapa ratus MB melalui kabel juga tidak terlalu intensif waktu jika Anda membutuhkan yang baru secara lokal.

Tim saya berhasil menerapkan konfigurasi "server PC lambat / VM Cepat". Untuk tim yang terdiri dari 20 pengembang, kami memiliki 8 prosesor, server RAM 256GB yang terhubung melalui fiber ke SAN yang sangat cepat. Itu mahal, tapi lebih murah daripada memberi setiap pengembang workstation dengan kinerja yang sama. Untuk tim kecil (4 pengembang) saya tidak yakin skala ekonomi akan masuk dan benar-benar menyelamatkan Anda apa pun.

VM untuk pengembangan layak untuk dilihat, tetapi biaya keuangan adalah alasan yang salah .

Ini dibahas secara singkat dalam Expert Holmes 'Marc . Pengiriman NET menggunakan NAnt & CruiseControl.net - singkatnya argumen untuk mengembangkan pada VM adalah bahwa hal itu mencegah segala aspek pekerjaan menjadi tergantung pada konfigurasi khusus pengembang. Anda nuke VM Anda di awal setiap proyek, dan kecuali Anda benar-benar membutuhkan alat tertentu, itu tidak terus menendang. Ini meminimalkan kemungkinan bahwa perubahan yang Anda buat akan merusak mesin siapa pun kecuali milik Anda. Pengembang mungkin menangis karena mainan mereka diambil - tetapi pada akhirnya, ketergantungan pada alat adalah kelemahan dan apa pun yang tidak dapat Anda lakukan secara intuitif di lingkungan yang bersih adalah bau.

Perhatikan bahwa saya tidak perlu percaya argumen yang disajikan di atas. Saya mengerti dan sampai batas tertentu selaras dengan mereka, tetapi saya membuatnya demi argumen, untuk menghasilkan diskusi.

Kerugian potensial

• Jika host VM turun ... Anda semua disemprot. Jika Anda pernah memiliki tim yang terdiri dari 20 orang berteriak, "GAH! HARUS TIDAK MENANGGUNG !?" serentak ... itu tidak menyenangkan.
• Jika Anda mengizinkan snapshot ... itu menghabiskan sumber daya dengan cepat. 20 orang * 10-20 foto masing-masing menghasilkan banyak ruang HDD (atau setidaknya cukup untuk mulai menyebabkan masalah).
• Jika Anda mengalami masalah dengan penggunaan sumber daya pada host, sekali lagi, semua orang mengalami rasa sakit.

IME, ini adalah solusi yang baik dan itu berfungsi, tetapi Anda memerlukan beberapa perangkat keras yang layak di host dan ketika hal-hal buruk terjadi, itu terjadi pada semua orang.

Ini gagal salah satu kriteria paling penting dari tes Joel.

Saya memastikan semua pengembang saya memiliki setidaknya i3 atau laptop atau desktop yang lebih baik dengan RAM sebanyak mungkin.

8GB adalah apa yang saya perjuangkan.

Itu membuat mereka lebih produktif, dan mereka benar-benar dapat menjalankan Virtual Box pada mesin lokal mereka untuk pengembangan dan pengujian, bukan pada mahal untuk memelihara server. Mereka dapat snapshot Virtual Box mereka menginstal hal-hal gila dan menguji berbagai browser dan installer dan semuanya dan dalam hitungan detik akan kembali ke konfigurasi yang dikenal baik tanpa perlu menghubungi layanan "IT".

Pengembang membutuhkan mesin tercepat di perusahaan, dengan izin RAM dan root terbanyak pada mesin lokal mereka. Akhir dari cerita.

Saya telah bekerja pada VMs sebelumnya untuk pengembangan, baik VM lokal (berjalan pada PC lokal) dan yang jauh. Yang lokal jauh lebih baik untuk bekerja daripada yang jauh.

VM jarak jauh, yang kami hubungkan dengan RDP, memiliki sedikit jeda antara setiap penekanan tombol dan tindakan. Dimungkinkan untuk berkembang dalam kondisi seperti itu untuk waktu yang singkat tetapi hari-hari menjadi sangat menyebalkan.

Saya dengan senang hati mengembangkan di bawah VM lokal di VMWare karena saya perlu menjalankan Flash Builder pada mesin Linux, dan cukup senang dengan itu asalkan memiliki cukup memori - itu cukup dapat digunakan.

Kami melakukan itu untuk mesin jarak jauh kami dan bekerja dengan cukup baik. Paling jarang bekerja dari rumah (biasanya hanya untuk perbaikan darurat di sana-sini) jadi kami hanya menggunakan netbook yang cukup lowend, dikirimkan kembali ke mesin desktop kami yang cepat di kantor. Mereka pasti masih lebih lambat (mungkin dibatasi oleh jaringan lebih dari apa pun), tetapi bekerja untuk tugas-tugas pendek setiap saat. Ini benar-benar tidak dapat diterima untuk kuda kerja penuh waktu, bagaimanapun, karena VM sering dapat menyebabkan sedikit kelambatan yang bahkan dengan perangkat keras terbaik, IMHO, sedikit mengganggu.

Di pekerjaan terakhir saya, kami melakukan hal itu:

Kami menggunakan Server Terminal Windows, tempat setiap pengembang memiliki akun. Pengembang masih memiliki PC biasa (karena mereka sudah ada di sana), tetapi PC hanya menjalankan klien RDP.

Kami melakukan pengembangan Java, jadi perangkat lunak yang digunakan di mana Java compiler + IDE (kebanyakan Eclipse), ditambah browser web, alat query DB, klien versi kontrol, dan kadang-kadang office sw (OpenOffice.org dalam kasus kami).

Kami tidak menemui masalah nyata, dan kinerjanya cukup baik.

Satu-satunya masalah sebenarnya adalah Anda benar-benar perlu berhati-hati untuk tidak mengganggu orang lain dalam beberapa situasi, karena Anda berbagi satu sistem. Ketika operasi TI diperlukan untuk melakukan salinan file besar atau menjalankan backup di server, kinerja menurun untuk semua orang. Ketika kami mengidentifikasi dan menyelesaikan ini (dengan menyalin dengan prioritas rendah, atau semalam), semuanya berjalan dengan baik.

Jadi peringatannya adalah: Mengevaluasi kinerja sesegera mungkin, dan merencanakan perangkat keras Anda dan penggunaannya sesuai.

TL; DR: Saya sudah melakukannya di banyak pekerjaan dan sekarang saya lebih suka.

Biaya adalah alasan yang salah untuk fokus. Inilah beberapa yang lebih baik.

Alasan

• Konsistensi platform dalam lingkungan yang berbeda (pengembangan, pengujian dan produksi).
  • Mengapa: Ini sepenuhnya menghilangkan vektor cacat, cacat dari perbedaan platform di lingkungan yang berbeda.
• Mengizinkan perubahan sistem seperti peningkatan yang pertama kali terjadi dalam pengembangan vms, diverifikasi, uji coba, verifikasi, dan putar ke produksi; semua jauh lebih mudah dengan pengembangan (dan uji) vms.
  • Mengapa: Kontrol. Saya dapat snapshot, rollback, mengidentifikasi delta, melakukan perubahan pada satu server dan menyebarkan keberhasilan dengan hanya menduplikasi vm, dll.
• Terkadang sistem yang Anda kembangkan hanya tersedia di jaringan yang aman. Atau, server yang akan dijalankan oleh perangkat lunak Anda mungkin hanya memiliki akses terbatas atau karakteristik jaringan yang berbeda.
  • Mengapa: Pengembangan VM dapat berada di VLAN yang memiliki akses ke sistem atau layanan yang terkunci. Atau jika server dev memiliki akses terbatas yang sama dengan server pengujian dan produksi, tidak pernah ada pertanyaan tentang pengkodean persyaratan pada karakteristik jaringan atau akses yang tidak akan tersedia.

Tantangan

Tantangan nomor satu adalah pengembangan jarak jauh, terutama jika Anda harus melalui gateway atau server lompat. Itu membuatnya sulit, terutama jika pengembang tidak berpengetahuan luas (mereka memiliki beberapa pengetahuan teknik sistem, pengetahuan jaringan, dll).

Ada banyak variasi pengembangan jarak jauh, tetapi mereka biasanya bermuara pada 2 perbedaan utama.

• Jalankan alat pengembangan Anda di lingkungan jarak jauh dan gunakan protokol seperti klien RDP, klien X11 jarak jauh, dll.
• Jalankan alat pengembangan Anda secara lokal dan gunakan protokol untuk secara transparan menyinkronkan atau mengeksekusi pada server jauh, sering menggunakan ssh sebagai lapisan transport.

Alat

Ada alat yang akan membantu dengan pengembangan jarak jauh, dan ada IDE yang memfasilitasi itu. Anda harus menyelidiki sejauh mana ia mampu pengembangan jarak jauh, banyak yang tidak tanpa berjalan di server yang sama kode sedang dikembangkan. Namun ada alat lain.

• Secure Shell: Sebagian besar pengaturan pengembangan jarak jauh yang sukses menggunakan ssh ke tingkat yang lebih besar, menggunakan login tanpa kata sandi (menggunakan otentikasi kunci), multihop transparan (memecahkan masalah server melompat) dan opsi konfigurasi lainnya untuk meningkatkan waktu respons. Catatan: Saya selalu mengalami masalah menggunakan implementasi SSH non-OpenSSH.
• Layar GNU / TMUX: Terminal multiplexer. Layar adalah kakek mereka dan masih kuat, tapi saya pikir sebagian besar orang sudah mulai beralih (atau bahkan mulai) pada TMUX.
• Vim / Emacs : Penjaga lama, tetapi keduanya bekerja bagus untuk pengembangan jarak jauh dengan cara yang berbeda. Ini Vim sehingga yang dibutuhkan hanyalah sebuah shell, sementara Emacs dapat berjalan secara lokal dan menggunakan TRAMP untuk pengembangan jarak jauh.

Pada taktik yang sedikit berbeda - sudahkah Anda memberikan spreadsheet yang menyoroti biaya penggunaan mesin lambat ini kepada manajer / akuntan Anda? Tunjukkan kepada mereka bahwa solusi VM (kecuali dilakukan dengan benar, dan itu tidak mudah) mungkin hanya menempatkan pengembang dan oleh karena itu perusahaan di kapal yang sama.

Ini akan tergantung pada seberapa besar daya administrasi yang Anda miliki atas pemasangan VMware, jika Anda dimasukkan ke dalam subpool prioritas rendah maka Anda akan memiliki mesin yang lambat tergantung pada aktivitas subpool lainnya.

Perangkat keras itu murah, programmer mahal.

Mengapa Anda ingin programmer Anda frustrasi dengan memberi mereka mesin pengembangan lambat? Biaya pemutakhiran perangkat keras artinya jika dibandingkan dengan manfaat kinerja yang akan mereka peroleh.

Minta mesin yang lebih baik. Paling tidak minta ram 4 gb. Menambahkan tablet 2gb lain akan diperoleh kembali dalam waktu kurang dari seminggu.

Kurangnya dukungan layar ganda selalu menjadi pembunuh pembunuh. Saya tidak bisa membayangkan melakukan pekerjaan pengembangan yang signifikan pada satu layar.

Sekarang, mereka melakukan uji coba / penyebaran / mengutak-atik, jadi saya tidak berpikir mereka harus jatuh dari tumpukan juga.

Jika Anda memiliki mainframe dengan 50 disk SSD di RAID10, dan hanya menggunakan 3-4 mesin pada mainframe itu, maka mungkin berhasil.

Kalau tidak, mereka laggy, sangat laggy (meskipun dalam beberapa kasus snapshot dapat mengimbangi itu).

Saya memiliki mesin desktop yang layak di kantor yang dapat saya hubungkan dari laptop saya melalui VPN menggunakan berbagi layar.

Ini bekerja selama berjam-jam mendukung insiden dan kerja jarak jauh paksa sesekali. Hal ini tentu lebih baik daripada mempertahankan lingkungan yang sepenuhnya dikonfigurasi pada mesin kedua, atau untuk mengembangkan hal-hal yang membutuhkan latensi rendah ke pusat data di WAN.

Namun, frustasi untuk bekerja seperti itu untuk waktu yang lama. Kadang-kadang saya didorong untuk bekerja pada paruh kedua hari itu begitu apapun yang membuat saya tetap berada di rumah tidak ada jalan.

Latensi dan layar real estat adalah dua pembunuh bagi saya.

Saya tidak berpikir Anda ingin pergi dengan solusi VM jarak jauh. Koneksi jaringan akan menjadi hambatan dan bahkan pada koneksi yang cepat, itu sudah cukup untuk menyebabkan frustrasi. Kami sedang beralih dari teknik ini ke menggunakan lingkungan pengembangan lokal.

Kami mengembangkan pada iMacs, yang sangat bagus, tetapi aplikasi web kami berjalan pada lingkungan Linux dalam Produksi. Masalah dengan ini adalah bahwa pada akhirnya, kita mungkin mengalami masalah yang hanya terjadi di Linux dan mungkin sulit untuk dipecahkan. Di situlah kekuatan mesin virtual masuk. Namun, saya bahkan tidak suka ide menggunakan VM 100% dari waktu.

Saya baru-baru ini belajar tentang Vagrant (http://vagrantup.com/docs/getting-started/why.html) dan Chef untuk membuat bekerja dengan VirtualBox sangat mudah. Vagrant memberi Anda kemampuan untuk memulai VM dengan mudah saat Anda membutuhkannya, dan menghancurkan VM saat Anda tidak membutuhkannya. Jadi saya bisa melakukan semua pengembangan saya menggunakan Mac saya. Kemudian ketika saya siap untuk menguji kode saya, saya dapat memulai VM untuk mengujinya, dan hanya menyimpannya selama saya membutuhkannya. Vagrant juga memberi Anda kemampuan untuk dengan mudah berbagi VM dengan rekan kerja Anda sehingga Anda semua dapat yakin bahwa Anda bekerja di lingkungan yang sama.

Saya akan merekomendasikan memeriksa Vagrant sehingga Anda setidaknya menyadari pilihan yang tersedia ketika datang untuk mengembangkan dan bekerja dengan VM.

Saya telah mengerjakan proyek warisan mengenai 5 mesin, masing-masing memiliki peran dalam pipa perhitungan (mesin 1 mengirimkan permintaan ke mesin 2, eh yang pada gilirannya akan mengirim permintaan ke mesin 3 dll). Pengaturan pemasangan pada mesin virtual menghemat waktu BESAR kami: 1. Sistem ini tidak dapat dibatalkan karena pengembang malas / tidak punya waktu untuk meng-encorporate pengujian dalam desain. 2. Terlalu banyak pengaturan yang digunakan dan saya perlu menghabiskan waktu mengaturnya dalam kelompok.

Sekarang saya menggunakannya karena saya mengerjakan terlalu banyak proyek sekaligus. Masalah utama yang saya miliki sekarang adalah: 1. VM menghabiskan terlalu banyak waktu untuk mempertahankan. 2. VM menghabiskan banyak sekali memori untuk dijalankan

Ini agak membuat VM sulit digunakan ketika Anda mencoba menggunakannya untuk memesan. Simpan satu mesin utama dengan email dan teks Anda, kembangkan di VM terdediasi. Menjaga hidup Anda tetap rapi dan bersih dengan biaya.

Seperti yang dinyatakan oleh orang lain, itu benar-benar tergantung pada masalah apa yang Anda coba selesaikan dengan VM Desktops dan kemudian menimbang manfaat dari penyelesaian masalah tersebut terhadap kerugian yang akan ditimbulkan oleh lingkungan VM.

Kami bergerak menuju lingkungan hibrid di mana semua pengembang darat kami akan memiliki mesin fisik tradisional tetapi pengembang luar negeri (bekerja dengan perusahaan outsourcing kecil sekarang) akan menggunakan desktop virtual. Masalah yang kami coba selesaikan dengan desktop jarak jauh terkait keamanan dan kinerja. Lingkungan virtual jelas akan memberi kita kendali lebih besar dari perspektif keamanan dan untuk kinerja kita hanya akan mentransfer "piksel yang diubah" daripada kode sumber lengkap dan harus mengimplementasikan server proxy dan semacamnya.

Masih tidak yakin apakah ini cara yang tepat untuk pergi, tapi ke mana tujuan kami.