[wp-trac] [WordPress Trac] #43711: Let's create a standard development setup for WordPress core.

[WordPress Trac]

#43711: Let's create a standard development setup for WordPress core.
------------------------------+------------------------------
 Reporter:  omarreiss         |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Build/Test Tools  |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:                    |     Focuses:
------------------------------+------------------------------

Comment (by pento):

 Thank you for your thoughts, @TJNowell. I wasn't aware of Docker's
 requirement for either Hyper V or Virtualbox when run on Windows, which
 certain changes the ease of use for a large portion of contributors.

 One of the most valuable things that Docker has done is to popularise the
 "container" concept: small, disposable, task-oriented VMs that are
 designed to spin up quickly, perform a single task well, and can be
 cheaply reset. This encourages tasks to be performed in the environment
 they most make sense: if something needs disk performance (eg,
 `watch`-type tasks), it can be run on the host. If something requires
 specialised software or configuration (eg, a MySQL database), it can be
 run inside of a container.

 This directly benefits the contributor experience: isolating the magic to
 little boxes that can't be easily broken (and can be easily reset in the
 event they are) reduces the cost of experimenting, knowing that you have a
 fast and reliable reset mechanism to fall back on. Drawing from my
 personal experience, VVV has the opposite experience: provisioning is a
 slow process, which discourages resetting, which makes experimenting a
 risky proposition.

 Thinking about a feature set I would want to see in the "VM" part of this
 project, it'd probably look something like this:

 - Lightweight. Download size should be small, startup time should be fast.
 - Disposable. Upgrades shouldn't run internally in the VM, downloading a
 fresh copy should be a good experience, encouraging people to take risks,
 knowing that they have a simple safety net.
 - Centrally manageable. We should be able to upgrade the VM images and
 make them available to download. As a contributor, I generally don't care
 what specific version of PHP is being used, just that it works.
 Ultimately, our contributor tool should be able to download and install
 updates in the background, preferably without the contributor even needing
 to be prompted.
 - Swappable components. Occasionally, I do care about the version of PHP:
 if I could easily click a button to switch to PHP 5.2 to test something, I
 would be a very happy contributor. I don't want to have to spend forever
 hacking PHP 5.2 support into a modern Ubuntu image: it should just work.

 @TJNowell: As our resident VVV expert, do you think that this is
 achievable with the Vagrant/Virtualbox stack? You mentioned that VVV3
 should solve the provisioning time, do you have an idea of how fast
 provisioning would be? Instant? Seconds? Minutes?

 VVV has a reputation for being fairly fragile, it's easy to break your
 development environment, and hard to fix it. Can we address this
 perception by making it more robust, and easier to reset?

 It bears repeating that I have no attachment to any particular technology
 or service, when it comes to solving this problem. To take the Travis
 example, Travis is a service that was easy to get up and running, and it's
 served us well for years. But, should we find ourselves better served by a
 solution that requires switching to a different CI service (or even self
 hosting!), we can absolutely do that.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43711#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform