Sanal makine olarak teslim edilebilecek bir yazılımı kabul etmemek için herhangi bir neden var mı?

Bu, lojistikle ilgili bir soru değil, teknik bir soru.

Şirketim gömülü bazı yazılım çalışmalarını dış kaynaklardan sağladı. Özellikle, kendimiz yapmak için yeterli kurum içi bilgiye sahip olmadığımız için bizim için gömülü bir sistem geliştirmek için bir yükleniciye ödeme yaptık (yalnızca masaüstü uygulama geliştiricilerimiz var).

Böylece, müteahhitler yazılımı bitirdi ve bize sanal bir makinede teslim edip etmeyeceklerini sordular. VM, kaynak koduyla CodeWarrior projesi olarak önceden yapılandırılmış CodeWarrior IDE'yi içeren bir Windows 8 makinesidir. Buradaki fikir, bu projenin daha da geliştirilmesi için halihazırda yapılandırılmış olan VM içinde kod değişiklikleri yapmamıza izin vereceği şeklindedir.

Bunu, kendi geliştirme makinelerimizi projede kod değişiklikleri yapmak üzere nasıl yapılandıracağımıza yönlendirmelerine karşı yapmanın sakıncası var mı? Tahmin edebileceğim tek sorun, VM'nin yavaş çalışması ve kod değişikliği yaptığımızda projenin yeniden inşa edilmesi uzun zaman alıyor. Ancak diğer taraftan, önceden yapılandırılmış bir gömülü sistem geliştirme ortamı elde etme fikrini seviyorum, bu yüzden masaüstü bilgisayarıma yeni bir IDE eklemek zorunda kalmıyorum.

VM'lerin teslim edilebileceğini kabul etmemek için iyi bir neden düşünemiyorum, ancak eksik bir şey olması durumunda bu topluluk tarafından çalıştırılmak istedim.

Gördüğüm sorun, sanal makineyi kurma ve yapılandırma bilgisinin kurum içi olmadığı ve yapılandırma önemsiz değilse, yazılımın farklı sürümleri için yapılandırılması gerektiğinde diğer şirkete güveneceğinizdir. OS / kütüphaneler / donanım / her neyse. Sanal Makineyi kabul etmek, daha hızlı kalkıp çalışmaya devam etmek için iyidir ancak gelecekteki bakım için kendi sisteminizi nasıl yapılandırabileceğiniz konusunda ısrar ediyorum.

Bununla ilgili büyük bir dezavantaj görmüyorum, ancak kaynak kodunu içeren bir VM'yi kabul etmenin, bir makine ile birlikte yazılım ve geliştirme ortamı kurulu olarak gönderilmesini kabul etmekle aynı paranoya gerektirmesi gerektiğini söyleyebilirim. iç ağınıza erişimi olan bir ortamda çalıştırmadan önce VM'de yüklü hiçbir şey olmadığından emin olun.

VM'yi çalıştırıp çalıştırıyorsanız, kaynak kodu normal kod havuzlarınıza katlayabilmelisiniz, tıpkı sizin (muhtemelen) yalnızca bir kaynak kod arşivi teslim edildiğinde yapacağınız gibi.

Makinede yapılandırılmamış, belgelenmemiş, yeniden üretilmesi zor olan veya standart yapılandırmanızda kabul edilmeyen bir şey olduğundan endişe ediyorum.

Ymmv, ancak proje standart geliştirme makinelerinin yapıldığı ve emtia sunucuları / müşterileri üzerinde konuşlandırıldığı gösterilinceye kadar yapılan gelişmeyi pek düşünmüyorum.

Projelerimin birkaçında, yazılımın bu şekilde teslim edilmesini sağlamak için çok mücadele ettim. Mükemmel bir format.

Emin olun:

1. Yükleniciden aldığınız her sürümün kaynak kodunu alın ve kendi kaynak kontrol sisteminizle birleştirin
2. VM'nin çevre kurulumuyla ilgili belgeleri alın ve şirket içinde çoğaltabilirsiniz. Belgeleri kaynak kontrolünüze de ekleyin

Ek yararlar:

