Bir geliştirme makinesi bir VM içinde olmalı mı? [kapalı]

Rob Conery tarafından yazılan bu yazı (sümüklü böcek notuna bakın), geliştirme ortamının sanal bir makinede çalıştırılması gerektiğini söylüyor. Ne dediğini ve kabullenme eğiliminde olduğunu anlıyorum ama yine de biraz tedirgin hissediyorum. Şimdi sanallaştırma o kadar olgunlaşmış ki, VM'lerin hızlarında çalışan üretim sistemleri bile sorun değil, ama söylediğim gibi burada bir şey beni rahatsız ediyor.

Geliştirme makinenizi sanallaştırmaya ne dersiniz? Bunu zaten yaptın mı? Öyle olsaydı, yol boyunca herhangi bir tuzak veya kanka var mı?

Bir şirket ortamında VM'lerde geliştirme konusundaki deneyimim, birçok çekirdeğin zorluklarla dolu sanallaştırılmasından dolayı, birçok işletme geliştirme makinesinin ihtiyaç duyduğu performansın elde edilmesinin zor olması.

Kod derleme testi iç döngüsünün olabildiğince hızlı olması, mümkün olan en iyi makinelerin yapılmasını gerektirir - derleme ve testlerin çalıştırılması, daha fazla çekirdekli makinelerde daha hızlı çalışır, çünkü bu faaliyetler eşzamanlı bir şekilde kolayca gerçekleştirilebilir * .

Ana akım geliştirme işletim sistemleri işletim sistemindeki mevcut çekirdeklerin sayısı geçicidir ve sanallaştırma yazılımı akıllıca bir çeşit "N çekirdeğe kadar" sözleşme sunabilinceye kadar, sanallaştırılmış geliştirme makineleri aynı tür üretkenlik iadelerini fiziksel cihazlarla sunmayacaktır.

EDIT: Bu sadece, genellikle sunucularda çalışmaya meyilli donanım maliyetlerini düşürmek için öngörülen şirket tarafından belirlenen VM'leri kullanma konusundaki kişisel hislerimi ifade ediyor. Yerel bir VM çalıştırmak, projeniz özellikle birden fazla işletim sistemi için kod geliştirmenizi gerektirmedikçe, iyi bir kaynak kontrol disiplini uygulamanız şartıyla, gereksiz görünüyor.

*: Derleme aşamaları ve test aşamaları içindeki alt görevler aynı anda çalıştırılabilir, aynı anda derlenemez ve test edilmez.

Tüm kişisel gelişimimi sanal makinelerde yapıyorum. Farklı ortamlar için birkaç VM kurulumum var ve iyi çalışıyor.

Ben dell studio 15 dizüstü bilgisayar (dört I7 2.8 ghz, 8 gb ram, ati grafik) çalışan sanal kutu yüklü olan 7 nihai 64bit kazanmak var. Tüm VM'lerimin dizüstü bilgisayara kayan bir 500GB harici USB sürücü kullandığını gördüm.

VM 0 - Temel şablon olarak Win 7 64bit temiz kurulum

VM 1 - Visual Studio 2008 araç seti ile 7 64bit (2 cpu, 4 gb ram, 120 gb hd) kazanın

VM 2 - Visual Studio 2010 araç seti ile 7 64bit (2 cpu, 4 gb ram, 120 gb hd) kazanın

VM 3 - Eclipse Java araç seti ile 7 64bit (2 cpu, 2 gb ram, 120 gb hd) kazanın

Çok yüksek IO gerektiren bir şey yapmıyorsam, performansın iyi olduğunu hissettim ve birileri bana laptop verdiyse ve gelişmeye başladığını söylesem VM'nin içinde olduğumu bilemedim.

Sanallaştırılmış makinelerle belirli geliştirme türlerinin (imkansız değilse de) çok daha zor olduğunu eklemek isterim.

Birkaç farklı USB çevre birim aygıtıyla (örneğin web kameraları, etiket yazıcıları, manyetik şerit okuyucular vb.) Entegre yazılım paketleri sunduğumuz bir şirkette çalışıyorum. USB bağlantı noktalarını sanallaştırılmış bir sunucuya eşlememe rağmen, üçüncü taraf satıcı aygıt sürücülerinde tuhaf ve anlaşılmaz sorunlar olduğunu fark ettim.

Dediğim gibi, bu durumun virütalize geliştirme makineleri üzerinde çalışmama garantisi verdiğini sanmıyorum, ancak henüz çözemediğimiz bir durum, bu nedenle laboratuarda farklı ortamlar için fiziksel iş istasyonlarını koruyoruz.

Şirketimizde şimdi VM'yi geliştirme ve test için kullanıyoruz. VM'leri kullanmanın bazı sakıncaları olsa da, faydaları önemli ölçüde ağır basmaktadır.

