Sanal Makineler Kullanarak Geliştirme Üzerine Düşünceler [kapalı]

Bir başlangıç ​​için geliştirme lideri olarak çalışacağım ve geliştirme için VM kullanmamızı önerdim. Test / geliştirme için VM'leri olan bir masaüstüne sahip olan her geliştiriciden bahsetmiyorum, tüm VM'lerin yönetildiği ve geliştiricilerin yerel olarak bir mikroPC'den (ChromeOS herkes?) Yerel olarak veya hatta evlerinden uzaktan çalıştığı bir sunucu rafına sahip olmaktan bahsediyorum. bilgisayar.

Bana göre, faydaları son derece ölçeklenebilir, uzun vadede daha ucuz, yönetimi daha kolay ve donanımı en yüksek potansiyelinden kullanmamız. Dezavantajları gelince, söz konusu kurulumu kurması / sürdürmesi için birine ihtiyaç duyacağımızdan başka belirli bir gösterici düşünemiyorum.

Bazılarınızın iş yerinizde benzer bir kuruma sahip olabileceğini ve düşüncelerinize ağırlık verebileceğini umuyordum. Teşekkürler.

Kalkınma bütçesinin bir parçası olarak ne kazanmayı umuyorsunuz? Bana öyle geliyor ki, bir epsilon için endişeleniyorsun. Geliştiricilere yönelik makinelerin maliyeti, geliştiriciyi çalışanlarda tutmak için toplam maliyetin% 5'inden azdır. Bu nedenle tek önemli soru "geliştiricilerin zaman kazanmasını sağlayacak mı?" Geliştirme yazılımını kurmak ve yükseltmek için zaman harcamak zorunda kalmazlarsa olabilir. Ya da ağ azalırsa ya da sunucu kapanırsa, ya da büyük olasılıkla, ağın karşısındaki cevap en az bitse, bu zaman alabilir. Modern gelişme, bir IDE ile tuşa basmadan tuş etkileşimi veya en azından çok akıllı bir editöre bağlıdır. Bu etkileşimi birkaç on milisaniyeyle bile geciktirmek geliştirici verimliliğini ortadan kaldırır. Geliştiricilerin bu yeni çalışma şeklini öğrenmesinin de maliyeti var.

Bunlar VM'lere itiraz değil, uzaktan geliştirmeye yönelik potansiyel itirazlardır.

Bence kurnaz ve palavra gibi davranıyorsun.

Her şeyden önce, makine maliyetleri bir geliştiricinin maliyetine kıyasla önemsizdir . Makine maliyetini en aza indirmemeli, verimliliği en yüksek seviyeye çıkarmalısınız.

İkincisi, gecikme (bant genişliği değil) birçok programlama görevinin anahtarıdır - özellikle de metin düzenleme. Geliştiricileriniz için makinelerde biriktirdiğiniz her dolar / pound / euro için, bir üretkenlik bile tutarsızlığı korumak için ağ yükseltmelerine en az on harcayacaksınız. Onları Pentium III'lerle birlikte bir çöp tenekesinde buldunuz.

Ayrıca, geliştiricilerinizin hedef son kullanıcı tarafından beklenenden en az makul bir oranda daha yakın bir ortam kullanmasında önemli bir yarar olduğunu düşünüyorum. Bir spesifikasyondaki resmi performans hedeflerinden bağımsız olarak, çoğu programcı, test ederken kodun "nasıl hissettiğine" biraz dayanmaktadır. Son kullanıcınınkinden tamamen farklı bir ortam kullanırken, büyük problemleri tamamen göz ardı ederken, önemsizlikler için zaman harcaması muhtemeldir.

Homojen bir ortam kadar çekici bir destek bakış açısıyla ses çıkarır ve geliştiricilerin makinelerinde mümkün olduğunca çeşitliliği teşvik etmelisiniz. Geliştiriciler zaten çok fazla desteğe ihtiyaç duymaz ve farklı bir grafik yongası, CPU, ağ bağdaştırıcısı vb.