1. Sürümleri VM biçiminde arşivlerseniz (.vhd veya başka bir şeyi kaydedin), orijinal ekip parçalanmış veya gitmiş olsa bile, birkaç yıl boyunca onları çalıştırıp çalıştırmanız daha kolaydır.
2. Farklı sürümleri yan yana çalıştırmak çok daha kolaydır.
3. Bazı VMWare entegrasyonuyla (HyperV ile de mümkün olabilir), bunları otomatik olarak bir CI derlemesine entegre edebilirsiniz.
4. Bu, geliştirici zamanından tasarruf sağlar (başlangıçta), çünkü çok az veya hiç ortam ayarı yoktur.

Devam et derim.

Bu gerçekten asıl sözleşmede yapılması gereken bir şey. Zaten yukarıda ve öteye gidiyor olabilirler. Ekstra ödeme yapmadan yapılandırma talimatları almayı beklemiyordum, çünkü bu konuda daha fazla çalışma gerektiriyor.

Daha önce seninkilerle benzer bir durumdaydım. Geliştirme ortamımız Windows / Cygwin'dir ve bir hafta boyunca bizimle bir arayüz kodunu taramak için satıcı ziyaretinde bulunduk. Öncelikle Linux kullanıyorlar, bu yüzden burada oldukları hafta boyunca kendimizi Linux sanal makineleri ile ayarladık. Onlar buradayken oldukça iyi sonuç verdi ve gittikten sonra Cygwin ile bağlantı kurmakta çok az sorun yaşadık.

Bana kendi yeteneklerini hafife alıyormuşsun gibi geliyor. IDE kurmak, karşılaştırmak için çalışan bir örnek olmadan bile zor değil. Windows ve CodeWarrior lisans sözleşmelerini ihlal etmekten daha çok endişe duyarım. Doğru şekilde lisanslandıysanız, herhangi bir kurulum sorunu için Freescale'den destek alabilmeniz gerekir.

As FrustratedWithFormsDesigner dedi , kendiniz için makineyi nasıl kurulacağını bilmek gerekir. Bununla birlikte, potansiyel olarak bir VM'nin tamamı yerine makineyi sizin için yapılandıran bir komut dosyası sağlamalarını isteyebileceğinizi de eklemek isterim. Komut dosyası yeterince iyi yazılmışsa, makinenin nasıl kurulacağına dair tam bir güncel belgeye sahip olacaksınız (kaynak kodunu okuyarak), ayrıca komut dosyası sizin için her zaman ihtiyaç duyduğunuzda size zaman kazandıracak Yeni makine

Yeni bir Windows makinesi kurmanın standartlaştırılmasına / otomatikleştirilmesine yardımcı olmak için denediğim bir araç Chocolatey .

Chocolatey NuGet, apt-get gibi bir Windows Paket Yöneticisidir, ancak Windows düşünülerek oluşturulmuştur.

Kendi Chocolatey paketlerinizi kolayca oluşturabilir, daha sonra hemen hemen her şeyi yükleyip yapılandıracak bir PowerShell betiği oluşturabilirsiniz.

Yavaş çalışan ortam bir sorun olmamalı, sadece ona bellek ve CPU atmak. Çoğu SW geliştirmesi gibi masaüstü tipi işler için modern VM ek yükü çok küçüktür, donanım değiştirirken herhangi bir kurulum yapmanıza gerek kalmadan birçok kez tasarruf edilir.

Geliştirme sözleşmesinin, yüklenicinin size verilecek yükümlülüklerini ve yükümlülüklerini öngöreceğini düşündüm.

En azından, yapılandırmanın nasıl yürüdüğünü ve projeyi yeniden oluşturabileceğiniz, onu inşa edebileceğiniz ve uygulayabileceğiniz nokta için hayati olan şeylerin bir belgelenmesini ve belgelenmesini talep ediyorum.

Gitmeye hazır bir şeye sahip olmak açısından, VM'nin tamamen kabul edilebilir olduğunu düşünüyorum.

Kesinlikle belgeler için zorluyordum. Ben onsuz tereddüt ederdim, çünkü nasıl çalıştığını çok iyi anlayamıyorsanız, özellikle uygulamayı kendiniz desteklemeniz gerekiyorsa gelecekte varil üzerinde olabileceğinizi anlamadık.

Dahili olarak geliştirilen gömülü sistemler için bile, derleme ortamının nasıl kurulacağını açıklayan bir belgeye sahip olmak önemlidir. Ayrıca, oluşturma ortamını ayarlamak için gereken tüm ikili dosyaları / yükleme dosyalarını ve arşiv dosyalarını arşivlemeniz gerekir.

