Ci sono dei motivi per non accettare un software consegnabile come macchina virtuale?

Questa è una domanda sulla logistica, non una domanda tecnica.

La mia azienda ha esternalizzato alcune attività di software incorporato. In particolare, abbiamo pagato un appaltatore per sviluppare un sistema integrato per noi poiché non disponiamo di adeguate conoscenze interne per farlo da soli (abbiamo solo sviluppatori di applicazioni desktop).

Quindi, gli appaltatori hanno finito il software e hanno chiesto se potevano consegnarcelo in una macchina virtuale. La macchina virtuale è una macchina Windows 8 contenente l'IDE CodeWarrior preconfigurato con il codice sorgente come progetto CodeWarrior. L'idea è che ciò ci consentirà di apportare modifiche al codice all'interno della VM già configurata per l'ulteriore sviluppo di questo progetto.

Ci sono degli svantaggi nel fare questo rispetto al fatto che ci guidano attraverso come configurare le nostre macchine di sviluppo per apportare modifiche al codice al progetto? L'unico problema che posso prevedere è che la VM funziona lentamente e ci vuole molto tempo per ricostruire il progetto quando effettuiamo modifiche al codice. D'altra parte, mi piace l'idea di ottenere un ambiente di sviluppo del sistema incorporato preconfigurato, quindi non devo aggiungere ancora un altro IDE sulla mia macchina di sviluppo dell'applicazione desktop.

Non riesco davvero a pensare a una buona ragione per non accettare un deliverable VM, ma volevo solo eseguirlo da questa community nel caso ci fosse qualcosa che mi manca.

Il problema che vedo è che la conoscenza dell'installazione e della configurazione della macchina virtuale non è interna e se la configurazione non è banale, ti affidi all'altra società quando il software deve essere configurato per diverse versioni di il sistema operativo / librerie / hardware / qualunque cosa. Accettare la VM va bene per iniziare e funzionare più velocemente, ma insisto per illustrare come configurare il proprio sistema per la futura manutenzione.

Non vedo un grosso inconveniente con esso, ma direi che accettare una VM con il codice sorgente su di essa dovrebbe comportare la stessa paranoia dell'accettazione di una spedizione di una macchina con il software e l'ambiente di sviluppo installati, quindi per favore sicuramente non c'è niente di male installato sulla VM prima di farlo girare in un ambiente che ha accesso alla tua rete interna.

Se / quando la VM è attiva e funzionante, dovresti essere in grado di piegare il codice sorgente nei tuoi normali repository di codice, come (probabilmente) avresti fatto solo con un archivio di codice sorgente consegnato.

Sarei preoccupato che nella macchina ci sia qualcosa di non documentato, difficile da riprodurre o non accettabile nella configurazione standard.

Ymmv, ma non prendo davvero in considerazione lo sviluppo fatto fino a quando il progetto non può essere dimostrato di costruire le macchine di sviluppo standard e distribuito sui server / client delle merci.

In alcuni dei miei progetti, ho dovuto lottare duramente per ottenere il software consegnato in questo modo. È un formato eccellente.

Accertati di:

1. Ottieni il codice sorgente di ogni versione che ottieni dall'appaltatore e uniscilo nel tuo sistema di controllo del codice sorgente
2. Ottieni documentazione sulla configurazione dell'ambiente della VM e puoi riprodurla internamente. Aggiungi anche la documentazione al controllo del codice sorgente

Benefici addizionali:

1. Se archivi le versioni in formato VM (salva il .vhd o qualcosa del genere) è molto più semplice metterle in funzione per diversi anni, anche se il team originale è frammentato o scomparso.
2. È molto più semplice eseguire diverse versioni affiancate.
3. Con alcune integrazioni VMWare (potrebbe essere possibile anche con HyperV), è possibile integrarle automaticamente in una build CI.
4. Risparmia tempo per gli sviluppatori (all'inizio), perché c'è poca o nessuna configurazione dell'ambiente.

Direi di provarci.

Questo è davvero il genere di cose che avrebbero dovuto essere risolte nel contratto originale. Potrebbero già andare oltre. Non mi aspetto di ottenere istruzioni sulla configurazione senza pagare un extra, perché richiede più lavoro da parte loro.

Sono stato in una situazione simile alla tua prima. Il nostro ambiente di sviluppo è Windows / Cygwin e abbiamo avuto una visita dal fornitore per una settimana per scrivere un codice di interfaccia con noi. Usano principalmente Linux, quindi ci siamo dotati di macchine virtuali Linux per la settimana in cui sono stati qui. Ha funzionato abbastanza bene mentre erano qui e abbiamo avuto pochi problemi a portarci su Cygwin dopo che se ne sono andati.

Mi sembra che tu stia sottovalutando le tue abilità. Impostare un IDE non è così difficile, anche senza un esempio funzionante con cui confrontarlo. Sarei più preoccupato di violare gli accordi di licenza di Windows e CodeWarrior. Se hai una licenza adeguata, dovresti essere in grado di ottenere supporto da Freescale per eventuali problemi di installazione.

Come ha detto FrustratedWithFormsDesigner , devi sapere come configurare la macchina per te stesso. Tuttavia, vorrei aggiungere che potresti potenzialmente chiedere loro di fornire uno script che configura la macchina per te, piuttosto che un'intera VM. Se lo script è scritto abbastanza bene, avrai l'esatta documentazione aggiornata su come impostare la macchina (leggendo il codice sorgente), inoltre lo script lo farà per te, risparmiando tempo ogni volta che hai bisogno di un nuova macchina.

Uno strumento con cui sto sperimentando per aiutare a standardizzare / automatizzare la configurazione di una nuova macchina Windows è Chocolatey .

ChocolateGioGet è un gestore di pacchetti di macchine, un po 'come apt-get, ma costruito pensando a Windows.

Puoi potenzialmente creare i tuoi pacchetti Chocolatey abbastanza facilmente, quindi creare uno script PowerShell che installerà e configurerà praticamente tutto.

L'ambiente che funziona lentamente non dovrebbe essere un problema, basta lanciare memoria e CPU. Il sovraccarico della moderna VM per il tipo di desktop funziona come la maggior parte dello sviluppo di SW è molto piccolo, viene salvato molte volte senza dover eseguire alcuna configurazione quando si cambia hardware.

Avrei pensato che il contratto di sviluppo prevedesse i risultati e gli obblighi del contraente nei tuoi confronti.

Come minimo, richiederei una passeggiata e una documentazione su come funziona la configurazione e ciò che è vitale al punto che è possibile ricreare il progetto, costruirlo e distribuirlo da soli.

In termini di avere qualcosa pronto, penso che la VM sia perfettamente accettabile.

Sicuramente spingerei per la documentazione. Sarei titubante senza di essa perché, a meno che tu non abbia una comprensione di alto livello di come funziona, potresti essere sopra un barile in futuro, in particolare se hai bisogno di supportare tu stesso l'applicazione.

Anche per i sistemi embedded sviluppati internamente è importante avere un documento che descriva come impostare l'ambiente di compilazione. È inoltre necessario archiviare tutti i file binari / i file di installazione degli strumenti e le librerie necessarie per configurare l'ambiente di compilazione.

Non accetterei VM come codice consegnabile perché rende difficile effettuare aggiornamenti. Devi avere quella VM come immagine d'oro per fare il lavoro di sviluppo. Ciò rende più difficile creare mod. Uno sviluppatore deve riformattare o ottenere una nuova macchina, deve installare una macchina virtuale ed estrarre la macchina virtuale.

Quando si apportano modifiche, è necessario eseguire il commit di una nuova "copia d'oro" della VM. Perché vorresti gestire un grosso file binario come quello nel controllo del codice sorgente? Non è possibile diff, e nella mia esperienza, cercando di controllare il codice sorgente, una copia d'oro di qualsiasi cosa binaria non finisce bene. A meno che tu non riesca a mantenere un controllo rigoroso su chi modifica la copia d'oro, finirai con qualcosa che non è documentato e nessuno lo sa.

Se uno sviluppatore volesse fornirmi software in quel modulo, troverei uno sviluppatore diverso. Questo mi dice che non sono abbastanza professionali da scrivere le loro dipendenze o almeno documentarle.

Li avrei entrambi:

1. Creare un file di testo che viene verificato nel controllo del codice sorgente con il codice. Elenca tutte le dipendenze necessarie per far funzionare il progetto, che non fanno parte del repository di controllo del codice sorgente (ad esempio CodeWarrior, qualunque strumento da riga di comando o altre app esterne da cui dipendi).

2. Uno script per installare le dipendenze. Dato che sei su Windows, non dovrebbe essere troppo difficile creare uno script Chocolatey per automatizzare l'installazione dell'ambiente di sviluppo. Tutte le dipendenze che hai che non sono già pacchetti cioccolatini, puoi fare. Ad esempio, è possibile installare strumenti commerciali pesanti come Visual Studio e SQL Server tramite Chocolatey. Tali pacchetti installano le versioni di prova, che sono complete, e possono essere sbloccate inserendo una chiave di licenza. Quindi è possibile fare la stessa cosa con CodeWarrior e qualsiasi altra dipendenza che hai per il tuo ambiente di sviluppo.

Forse il tuo sviluppatore è davvero abbastanza bravo da voler ancora lavorare con lui / lei, ma non è bravo in questa roba di automazione. Va bene lo stesso, se così fosse, o farei la parte dell'automazione da solo, lavorando con lui / lei per identificare le dipendenze e far funzionare lo script, o farei fare un altro sviluppatore che è bravo nell'automazione a farlo . Dovrebbe essere fatto all'inizio del progetto. Una copia pulita e barebone di una VM Win8 sarebbe comunque utile perché puoi usarla per testare il tuo script Chocolate.

Non credo che ci sia un problema con questo, ho visto i sistemi di gestione dei contenuti che si installano come macchine virtuali e da quello che dici i contraenti ti hanno dato la possibilità di mantenere e ampliare l'applicazione tu stesso.

Tuttavia, come hanno notato altri poster, ci sono due cose che vorrei fare. Innanzitutto, assicurarsi che durante l'installazione della VM, inserirla in un computer separato dalla rete. Non scaricare un EXE sconosciuto da Internet e installarlo sul tuo computer.

In secondo luogo, se possibile, conservare questa copia isolata come riferimento per l'impostazione della versione interna. Dico, se possibile, perché non conosco le pressioni economiche che subisci. Alla fine, saranno i dipartimenti IT / i programmatori della tua azienda a essere responsabili di questa applicazione. Quindi, più ne sai e meglio è.