Alt satır: sanallaştırılmış bir sunucu ortamında kullanılmak üzere (en azından öncelikle) amaçlanan bir kod yazıyorsanız , bunu geliştiricileriniz için sağlamanız gerekir. Test için yine de yapıyorsanız, geliştirme için de bir anlam ifade edebilir (ancak zorunlu değildir). Aynı şekilde, yine de çok fazla yetenekli bir sunucuya ve ağa ihtiyacınız varsa (veya en azından sahipseniz), halihazırda sahip olduklarınızı kullanarak bundan faydalanmak mantıklı olabilir .

Bununla birlikte, en tipik koşullar altında, bunun bana çözdüğünden daha fazla sorun getirmesi muhtemel görünüyor.

Geçmişteki fikirlerimden biri buydu: tüm gerekli yazılıma sahip yüksek performanslı bir sunucuya sahip olmak ve sadece Uzak Masaüstü aracılığıyla sunucuya bağlanmak için kullanılabilecek bir grup düşük performanslı masaüstü bilgisayarına sahip olmak.

Yararları:

• Sağlam yedekleme. Bazı geliştiriciler masaüstü bilgisayarlarını düzenli olarak yedeklemek istemeyebilir, bu nedenle merkezi bir çözüm daha güvenilir olur,
• Her geliştirici için her yerden çalışma imkanı. Bununla, şirketteki herhangi bir bilgisayardan da çalışmayı kastediyorum. Diyelim ki sabah, geliştirici sessiz çalışma koşulları istiyor. Kendi odasına gider ve orada çalışır. Sonra bir çift programlama yapmak veya daha sosyal bir ortamda çalışmak istiyor. Masaüstü bilgisayarını kapattı, on bilgisayarın olduğu başka bir odaya gitti ve oradan bağlandı. "Tüm uygulamalarımı yeniden yüklemeliyim" yok.

Gelecek yıllarda böyle bir şeyi asla kullanmayacağımı düşünmeme neden olan birkaç ciddi sorun var.

• Uzak çözümlerin özgüllüğü. Aynı anda birkaç bilgisayar ekranını kullanarak uzaktan çalışmaktan ne haber? Yani kolay mı? Açık mı? Uzaktan çalışırken günlük kullandığım kısayollar etkin mi? Çok emin değilim. Çalışmakta olan programların listesini görmek için Ctrl + ÜstKrkt + Esc tuşlarına basarsam ne olur? Oh evet, işe yaramıyor, şimdi farklı bir şekilde yaptığımı hatırlamalıyım.

• Performans isabet. Performans azalması olmayacağından emin değilim. Ve unutmayın, yavaş bir bilgisayar kullanan bir programcı mutsuz bir programcıdır. Ve programcılarını berbat koşullardan mutsuz eden şirket asla yüksek kaliteli yazılım üretmeyecek.

• Bir felaketin daha yüksek etkisi. Çözümü gereksiz bir sunucuda barındırır mısınız? Şirketinizde yedekli ağ var mı? Yönelticinin aşağı indiğini ve gereksiz olmadığını varsayalım. Bu, tüm geliştiricilerin çalışamadığı anlamına gelir. Hiç. Çünkü yerel olarak kurulu bir yazılımı yok. Çünkü kaynak kodları bile yok: sunucuda. Böylece herkes durur ve yönlendiricinin değiştirilmesini beklemek için bu insanlara saat başı ödeme yaparsınız.

• Donanım maliyetleri Tek sunucu yalnızca bir sunucuysa, maliyeti nedir? Diyelim ki, yirmi geliştirici varsa, sunucuda 64 GB RAM yeterli olur mu? Pek emin değilim. İki işlemcili dört çekirdekli çözüm yeterli olur mu? Yine, bazı şüphelerim var. Aksi takdirde, ne düşünüyorsun? Bir çeşit bulut mu? Veya birkaç sunucuda çalışan ölçeklenebilir bir çözümünüz var mı? Makine başına Windows Server ücretini (Windows kullanıyorsanız) ödemeye hazır mısınız?

• Elektrik maliyeti. Tamamen uzaktan çalışıyorsanız, yerel olarak çalışıyormuşuz gibi neredeyse aynı miktarda güç sunucu tarafı, yerel makine ve ağ tarafından boşa harcanan güç miktarını harcarsınız.

• Lisanslar. Bir fayda mı yoksa bir sorun olarak mı kullanmam gerektiğinden emin değilim, ancak bu durumda yazılım lisansının maliyetinin çok daha yüksek olacağını düşünüyorum.

Ve yine, yönetim, destek, dağıtım, bakımın tüm maliyetlerini düşünün. Bunun gibi özel bir çözümle, kolayca büyük olabilir, bir şeyin ne zaman başarısız olacağını saymaz, her geliştiricinin işine devam edebilmeyi bekleyen NOPing'i göreceksiniz.

Talep üzerine amazon ec2 örneklerini geliştirici makineler olarak kullanıyoruz. Bunun maliyetle alakası yok. Birkaç proje üzerinde çalışan bir "geliştirici havuzu" var ve projeler arasında hızlı bir şekilde hareket etme yeteneğine ihtiyacımız var.

Genel olarak, VM başlangıç ​​kurulum zamanından tasarruf sağlar. Ancak uzun vadede verimlilik kaybına bağlı olarak zaman harcar. Maliyet eksen dışıdır, çünkü geliştirici maliyeti makine maliyetinden çok daha fazladır.

Verimlilik maliyetleri - VM görüntüsünü başlatmak için geçen süre (birkaç dakika), zayıf yanıt verme ve kaynak / bellek kısıtlamaları. Bunlar başlangıçta pek değil, ama zamanla can sıkıcı oluyorlar.

Projelerimizden birinde, ilk kurulumu "kod indirme ve maven çalıştırma" işlemini basitleştirmek için kodu yeniden düzenledik. Bu değişiklikle, yeni bir geliştiricinin proje üzerinde çalışmaya başlaması basitti - ve şimdi kimse Amazon VM imajını kullanmıyor. Bunu diğer projelere de taklit etmek istiyoruz, ancak zaman alacak. O zamana kadar ec2 görüntülerimiz var.

Burada çok dikkatli olun. Geçenlerde, BT departmanındaki herkesin temelde aynı sebepten dolayı kendi VM'lerini kullandıkları bir müşteriye yerleştirildim - masanın üzerinde daha düşük uçlu PC'lere sahip olmalarını ve sonra da VM'yi uzaktan kontrol etmelerini ve normal işlerini yapmalarını sağlamak için.

Orada deneyim hoş değildi. Haftada en az bir kere, çeşitli nedenlerle çok yavaş çalışıyorduk. Genel olarak, ekipten birinin işlemci yoğun SSIS paketlerini ne zaman çalıştırdığını söyleyebiliriz. Sonunda bir kaçımızı farklı sunuculara taşıdılar, bu da bazılarına yardımcı oldu, ancak performans hiçbir zaman haklı değildi.

Bence bunu yapacaksanız - sunucu gücüne, işlem gereksinimlerinize, kaç makineye hizmet vereceğinize dair özeninizi yapın. Size biraz para kazandırabilir, ancak doğru şekilde uygulanmazsa, LOTS'a neden olabilir Baş ağrısı

Lütfen dikkat: Bu VM mimarisinin alevi DEĞİLDİR - sadece ilgilenen insanlar için bir uyarı - uygulamadan önce ördeklerinizin üst üste geldiğinden emin olun.

Sanal makinelerde geliştirme oldukça iyi çalışabilir, ancak doğru yapıldığında:

• VM'leri kullanmak, geliştiriciden bir taneden çok, tüm ekibiniz için tek bir bilgisayara sahip olmanıza izin vermesi, bunun iyi bir fikir olduğu anlamına gelmez
• Yeniden başlatma, 24 saatlik yanıt süresine sahip bir destek bileti açmayı gerektirmemelidir
• Geliştirme VM'leri, geliştiricilerin 5000 mil uzağındaki bir veri merkezinde olmamalıdır.
• VM'ler geliştiriciler tarafından yönetilebiliyor ve bu nedenle desteklenmiyor olsa da, bu, kaynak kontrolü gibi ağ servislerine erişememesi gerektiği anlamına gelmiyor.
• Uzak masaüstü bağlantısı standart olmalı, umlautlara yazılan herhangi bir alıntıyı dönüştüren bazı özel "yüksek güvenlikli" uygulamalar.
• Yeni bir VM edinmek veya mevcut bir tane yeniden oluşturmak haftalar değil dakikalar alacaktır

Tüm bu sorunları gördüm ve özellikle onlarla çalışmaktan hoşlanmıyorum. Ancak evde seçimde kullandığım bir VM kurulumum da var. Yerel bir kurulumdan daha hızlı çalışan ve farklı projeler için ayrı ortamlar ve ortamın dengesiz hale gelmesi durumunda hızlı yeniden yapılanmalar gibi şeylere izin verir.

VM'lerle çalışıyorum, ancak ana projeniz için bunu önermiyorum.

VM'leri geliştirme için kullanmamın nedeni eski projeleri desteklemem (ör. VB6, .NET 1.1, vb ...) ve VS2003 / 2005 / vb6 / etc'yi kurmak zorunda kalırken ana makinemi kirletmek istemiyorum. ... Tamam çalışıyor, ama burada ve burada aralıklı sorunlar var.

Ayrıca, etkileşim daha yavaştır, VM'lerin başlaması / kapanması biraz zaman alır, yerel kullanıcı arayüzü etkileri yoktur (Win7'deki Aero gibi), vb.

Para açısından ne kadar tasarruf edecekseniz harcayacağınız güçlükle ve takımınıza dayatacağınız güçlükle daha fazlasını kaybedersiniz. Ayrıca, burada belirtildiği gibi, çoklu ekran desteği yoktur. Mümkün olduğunca verimli olmak için en az 3 ekrana ihtiyacım var.

Bir numaralı gelişim kuralı, geliştiricilerinizi mutlu etmektir. Uzak VM'lerle yapmanın neredeyse imkansız olduğunu göreceksin. Çoklu monitör desteği sivilceli, ağda gecikme ve hatalar zahmetli ve maliyet tasarrufu genellikle asgari düzeyde.

Sanal makinelerde çalışın, elbette, ancak yerel sanal makinelere de izin verin ve fiziksel bilgisayarı da çok hızlı bir canavar haline getirin.

% 100 telekomünikasyon kullanıyorum ve kişisel ISS'm ile VPN arasında - yüksek güvenilirliğe rağmen - çevrimdışı modda çalışamazsam beni deli edecek yeterli uçurum var.

Genelde çeşitli VirtualBox görüntülerini döndürürüm ve onlardan çalışırım. Yerel olarak yenisine ihtiyaç duyarsanız, birkaç yüz MB tel üzerinden kopyalamak çok yoğun olmaz.

Ekibim başarıyla "yavaş PC / Hızlı VM sunucusu" yapılandırmasını uyguladı. 20 geliştiriciden oluşan bir ekip için, fiber üzerinden çok hızlı bir SAN'a bağlanan 8 işlemcili, 256 GB RAM sunucumuz vardı. Pahalıdır, ancak her geliştiriciye benzer performansa sahip bir iş istasyonu vermekten daha ucuzdur. Küçük bir ekip için (4 geliştirici) Ölçek ekonomilerinin tekmeleyip, sizi bir şey kurtarabileceğinden emin değilim.

Geliştirme için sanal makinelere bakmaya değer, ancak finansal maliyet yanlış sebep.