VM'yi kod teslim edilebilir olarak kabul etmem çünkü güncelleme yapmayı zorlaştırır. Geliştirme çalışması için bu sanal makineye altın bir görüntü olarak sahip olmalısınız. Bu mods yapmayı zorlaştırır. Bir geliştiricinin yeniden biçimlendirilmesi veya yeni bir makine edinmesi gerekir, bir VM kurup VM'yi çekmeleri gerekir.

Düzenlemeler yaparken, VM'nin yeni bir "altın kopyasını" işlemelisiniz. Kaynak kontrolünde neden böyle büyük bir ikili dosyayı yönetmek istiyorsunuz? Farklı olmak mümkün değil ve benim tecrübeme göre kaynak kontrolü yapmaya çalışmak, ikili bir şeyin altın bir kopyasını iyi bitmiyor. Altın kopyayı kimin düzenlediği üzerinde sıkı bir kontrol sağlayamazsanız, orada belgelenmemiş ve kimsenin bilmediği şeylerle sonuçlanacaksınız.

Bir geliştirici bana bu biçimde yazılım sunmak isterse, farklı bir geliştirici bulurdum. Bu bana bağımlılıklarını ortadan kaldıracak kadar profesyonel olmadıklarını ya da en azından onları belgelemediklerini söylüyor.

Ben de onlardan isterdim:

1. Kod ile kaynak kontrolüne giren bir metin dosyası oluşturun. Kaynak kontrol deposunun parçası olmayan, projeyi başlatmak ve çalıştırmak için ihtiyaç duyduğunuz tüm bağımlılıkları listeler (örneğin, CodeWarrior, hangi komut satırı araçlarına veya bağlı olduğunuz diğer harici uygulamalara).

2. Bağımlılıkları yüklemek için bir komut dosyası. Windows'da olduğunuzdan, dev ortamının kurulumunu otomatikleştirmek için bir Chocolatey betiği oluşturmak çok zor olmamalı. Sahip olduğunuz herhangi bir bağımlılık zaten çikolata paketinde bulunmuyorsa, yapabilirsiniz. Örneğin, Visual Studio ve SQL Server gibi ağır ticari araçları Chocolatey üzerinden yükleyebilirsiniz. Bu paketler tam özellikli deneme sürümlerini yükler ve bir lisans anahtarı girerek kilidi açılabilir. Bu yüzden, aynı şeyin CodeWarrior ile ve dev ortamınız için sahip olduğunuz diğer herhangi bir bağımlılıkla yapılabilmesi mümkündür.

Belki geliştiriciniz hala onunla çalışmak istemeniz için yeterince iyidir, ancak bu otomasyon işinde iyi değil. Bu da iyi, eğer durum buysa, ya otomasyon kısmını kendim yapardım, bağımlılıkları belirlemek ve senaryoyu çalıştırmak için onunla çalışırdım, ya da otomasyonu konusunda iyi olan başka bir geliştirici elde ederim. . Proje başlangıcında yapılmalıdır. Win8 VM'nin temiz, barebones kopyası hala yararlı olacaktır çünkü çikolatada betiğinizi test etmek için kullanabilirsiniz.

Bununla ilgili bir sorun olduğunu sanmıyorum, VM olarak yüklenen içerik yönetimi sistemleri gördüm ve müteahhitlerin size uygulamayı sürdürme ve genişletme yeteneği verdiğini söylediklerinizden bahsettim.

Bununla birlikte, diğer afişlerin de belirttiği gibi, yapacağım iki şey var. Öncelikle, VM'yi kurarken, onu ağınızdan ayrı bir makineye yerleştirdiğinizden emin olun. İnternetten bilinmeyen bir EXE indiremez ve makinenize yükleyemezsiniz.

İkincisi, eğer mümkünse bu izole edilmiş kopyayı kurum içi versiyonunu ayarlamak için referans olarak saklayın. Mümkünse derim, çünkü altında bulunduğunuz iş baskılarını bilmiyorum. Sonuçta, bu uygulamadan sorumlu olacak firmanızın BT departmanı / programcıları olacaktır. Yani, ne kadar çok şey biliyorsan o kadar iyi.