VM'leri kullanmaya başlamadan önce, yeni geliştiriciler için geliştirme makineleri ayarlamada sorun yaşadık. Takımdaki yeni geliştirici için ilk görev genellikle kendi geliştirme makinesini kurmaktı. Biz küçük bir şirketiz ve her zaman yeni bir ekip üyesine makinelerini kurmalarına yardım edecek insan gücümüz yoktur. Bu, farklı sorunlara yol açtı: bazen böcek sadece makinelerinde yeniden üretilebiliyordu ya da hiç üretemiyorlardı, uygulama düzgün yapamıyordu, vs. her zaman uyumlu olmayan çalışma ortamlarında.

VM'lere geçtiğimizde her şey değişti. Artık, bir VM'de ortamın projeyle ilgili her şeyle birlikte kurulmasından yalnızca bir kişi sorumludur. Tamamlandığında tüm ekip üyelerine VM'nin kopyası verildi. Bu, her yeni ekip üyesi için ortamı kurma süresini azaltır (VM'nin kopyalanması 1 saatten fazla sürmemelidir). Ayrıca, paralel olarak birden fazla çalışma ortamında çalışmamızı sağlar.

VM kullanmak için sakıncaları: hız. Sanal makineye yapılan performans görünür. Daha yavaş iş istasyonlarında gelişimi neredeyse imkansız hale getirebilir. İyi bir iş istasyonunuz varsa (dört çekirdekli, 8 + GB RAM, SSD) muhtemelen farketmezsiniz.

Diğerlerinin de belirttiği gibi, birkaç şeye bağlıdır:

• Ortamınız nasıl görünüyor?
• Geliştirme yapmak için yeterli erişim hakkına sahip misiniz?
• HW'niz koparmak için mi?

Çevre, ortam

Bir projenin birden fazla sürümünde çalışıyorsanız, VM kullanmak yardımcı olabilir; çoklu projeler; veya normalde çalıştırdığınızdan farklı bir işletim sistemi hedeflemek (ana işletim sistemi işletim sistemi). Çok fazla SharePoint çalışması yapıyorum ve bir sürümün farklı sürümleri için farklı bir makine çalıştırabilmem yararlı oluyor çünkü farklı bir makineyi başlatabilirim ve GAC / veritabanının durumu için iyi hissediyorum. Ayrıca, bir * nix uygulama ortamını hedeflemeniz gerekiyorsa, ancak bir Windows makineniz varsa, yine de bir VM'de geliştirme yapabilirsiniz (bu, genellikle .NET geliştirme yaptığım halde evde Ruby'yi nasıl öğrendiğimdir). ASP.NET geliştirme sınamasını yaparken / uygulamanın sonuçta çalışacağı IIS'nin aynı sürümünde geliştirirken (bu aynı rasyonel diğer sunucu hedef ortamları için de geçerlidir) savunuculuk yapıyorum. İşletim sistemi sürümüne bağlı olarak bazı küçük fakat kritik farklılıklar olabilir. Bunun, belirli bir IIS / OS sürümünü kodlamanız gerektiği anlamına gelmediğini unutmayın, ancak gerçekten dürüst olalım, gerçekten sadece yerel makinenizde kullanmayacağınız bir yerde çalışmak zorunda.

VM'ler ayrıca (kullanılan yazılıma bağlı olarak) mevcut makine durumunun fotoğraflarını çekmenize ve / veya klonlamanıza izin verir. Bu bir şeyi prototiplerken paha biçilmez olabilir ve GAC / Kayıt Defterinizde / vb. Ne olduğu konusunda endişelenmenize gerek yok. Onları da vaktinden önce bir müşteri demosu hazırlarken çok değerli buldum. Demo ortamı VM'de olduğu için müşteriye ne yaptığımızı gösterme noktasına kadar çalışmaya devam edebilirim çünkü farklı bir makinede çalışıyordum .

Yeterli haklar

Bu genellikle erişim hakları konusunda oldukça gergin politikalar içeren bir şirkette çalışan insanlar için geçerlidir. Makinenizde düzensiz yönetici bulunamıyorsa, bu, bir VM'de çalışmak için iyi bir zaman olabilir. Tipik olarak, güçler yalnızca ana işletim sisteminizi kilitlemekten endişe duyarlar, misafir tamamen açık olabilir (izinler akıllıca olabilir). Gezici profillerle, sakat yönetici haklarıyla ve VS 2010'u çalıştırmakla ilgili garip sorunlarla karşılaştım; VM kullanmak bu sorunları önlememe izin verdi.

HW'niz koparmak için mi?

Bu, VM görüntülerinizin bir sunucuda ve uzaktan kumandanızda bulunduğunu veya yerel olarak çalıştırıldığınızı gösterir. Eğer sunucu üzerinde çalışıyorsanız, en büyük sorun muhtemelen aynı donanım üzerinde çalışan çok fazla VM olması. Yerel olarak temel olarak bol miktarda RAM istersiniz ve sabit sürücünüz için R / W tamponunu ne sıklıkta aşırı yüklediğinizi en aza indirirsiniz. Temel LOB / SharePoint / ASP.NET geliştirmesi için en az 8 GB RAM ve bir çift sabit sürücü yapılandırmasının pratikte iyi çalıştığını gördüm (bir i5 çalıştırarak ancak Core 2 ile de çalıştım). İkinci sabit disk, performanstaki en büyük farkı yaratıyor.