Bu, NAnt ve CruiseControl.net kullanılarak Marc Holmes'un Uzman .NET Tesliminde kısaca ele alındı - kısacası bir VM üzerinde geliştirme argümanı, çalışmanın herhangi bir yönünün geliştiricinin özel yapılandırmasına bağlı kalmasını engellediği yönündedir . Sanal makinenizi her projenin başlangıcında bombalarsınız ve aslında belirli bir araca ihtiyacınız olmadıkça tekme atmaya devam etmez. Bu, yaptığınız değişikliklerin sizinkinden başka birinin makinesinde kırılma olasılığını en aza indirir. Geliştiriciler oyuncaklarını ellerinden almakta ağlayabilir - ama sonuçta, araçlara güvenmek bir zayıflıktır ve temiz bir ortamda sezgisel olarak yapamayacağınız herhangi bir şey kokudur.

Yukarıda belirtilen argümanlara mutlaka inanmadığımı unutmayın . Anlıyorum ve bir dereceye kadar onlarla aynı hizaya giriyorum, ancak tartışma amacıyla onları tartışmalar için yapıyorum.

Potansiyel dezavantajları

• VM konak aşağı giderse ... Eğer konum tüm hortumlu. 20 kişiden oluşan bir ekibiniz varsa "GAH! HOST RESPONDING !?" diye bağırdı. birlikte ... eğlenceli değil.
• Anlık görüntülere izin veriyorsanız ... bunlar kaynakları çabucak tüketir. 20 kişi * 10-20 anlık görüntü, her biri çok fazla HDD alanı oluşturur (veya en azından soruna neden olacak kadar).
• Konakta kaynak kullanımıyla ilgili sorunlarla karşılaşırsanız, yine herkes acı çekiyor.

IME, bu iyi bir çözüm ve işe yarıyor, ancak ana bilgisayarda iyi bir donanıma ihtiyacınız var ve kötü şeyler olduğunda, herkes oluyor.

Bu, Joel testinin en önemli kriterlerinden birini alamaz.

Tüm geliştiricilerimin, alabileceği kadar RAM'i olan en az bir i3 veya daha iyi bir dizüstü bilgisayar veya masaüstüne sahip olduğundan emin olun.

8GB bunun için uğraşıyorum.

Onları daha üretken kılar ve aslında sanal kutuları korumak için pahalı yerine geliştirme ve test için yerel makinelerinde Sanal Kutu çalıştırabilirler. Sanal Kutu'larını çılgınca şeyler kurabilir ve farklı tarayıcıları ve yükleyicileri test edebilir ve her şeyi ve saniyeler içinde "BT" servisleriyle bağlantıya geçmeden bilinen iyi bir yapılandırmaya geri dönebilirler.

Geliştiriciler, yerel makinelerinde en fazla RAM ve kök izinleriyle, şirketteki en hızlı makinelere ihtiyaç duyar. Hikayenin sonu.

Yerel VM'leri (yerel bilgisayarda çalışan) ve uzaktakileri geliştirmek için daha önce VM'lerde çalıştım. Yerel olanlarla çalışmak, uzak olanlardan çok daha hoş.

RDP tarafından bağlandığımız uzak VM'ler, her tuş vuruşu ve eylem arasında az miktarda gecikmeye neden oldu. Bu şartlar altında kısa bir süre için geliştirme yapmak mümkündür, ancak gün-gün-gün dışında çok sinir bozucu oldu.

Mutlu bir şekilde VMWare üzerinde yerel bir VM altında geliştim çünkü Flash Builder'ı bir Linux makinesinde çalıştırmam gerekti ve yeterli hafızası olduğu sürece bundan çok memnundum - oldukça kullanışlıydı.

Bunu uzak makinelerimiz için yapıyoruz ve oldukça iyi çalışıyor. En nadiren evden çalışır (normalde yalnızca buradaki ve buradaki acil durum düzeltmesi için), bu yüzden ofisteki hızlı masaüstü makinelerimize uyarlanan oldukça düşük maliyetli netbooklar kullanıyoruz. Kesinlikle daha yavaştırlar (muhtemelen ağ tarafından her şeyden daha fazla sınırlıdırlar), ancak her zaman ve sonra kısa görevler için çalışmaktadırlar. Bu, tam zamanlı bir çalışma atı için gerçekten kabul edilemez, ancak VM, en iyi donanım olan IMHO'nun bile biraz rahatsız edici olduğu sık sık biraz gecikmeye neden olabilir.

