Are there any reasons not to accept a software deliverable as a virtual machine?

This is a question about logistics, not a technical question.

My company has outsourced some embedded software work. Specifically, we have payed a contractor to develop an embedded system for us since we do not have adequate in-house knowledge to do it ourselves (we only have desktop application developers).

So, the contractors have finished the software and they have asked if they may deliver it to us in a virtual machine. The VM is a Windows 8 machine containing the pre-configured CodeWarrior IDE with the source code as a CodeWarrior project. The idea is that this will allow us to make code changes within the VM that is already configured for further development of this project.

Are there any drawbacks to doing this as opposed to having them walk us through how to configure our own development machines to make code changes to the project? The only problem I can foresee is the VM running slowly and it taking a long time to rebuild the project when we make code changes. But on the other hand, I like the idea of getting a pre-configured embedded system development environment so I don’t have to add yet another IDE on my desktop application dev machine.

I can’t really think of a good reason why not to accept a VM deliverable, but I just wanted to run it by this community in case there’s something I’m missing.

The problem I see is that the knowledge of setting up and configuring the virtual machine is not in-house, and if configuration is non-trivial then you’ll be relying on the other company when the software needs to be configured for different versions of the OS/libraries/hardware/whatever. Accepting the VM is fine to get up and running faster, but I’d insist on getting walk-through on how to configure your own system for future maintenance.

I don’t see a massive draw-back with it, but I would say that accepting a VM with the source code on it should entail the same paranoia as accepting a shipment of a machine with the software and dev environment installed, so please make sure there’s nothing bad installed on the VM before you spin it up in an environment that has access to your internal network.

If/when you have the VM up and running, you should be able to fold the source code into your normal code repositories, as you (probably) would’ve done with just a source code archive delivered.

I would be worried that there is something configured in the machine that is undocumented, difficult to reproduce, or not acceptable in your standard configuration.

Ymmv, but I don’t really consider the development done until the project can be demonstrated to build off the standard dev machines and deployed on the commodity servers/clients.

In a few of my projects, I’ve had to fight hard to get software delivered this way. It’s an excellent format.

Make sure you:

Get the source code of each release you get from the contractor, and merge it into your own source control system
Get documentation on the VM’s environment setup, and can reproduce it in-house. Add the documentation to your source control as well

Additional benefits:

If you archive the releases in VM format (save the .vhd or something) it is much easier to get them up and running several years down the line, even if the original team is fragmented or gone.
It is much easier to run different versions side by side.
With some VMWare integration (it might be possible with HyperV too), you can integrate these into a CI build automatically.
It saves developer time (at the beginning), because there’s little to no environment setup.

I’d say go for it.

That’s really the sort of thing that should have been worked out in the original contract. They may already be going above and beyond. I wouldn’t expect to get configuration instructions without paying extra, because it requires more work on their part.

I’ve been in a similar situation as yours before. Our development environment is Windows/Cygwin and we had a vendor visit for a week to cowrite some interface code with us. They primarily use Linux, so we set ourselves up with Linux virtual machines for the week they were here. It worked out quite well while they were here and we had little trouble porting over to Cygwin after they left.

It sounds to me like you’re underestimating your own abilities. Setting up an IDE is not that hard, even without a working example to compare it to. I would be more concerned about violating Windows and CodeWarrior licensing agreements. If you’re properly licensed, you should be able to get support from Freescale for any setup issues.

As FrustratedWithFormsDesigner said, you need to know how to set up the machine for yourself. However I would like to add that you could potentially ask them to provide a script that configures the machine for you, rather than an entire VM. If the script is written well enough, you’ll have exact up-to-date documentation of how to set up the machine (by reading source code), plus the script will do it for you, saving you time every time you need a new machine.

A tool I’m experimenting with to help standardize/automate setting up a new Windows machine is Chocolatey.

Chocolatey NuGet is a Machine Package Manager, somewhat like apt-get, but built with Windows in mind.

You can potentially build your own Chocolatey packages pretty easily, then create a PowerShell script that will install and configure practically everything.

Environment running slowly should not be an issue, just throw memory and CPU at it. Overhead of modern VM for desktop type work like most SW development is very small, it is saved many times over by not needing to do any setup when changing hardware.

I would have thought that the development contract would stipulate the deliverables and obligations of the contractor to you.

At a minimum I would be requesting a walk through and documentation of how the configuration works and what’s vital to the point that you can recreate the project, build and deploy it yourself.

In terms of having something ready to go, I think the VM Is perfectly acceptable.

I would definitely be pushing for documentation though. I would be hesitant without it because unless you have a high level understanding of how it works you could be over a barrel in the future, particularly if you need to support the application yourself.

Even for internally developed embedded systems its important to have a document describing how to setup the build environment. You also need to archive all the binaries / install files of tools, and libraries needed to set up the build environment.

I would not accept VM as a code deliverable because it makes it hard to make updates. You have to have that VM as a golden image to do development work. That makes it harder to make mods. A developer has to reformat, or gets a new machine, they have to install a VM and pull the VM.

When you make edits, you have to commit a new “golden copy” of the VM. Why would you want to manage a big binary file like that in source control? It’s not possible to diff, and in my experience trying to source control a golden copy of anything binary doesn’t end well. Unless you can maintain strict control over who edits the golden copy, you will end up with stuff in there that is undocumented and no one knows about.

If a developer wanted to deliver software to me in that form, I’d find a different developer. This tells me they aren’t professional enough to script out their dependencies, or at the very least document them.

I’d have them either:

Create a text file that gets checked into source control with the code. It lists all dependencies that you need to get the project up and running, that aren’t part of the source control repo (e.g., CodeWarrior, whatever command line tools, or other external apps you depend on).
A script to install the dependencies. Since you are on Windows, it shouldn’t be too hard to create a Chocolatey script to automate the setup of the dev environment. Any dependencies you have that aren’t already chocolatey packages, you can make. For example, you can install heavy commercial tools like Visual Studio and SQL Server via Chocolatey. Those packages install the trial versions, which are full featured, and can be unlocked by entering a license key. So it’s possible the same thing can be done with CodeWarrior, and any other dependencies you have for your dev environment.

Maybe your developer is really good enough that you still want to work with him/her, but isn’t good at this automation stuff. That’s fine too, if that were the case, I’d either do the automation part myself, working with him/her to identify the dependencies and get the script working, or I’d get another developer who’s good at the automation to do it. It should be done at the start of the project. A clean, barebones copy of a Win8 VM would still be useful because you can use it to test out your chocolatey script.

I don’t think there’s a problem with this, I’ve seen content management systems that install as VMs, and from what you say the contractors have given you the ability to maintain and extend the application yourselves.

However, as other posters have noted there are two things I would to do. First, make sure that when installing the VM, put it on a machine that’s separate from your network. You wouldn’t download an unknown EXE from the internet and install it on your machine.

Second, if possible keep this isolated copy as reference for setting the in-house version. I say if possible because I don’t know the business pressures you are under. Ultimately, it’ll be your firm’s IT department / programmers that’ll be responsible for this application. So, the more you know about it the better.

Filed under: softwareengineering - @ 15:34

Thẻ: delivery, release, virtual-machine

Thiết kế website giá rẻ

Danh mục

Are there any reasons not to accept a software deliverable as a virtual machine?