The Marketplace has been placed into maintenance mode. It is no longer under active development. You can read complete details here.

Development Virtual Machine (Draft)

To help lower the barrier to contributions across marketplace and ease the friction of development day to day. We would like to build a vm that contains a virtual machine that can represent all the services that make-up marketplace.

This vm should allow a new developer to get set-up within a very short space of time.

Requirements

Here's a list of requirements (feel free to add to it)

Easy to make changes

It must be easy and obvious to a new developer where changes should be made. For example we should be consistent where project files live. E.g. all projects working trees should be available at the same level. There shouldn't be any source from one project buried in the tree of another.

Visibility of changes

Changes should be as close to immediately visible as possible. All projects should have service reloading on so that all changes are seen as quickly as possible (e.g. template changes / CSS / JS changes etc)

Zero config

Zero application configuration for the developer - as we've decided ports + paths up front there should be no config for the developer to change to see things up and running.

Easy to update

Being able to pull new changes, get dependency updates, run migrations etc should be very easy. The way to do this should be exposed with a common CLI across every project.

For bonus points (only update to revs which have passed tests)

Work offline and not care about host network changes

Aside from updating, the env should work happily offline. This includes thinking about networking e.g. if I'm using the env in an office and I disconnect from that network there and work somewhere else this shouldn't impact the vm's network. (In other words we should avoid bridged networking and use host-only)

Easy to configure user preferences

There should be a documented way to configure a user preferences e.g. preferred editor / bash profiles etc. We might decide that a pre-defined user is the way to use the env in which case making an allowance for user-overrides to sane defaults should be possible. Assuming this was preferred over allowing the user to create their own user.

Ensuring this doesn't get blown away when re-provisioning would be important.

Balance provisioned downloads vs what's in the box file

We need to balance the amount of downloads the provisioning step does vs the size of the box file. We might for example prefer to have all the deps already installed so that the provisioning step is much quicker. But at all times it must be possible for the provisioning code to work from bare metal.

Keeping the boxfile updated with the installed deps should also be a consideration.

Provide a web-based dashboard [Stretch]

Providing a web-based dashboard that shows the revs of each project. Migration status, deps status etc could be really useful. It could also be an interface for updates too?

Tested [Stretch]

Having jenkins run test updates on a vm on changes and check services still run would be useful. E.g. to avoid a case where a new migration causes a problem in the current dev-env.

Build in error reporting to update CLI/API [Stretch]

If a project update dies having some way to easily send feedback to us would be useful.

Specification

Here we should list a detailed of what decisions are made in order to meet the requirements. E.g. paths/networking etc.