Son işimde tam olarak şunu yaptık:

Her geliştiricinin hesabının olduğu bir Windows Terminal Server kullandık. Geliştiriciler hala düzenli PC'lere sahiplerdi (çünkü zaten oradalardı), ancak PC'ler yalnızca RDP istemcisini işletiyordu.

Java geliştirmeyi yaptık, böylece yazılım Java derleyici + IDE (çoğunlukla Eclipse), web tarayıcı, DB sorgulama araçları, sürüm kontrol istemcisi ve bazen ofis sw (bizim durumumuzda OpenOffice.org) kullanıldı.

Gerçek bir sorunla karşılaşmadık ve performans oldukça iyi oldu.

Tek gerçek sorun, bazı durumlarda başkalarını rahatsız etmemek için özen göstermeniz gerektiği idi çünkü bir sistemi paylaşıyorsunuz. BT işlemlerinin büyük dosya kopyalaması veya sunucuda yedeklemeler yapması gerektiğinde, herkes için performans düşer. Bunu tespit edip çözdüğümüzde (düşük öncelikli veya bir gecede kopyalayarak), her şey iyi sonuçlandı.

Bu yüzden uyarı: Performansı en kısa zamanda değerlendirin ve donanımınızı ve kullanımınızı buna göre planlayın.

TL; DR: Birden fazla işte yaptım ve şimdi tercih ediyorum.

Odaklanmanın yanlış nedeni maliyettir. İşte daha iyileri.

Nedenleri

• Farklı ortamlarda platform tutarlılığı (dev, test ve üretim).
  • Neden: Bir kusur vektörünü tamamen ortadan kaldırır, farklı ortamlardaki platform farklarından kaynaklanan kusurları.
• Yükseltme gibi sistem değişikliklerinin geliştirme vms'sinde ilk olarak gerçekleşmesine, doğrulanmasına, teste alınmasına, doğrulanmasına ve üretime alınmasına izin verir; geliştirme (ve test) vms ile hepsi çok kolay.
  • Neden: Kontrol. Fotoğraf çekebilir, geri alabilir, deltaları belirleyebilir, bir sunucuda değişiklik yapabilir ve vm'yi kopyalayarak vb. Bir başarıya ulaşabilirim.
• Bazen geliştirdiğiniz sistemler yalnızca güvenli bir ağda bulunur. Alternatif olarak, yazılımınızın çalışacağı sunucu yalnızca sınırlı erişime veya farklı ağ özelliklerine sahip olabilir.
  • Neden: Geliştirme VM'si, kilitli sisteme veya hizmete erişimi olan VLAN'da olabilir. Alternatif olarak, eğer dev sunucu test ve üretim sunucusuyla aynı sınırlı erişime sahipse, hiçbir zaman bir ağ özelliği veya mevcut olmayacak olan bir erişim üzerinde bir gereksinimi yanlışlıkla kodlama ile ilgili bir sorun yoktur.

Zorluklar

Bir numaralı zorluk, özellikle bir ağ geçidi ya da atlama sunucusundan geçmeniz gerektiğinde uzaktan geliştirmedir. Özellikle geliştiriciler yeterince yuvarlanmış değilse (bazı sistem mühendisliği bilgisine, ağ bilgisine, vb.) Zorlaştırır.

Uzaktan gelişmenin birçok çeşidi vardır, ancak bunlar genellikle 2 ana farklılığa kadar kaynar.

• Geliştirme araçlarınızı uzak bir ortamda çalıştırın ve RDP istemcileri, uzak X11 istemcileri, vb. Gibi protokolleri kullanın.
• Geliştirme araçlarınızı yerel olarak çalıştırın ve genellikle aktarım katmanı olarak ssh kullanarak uzak sunucuda şeffaf bir şekilde eşitlemek veya yürütmek için protokolleri kullanın.

Araçlar