Not: Bunu yedekleyecek hiçbir istatistiklerim yok, ancak Virtual PC'nin hem VMWare hem de Virtual Box'a kıyasla daha düşük performans gösterme eğiliminde olduğunu fark ettim. Bununla çalışmadığım için Hyper-V ile konuşamam. Sanal bilgisayar kullanıyorsanız (sanal makinenin ilk baskısı olarak) sanallaştırıcı yazılımı kullanarak sanal bir yazılım kullanıyorsanız şaşırmam.

Her zamanki gibi: bağlıdır. Örneğin, kesinlikle gerçek zamanlı veya bilgisayar oyunu ile ilgili bir gelişme için bunu tavsiye etmem.

Kişisel deneyimim: 2009'un sonlarında bir iMac'im var ve Visual Studio 2010'un Parallels Desktop'ta kod editöründe bir tuşa basmanın kaydolması birkaç saniye sürdüğü için temelde kullanılamaz olduğunu buldum. SQL Server Management Studio'daki Windows, odağı değiştirir ve odağı rasgele olarak değiştirir. Daha yeni boot kampına girdim.

Elbette, yeni bir projem, Windows tabanlı bir yapılandırma aracıyla bir iOS uygulamasını içerecektir, bu nedenle sanallaştırmayı kullanmamak çok acı verici olabilir, ancak masaüstü sanallaştırma teknolojisi geçen yıl yeterince ilerlememişse, Muhtemelen burada başka bir masaüstü ayarlayacağım.

Bir sunucu uygulamasını test etmek söz konusu olduğunda, bu farklı bir durum, bunu sanallaştırmaktan tamamen mutluyum, ancak geliştirme uygulamalarımda yanıt vermem gerekiyor.

VM'leri geliştirme için kullandım ve genel olarak kendi makinemdeki geliştirmeden çok farklı değil. Kaynak Denetimi'ni doğru kullanıyorsanız pek fazla fark yoktur.

Başlıca farklar, herhangi bir nedenle çevrimdışı olmanız durumunda, size uygun bir geliştirme makinenizin olmaması, bu nedenle evden çok seyahat etmeniz veya çalışmanızın pek iyi olmaması. Ayrıca Uzak Masaüstü'nde birden fazla monitörü nasıl çalıştıracağımı da asla bulamadım, ancak ilkemle ilgili bir sorundan ziyade benim başarısız olduğumdan eminim. Genelde ana monitörümü geliştirme için kullandım ve ikincisini masaüstü makinem için e-posta, tarayıcılar vb. Kullanmaya devam ettim.

Kodunuzu farklı platformlarda (özellikle de yükleyici geliştirme gibi) çalışıp çalışmadığını kontrol etmeniz gereken bir şekilde çalışıyorsanız, farklı işletim sistemi sürümleri için VM'leri çalıştırabilmenizin çok kullanışlı olduğunu ekleyeceğim.

Onları önceki şirkette kullandım. Bazı üçüncü taraf kontrolleri aynı şirketin diğer versiyonlarıyla iyi bir şekilde bir arada bulunamamıştır. Ayrıca diğer işletim sistemlerini test etmek ve hata ayıklamak için bir çift kullandım (XP vs Vista vs 7). Bir sanal ürün, eski ürünler için VB6 ve VS2003'e sahipti. Evet, tipik bir geliştiricinin makinesinde yavaş ve zahmetli olabilir, ancak "bağışladığım" birkaç yedek sabit diskim vardı ve sanalları kendi disk denetleyicilerinde kendi sabit disklerine koydum. Sanalları kullanmaya devam eden son kişi bendim ve bazı hatalar için sadece üzerinde çalışabildim (işletim sistemi ve bileşen endişeleri nedeniyle).

Çocukların bazıları beta yazılım yükleyerek yakıldı ve MS’teki betaların bazıları kaldırılamadı, bu yüzden sabit disklerini yeniden biçimlendirene kadar sanal kullanmak zorunda kaldılar.

Sanallarda geliştirmek için tavsiyem, minimum 8GB RAM ile bir şeyler elde etmektir. 16 ya da daha fazlası daha iyi olurdu, çünkü "buzul" üzerindeki hızlarda çalıştırmak için sunucunun RAM'ının yaklaşık 1,5GB'lık sanal ihtiyaçlarını karşılayan herhangi bir görsel stüdyo bulacaksınız. Ayrıca, bir bilgisayar satın alırken çok fazla sabit disk edinin. Yedek donanım destenizden seçtiğiniz sürücüler için, çalışacağınız VHD'nin en az 2 katı boyutta olanları arayın.