WordPress.org

Make WordPress Core

Opened 7 weeks ago

Last modified 3 days ago

#43711 new enhancement

Let's create a standard development setup for WordPress core.

Reported by: omarreiss Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: trunk
Component: Build/Test Tools Keywords:
Focuses: Cc:

Description

This ticket was triggered by previous discussion in https://core.trac.wordpress.org/ticket/43055 The current default for developing WordPress core seems to be VVV. While VVV is doing a great job in making it easier to run WordPress locally, I think we could do better, especially for WordPress core.

With this ticket I would like to set a goal for improvement and discuss ways to achieve it.

The goal: a simple, two-step process for setting up a WordPress core development environment

The simplest development setup workflow I can think of consists just of two simple steps:

Download and boot

That's how simple it should (eventually) be. WordPress should now be running on some local address and every developer should be able to dive in the code and make changes.

Integrating watch and build behavior

As we plan to introduce a build step to the development workflow, it becomes more important that building is not an afterthought but something that is integrated into the development workflow.

The desirable state is one in which we just boot and can trust all changes are processed to whatever's being served in the browser.

This unfortunately is not the case at the moment. If we want to do better, we need a more unified approach.

Requirements

We need something that is:

  • the easiest possible development workflow: just download and boot.
  • fast: reduce build and boot times to a minimum.
  • reliable: it should just work.

@pento noted that eventually he'd like this thing to be configurable and installable through a GUI in order to reduce the barrier of entry for new contributors to the absolute minimum.

Possible solutions

Docker install script

@pento built automated development environment setup scripts for Gutenberg based on Docker.

The Gutenberg setup script walks the user through setting up their development environment. It would obviously need to be written to work on Windows, too, before it was a valid option for Core. That will be fun. 🙂

There are a few benefits to using a Docker based environment.

  • It's fast
  • It's composable
  • It only requires Docker

Aside: If we get good and well maintained Docker images for WordPress, this could also benefit the web hosting community, will make WordPress more optimized for cloud native hosting infrastructures, could also help optimize WordPress unit testing in container based CI solutions like Travis etc.

VVV install script

@TJNowell noted similar advantages might also be achieved with VVV

I see no reason the docker call in the GB script couldn't be a git clone ... cd vvv.. vagrant up --provision

Of course VVV and the community behind it include a great deal of experience with regard to the intricacies of creating the development environment for WordPress.

If we can make it easy, fast and reliable enough, that might just be what we need!

Change History (12)

#1 @youknowriad
7 weeks ago

Thanks for opening this issue

Two things that I think are important to address as part of this:

  • Ideally, the integration and e2e tests (even unit tests since PHP unit tests require a full setup) should use the same environment
  • A dev environment even if it's hidden behind magical scripts should stay simple. When bugs happen developers of any level should be able to understand, debug and tweak how the environment works.

I admit having a preference for docker setups because it's light compared to a real Virtual Machine. I think the current docker setup is Gutenberg has grown to be slightly more complex to what I want it to be. (two many scripts calling each other), I believe we can achieve the same goals using a simple docker-compose file.

#2 @TJNowell
6 weeks ago

With note to VVV:

Currently VVV uses the NFS option to map folders, which is why grunt watch is slow/unreliable, but there are mechanisms for mitigating this. Such as reducing the caching time to 1ms, or disabling caching at all, or even using a completely different mechanism. These options were set in VVV a ​long time ago, and so the exact reasons it's set up that way may be lost to the sands of time ( depends how sleepy Jeremy was at the time )

But since the option of a setup script is present, we could setup node etc locally on the host bypassing any performance costs of mounted/shared folders in Vagrant/Docker

There are also other Vagrant options to be explored, such as changes to guard, or using watchr.

I also had an idea of how to mitigate the problem of all users having a grunt watch in the background even when they aren't doing work on core, make it an option turned off by default

Re: Docker

Outside linux, docker still runs inside a VM, so a docker container may have different performance, but it still has a performance cost. It appears that with caching eliminated, the tradeoff is speed

See here for more details:

​https://docs.docker.com/docker-for-mac/osxfs/#performance-issues-solutions-and-roadmap

This ticket was mentioned in ​Slack in #meta by netweb. ​View the logs.


2 weeks ago

#4 @Mte90
7 days ago

I am a huge fan of VVV, so I will try to be not from a side and be impartial.

One of the problems that has VVV right now is that require a lot of time on first start because of installation (and download of a lot of things) but the plan for version 3 (​https://github.com/Varying-Vagrant-Vagrants/VVV/issues/1469) with a box that contain everything and also the parallel for the provision will improve a lot this point.

The other problems that often at contributor day we have is Windows. Install virtualbox, vagrant, git on Windows is a big step because people do't know anything of them. Often the problems on VVV is because there are different versions of powershell on the system (don't ask me why) and Vagrant or Virtualbox works with issue based on the version of ps.

With docker we will have more problems on Windows because we need a virtual machine so (virtualbox and git will be required in any case) so the only advantage that we don't have anymore the easy vagrant to use but docker (that is not so entry level).

Sure, there is the VVV USB Generator that prepare all the executables for download (maybe also the latest image) but we need to think that at contributor day not everyone has an OS dev friendly for *nix stuff. We have already a lot of issues with vagrant I can image with Docker virtualized...

From the other side VVV has the cool part to be used also for not contribute and very easy with vagrant up/halt and db backup so usually people are interested in that then contribute.

So probably the better way is to start to work on VVV at least for the GUI side, so we can gather feedback because the technical problems are from both the side.

