[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 TJNowell):

 We already prebuild the box for contributor days, the script generates:

  - a box with an already installed Ubuntu running Nginx/MariaDB etc so
 that no package installation happens on contributor day wifi
  - A copy of a preprovisioned VVV folder so that it doesn't download WP
  - A folder with all the installers needed for Windows and Mac users

 The only thing contributor day USB drives need to do on provision is setup
 the DB, which happens automatically on the first `vagrant up`. For an end
 user, it's:

  - run the installers
  - copy and extract vvv.zip
  - open the new folder in a command prompt and type `vagrant up`
  - wait for it to finish

 Most of the issue and time spent is telling users how to work it, they're
 unfamiliar with local dev environments, and might have strange issues. For
 example one users I helped had turned off scrollbars because she didn't
 like how they looked, and a user at a local user group had not set up
 trackpad drivers and couldn't right click or 2 finger scroll.

 VVV 3 goes one step further. We're planning to provision a prebuilt box on
 a CI server so that the only thing that happens on the users computer is
 setting up the sites. No package installation or configuring, just a box
 download, and updates arriving by pulling in new boxes. This also
 eliminates the need for the vagrant-vbguest plugin, and allows the
 provisioning scripts to be dramatically cut down in size.

 VVV 2.2.1 which is released either today or tomorrow also brings Vagrant
 2.1 support, which removes the need for the vagrant triggers plugin.
 Bundling Vagrant hosts updater is also being considered, which


     Lightweight. Download size should be small, startup time should be
 fast.

 VVV 3 should provision faster than 2, the main determiner of time at the
 moment is conference wifi stability and the ability of users to follow
 instructions. Efforts to reduce the first issue, and eliminate the second
 are in progress  ( e.g. an electron based installer that verifies you have
 the stuff needed installed, then does all the vagrant commands for you
 with a progress bar https://github.com/tomjn/vvv-cd-installer )

   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.

 Technically VVV 2 already has this, we backup the DB on halt/destroy, and
 restore the DB if it's lost, so a `vagrant destroy && vagrant up
 --provision` will recreate the VM fresh

   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.

 VVV 3 accomplishes this, security updates, guest additions, are applied on
 the CI server. If they fail for whatever reason then an update isn't
 pushed so no end users are impacted.

   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.

 VVV lets you swap out PHP versions and install additional versions at the
 moment. We use the Ondrej packages, but adding in PHP 5.2 would be easy,
 utilities are literally a bash script in a folder that gets run on
 provisioning so you can install software that isn't a website.

 https://varyingvagrantvagrants.org/docs/en-US/adding-a-new-site/changing-
 php-version/

   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?

 We made a lot of changes when VVV 2 came out that improved on this front,
 reducing the support burden of VVV has been a top goal, as well as lots of
 other things planned. VVV 3 means large swathes of the provisioning will
 happen elsewhere, and updates to Vagrant itself have eliminated some
 issues that were endemic several years ago.

 For that reason VVV 2.2 requires Vagrant 2.1, which also ensures a more
 modern version of VirtualBox. Most issues these days are fixed by
 upgrading Vagrant and VirtualBox. The longer term hope is to have a point
 and click UI

 ----

 As a side note, something the VVV project lacks is feedback. We made a lot
 of changes to try and improve things, such as putting a colourful splash
 logo with the version number and branch and links when you try to
 provision, or a dashboard that lists all the users, with a search box and
 tips/hints, or the rewrite of the docs, and sometimes we get helpful
 comments on those, mostly that the colours are pretty and welcoming

 But on some fronts, there's very little feedback at all. E.g. Lorelei
 built a `custom-site-template-develop` site template, making WP core dev
 provisioning more robust, adding in features, and allowing you to have
 multiple dev sites installed rather than the single site the old template
 allowed. But we've have almost no feedback of any kind for it, and that
 makes it difficult to know what blips need to go on the radar. Coupled
 with backwards compatibility, it's not an easy task. My fear is people who
 are afraid to update and run multiple versions side by side, and so
 there's been an emphasis on reducing maintenance cost and making
 everything friendlier and easier

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