Uzaktan geliştirmeye yardımcı olacak araçlar var ve onu kolaylaştıran IDE'ler var. Uzaktan geliştirme becerisinin ne dereceye kadar olduğunu araştırmanız gerekecek, birçoğu kodun üzerinde çalıştığı sunucu üzerinde çalışmayacak. Ancak başka araçlar da var.

• Güvenli Kabuk: Başarılı uzaktan geliştirme kurulumlarının çoğu, ssh'yi, parolasız girişleri (anahtar kimlik doğrulamasını kullanarak), saydam çoklu girişleri (atlama sunucusu sorununu çözer) ve yanıt süresini iyileştirmek için diğer yapılandırma seçeneklerini kullanarak daha fazla ssh kullanır. Not: SSH’nin OpenSSH’i olmayan uygulamalarını kullanırken her zaman sorun yaşadım.
• GNU Screen / TMUX: Terminal çoklayıcılar. Ekran onların büyükbabası ve hala güçlü oluyor, ama sanırım çoğu insan TMUX’e geçmeye (hatta başlamaya) başladı.
• Vim / Emacs : Eski gardiyan, ancak her ikisi de farklı şekillerde uzaktan gelişim için harika çalışıyor. Vim'dir, bu yüzden ihtiyacı olan tek şey bir kabuktur, Emacs ise yerel olarak çalışabilir ve TRAMP'ı uzaktan geliştirme için kullanabilir.

Biraz farklı bir yapıt üzerinde - yöneticilerinize / muhasebecilerinize bu yavaş makineleri kullanmanın maliyetini vurgulayan bir elektronik tablo verdiniz mi? Onlara bir VM çözümünün (doğru şekilde yapılmadıkça ve kolay olmadığının) geliştiricileri ve dolayısıyla şirketi aynı tekneye koyabileceğini belirtin.

Bu, VMware kurulumu üzerinde ne kadar yöneticiliğiniz olduğuna bağlı olacaktır, düşük öncelikli bir alt havuza yerleştirilirseniz, diğer alt havuzların faaliyetlerine bağlı olarak yavaş makinelere sahip olacaksınız.

Donanım ucuz, programcılar pahalı.

Programcılarınızın neden yavaş geliştirme makineleri vererek hayal kırıklığına uğramasını istiyorsunuz? Donanım yükseltmenin maliyeti, kazanacakları performans avantajıyla karşılaştırıldığında.

Daha iyi makineler isteyin. En azından 4 gb ram için isteyin. Başka bir 2 gb tablet ekleyerek bir haftadan kısa bir sürede geri kazanılır.

Çift ekran desteğinin olmaması her zaman anlaşma katili olmuştur. Tek bir ekranda önemli geliştirme çalışmaları yapmayı hayal bile edemiyorum.

Şimdi, test / dağıtım / kemanlama için rock yapıyorlar, bu yüzden yığından düşmeleri gerektiğini de sanmıyorum.

RAID10'da 50 SSD diskli bir ana makineniz varsa ve yalnızca bu ana bilgisayarda 3-4 makine kullanıyorsanız, o zaman işe yarayabilir.

Aksi takdirde, onlar gerçekten laggy, laggy (bazı nadir durumlarda snapshoting bunu telafi edebilir).

Dizüstü bilgisayarımdan VPN üzerinden ekran paylaşımı kullanarak bağlanabileceğim ofiste iyi bir masaüstü bilgisayarım var.

Mesai saatleri dışında destek olayları ve ara sıra zorlamalı uzaktan çalışma için çalışıyor. Tamamen yapılandırılmış bir ortamı ikinci bir makinede tutmaktan veya bir WAN'daki veri merkezine düşük gecikme gerektiren şeyler geliştirmek için kesinlikle daha iyidir.

Ancak, uzun süre bu şekilde çalışmak sinir bozucu. Ara sıra, beni evde bırakan her neyse yoldan çekildikten sonra, günün ikinci yarısında çalışmaya başladım.

Gecikme ve ekran emlak benim için iki katil.

Uzak bir VM çözümüyle gitmek istediğinizi sanmıyorum. Ağ bağlantısı tıkanıklık olacak ve hatta hızlı bir bağlantıda bile, hayal kırıklığına neden olmak için yeterli olabilir. Bu teknikten yerel kalkınma ortamlarını kullanmaya geçiyoruz.

Gerçekten güzel olan iMac'ler üzerinde geliştiriyoruz, ancak web uygulamalarımız Üretimde bir Linux ortamında çalışıyor. Bununla ilgili sorun, nihayetinde, sadece Linux'ta olan ve giderilmesi zor olabilecek bir sorunla karşılaşabileceğimizdir. Sanal makinelerin gücü burada devreye giriyor. Ancak, zamanın% 100'ünü VM kullanma fikrinden bile hoşlanmıyorum.

Geçenlerde Vagrant (http://vagrantup.com/docs/getting-started/why.html) ve Chef ile VirtualBox ile çalışmayı çok kolaylaştırmayı öğrendim. Vagrant, ihtiyaç duyduğunuzda kolayca VM başlatmanıza ve ihtiyaç duymadığınızda bir VM'yi yırtmanıza olanak tanır. Böylece Mac'imi kullanarak tüm gelişimimi yapabilirdim. Sonra kodumu test etmeye hazır olduğumda, test etmek için bir VM başlatabilir ve yalnızca ihtiyacım olduğu sürece saklayabilirim. Vagrant ayrıca, VM'leri çalışma arkadaşlarınızla kolayca paylaşma olanağını da verir, böylece hepiniz aynı ortamda çalıştığınızdan emin olabilirsiniz.

Vagrant'a göz atmanızı tavsiye ederim, böylece en azından VM'lerde geliştirme ve çalışma konusunda mevcut seçeneklerin farkında olmalısınız.

5 makineyle ilgili eski bir proje üzerinde çalışıyorum, her birinin bir hesaplama boru hattında rolü var (makine 1, makine 2'ye istek gönderir, sırayla makine 3'e istek gönderir). Bununla birlikte, sanal makineye yapılan ayar dağıtımı bize çok büyük zaman kazandırdı: 1. Devs tembel olduğu / tasarımda teste uyum sağlamak için zamanı olmadığı için sistem tartışılmaz. 2. Çok fazla kurulum yapıldı ve bunları gruplar halinde düzenlemek için zaman harcamam gerekiyordu.

Şimdi kullanıyorum çünkü aynı anda çok fazla projede çalışıyorum. Şu an sahip olduğum ana problem: 1. VM'ler bakımı çok fazla zaman harcıyor. 2. VM'ler çalıştırmak için çok büyük miktarda bellek tüketiyor

Bu tür, sipariş vermek için kullanmaya çalıştığınızda VM'lerin kullanımını zorlaştırır. Ana makinenizi e-postanız ve metninizle birlikte tutun, söz konusu VM'lerde geliştirin. Hayatınızı düzenli ve temiz tutar.

Diğerleri tarafından belirtildiği gibi, VM Desktop'lar ile çözmeye çalıştığınız sorunu gerçekten çözmenize ve ardından bu sorunu VM ortamının yaşayacağı dezavantajlara karşı çözmenin yararlarına ağırlık vermenize bağlıdır.

Tüm karasal geliştiricilerin geleneksel fiziksel makinelere sahip olacağı ancak açık denizdeki geliştiricilerin (şu anda küçük bir dış kaynak şirketiyle çalışan) sanal masaüstlerini kullanacağı karma bir ortama doğru ilerliyoruz. Uzak masaüstleriyle çözmeye çalıştığımız sorunlar güvenlik ve performansla ilgilidir. Sanal ortam bize güvenlik açısından daha fazla kontrol sağlayacak ve performans için tam kaynak kod yerine sadece "değişen pikselleri" transfer edeceğiz ve proxy sunucularını uygulamak zorunda kalacağız.

Hala bunun doğru yol olup olmadığından emin değilim, ama nereye gidiyoruz.