#5 @TJNowell
7 days ago

Don't forget that we'll need to instruct users on how to setup Hyper-V to get Docker working, and docker has a lot of the same file performance issues Vagrant has, since it runs in a VM on all platforms except Linux. Users may even have to upgrade to Windows 10 Professional. No amount of USB drives will save us from Netbooks and cheap Windows machine trying to perform large scale downloads over conference wifi via Microsoft update servers

VVV 3 should resolve the provisioning time, and there are options for improving file system performance, such as vagrant-bindfs, or changing cache timings

As an aside, I see some of the reasoning for docker is that travis doesn't provide PHP 5.2 and you can't run a VM in travis. Given that we power 30% of the web, has nobody thought to spend $2 a month and set up CI with GitLab/Jenkin/Circle CI/Teamcity etc and just have a dedicated build server? We set up a Jenkins server to build boxes for VVV 3, and VVV already supports running multiple versions of PHP side by side, so it's not a huge task by any stretch

#6 @netweb
7 days ago

Integrating watch and build behavior: As we plan to introduce a build step to the development workflow, it becomes more important that building is not an afterthought but something that is integrated into the development workflow.

  • WordPress will also soon begin moving away from Grunt to npm scripts and webpack, see #43731
  • WordPress' CLI commands and scripts will need to be compatible with Mac, Windows, and *nix operating systems

Here are a few of the wishlist requirements I see whilst wearing my "Build Tools Component Maintainer Hat"

  • Support multiple versions of MySQL and MariaDB for testing #30462 #42811
  • Support multiple versions of PHPUnit for testing (Legacy PHP versions required legacy PHPUnit versions) #43218
  • Support multiple versions of PHP for testing, Travis CI ended support of PHP 5.2 and PHP 5.3 in September 2017 and WordPress is only able to use Travis CI builds on Ubuntu 12.04 LTS servers that no longer receive updates #41292.

This last item here is the most important here, there are a not many options available to us apart from a using a custom Docker image with Travis CI, at the moment Gutenberg is using ​these scripts to manually install PHP 5.2 & 5.3 versions for Travis CI though they are quite fragile.

Also in #41292 @miyauchi created a Docker image supporting PHP 5.2 - 7.1 and PHPUnit, this now supports PHP 7.2 as can be seen in the GitHub repo ​here, it was a great first step into exploring the potential of a Docker solution for Travis CI.


  • Docker can be run on Mac, Windows, and *nix platforms
  • WordPress can have a purpose-built Travis CI environment
  • The same purpose-built Travis CI environment can be used locally
  • A standardised "base" WordPress development environment
  • Existing Docker solutions can use the images as their base images

#7 @TJNowell
7 days ago

Keep in mind that when using docker with Vagrant actually runs inside a Virtualbox VM. Under MacOS native docker uses an xhyve VM running Alpine Linux, and under Windows it's an Alpine Linux VM under a Hyper-V managed VM.

I'm mindful that in the future, we'll be told that docker containers are the only option, and that other methods will suffer from this. I'm also disappointed that Travis limitations are dictating local dev environment decisions. If docker is the solution there, then fine, but that's not the same issue as a standardised development environment.

Before we blindly charge down this route, I'd like to see a solution to making contributer day attendees pay for and download a Windows upgrade since Hyper V is required for Docker on Windows, and it requires Windows Enterprise/Professional. Docker is not as inclusive or available as it appears, and it's being touted as a way to make contributing for new users easier, which isn't necessarily true.

Any solution would require a provisioning script to set up the database user and the relevant files, as well as perform checks that relevant tools are installed. This would seem to be a more portable approach that needs to be taken anyway regardless of what devops gets done.

#8 @pento
6 days ago

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.

#9 @TJNowell
6 days ago

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

#10 @nbachiyski
5 days ago

If our end goal is to make it really easy, the same way WordPress made website create easy 😜 we should aim higher – installing docker/vvv/waiting for any installation/setup seems both slow and error-prone (I’ve been to my fair share of contributor days). Two, closely related ideas:

  • ​https://janitor.technology/ – a project build by Mozilla to easy open-source project contributions. Everything is a click away, mostly aimed at desktop software (VNC), but might simplify web projects, too.

This might require some more research and maybe even infrastructure on our side, but will save hundreds of hours and will probably have immense long-term effects 🚀

#11 @Mte90
5 days ago

I agree about Janitor, infact I tried to make a docker solution for that: ​https://github.com/Mte90/wordpress-janitor I know the developer/creator of the project so he helped me but I have no time to work on that but as I can remember my image was complete (based on VVV).

#12 @pento
3 days ago

@nbachiyski: I'm absolutely in favour of supporting web-based development environments, as well as investigating their use for new contributors. They're a long way from being full solutions, however, for a few reasons:

  • They require a continuous, reasonably stable internet connection.
  • Adding config for popular editors is a good idea. Mandating the editor is not.
  • Storing GitHub/SVN/whatever credentials in the cloud is... less than ideal. 🙃 Requiring re-authentication for every commit is a terrible UX.

There are other services that are more focussed on providing the shared development stack (eg, ​Koding), but they have their own set of issues.

So as to not get too far ahead of ourselves, the focus of this ticket is to create a development environment that:

  • Fits existing uses. Primarily, core development, Gutenberg development (as a model for future core development), and can be easily setup at contributor days.
  • Is built with future uses in mind. Either container or full VM configurations can be relatively easily translated to online development environments, or to testing environments like calypso.live.
Note: See TracTickets for help on using tickets.