The hosting provider for the blog is providing a production site and a staging site, but we really should have a development/testing site to use to iterate on changes before we push them up the vendor provided "push to deploy" git repository on GitHub.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | bd808 | T246506 Investigate a development/testing environment for #techblog | |||
| Resolved | bd808 | T246708 Request creation of "techblog" VPS project |
Event Timeline
Comment Actions
Look at what was done to create https://tools.wmflabs.org/wptestblog/ and see if that can be repeated easily.
Comment Actions
I worked on this yesterday and ended up creating https://github.com/bd808/vvv-wmf-techblog-site-template to make it relatively easy to create a local development environment using https://github.com/Varying-Vagrant-Vagrants/VVV which is functionally the WordPress version of MediaWiki-Vagrant.
I also created T246708: Request creation of "techblog" VPS project to request a Cloud-VPS project where we can setup a full WP deployment for user acceptance testing.
Comment Actions
Now that T246708: Request creation of "techblog" VPS project is done I will start building a deployment there that @srodlund and others can use to iterate on basic WordPress setup and give feedback about additional plugins and code level config that is needed.
Comment Actions
Mentioned in SAL (#wikimedia-cloud) [2020-03-05T01:12:19Z] <bd808> Building techblog-wp-01.techblog.eqiad.wmflabs (T246506)
Comment Actions
Dropping priority not because this is not important in the long term, but because it is less important right now relative to other work for this goal.
Comment Actions
For what it is worth, our VIP setup has a built-in development environment for each site and a preproduction environment upon request (allowing for three instances - two in addition to production). Each instance is a different branch within the same private GitHub repository.
Comment Actions
Out of curiosity, what do you see as the advantages for having duplicate testing environments?
Comment Actions
Mostly faster code-test cycles and the ability to experiment without stepping on the toes of any other developers. It would also make working with community members on code changes easier if we can get to the point of attracting folks to help us.
Comment Actions
Gotcha. Who are the other developers we are trying to avoid stepping on the toes of? Also, how do you see the workflow working with the other blogs which will be sharing the blog's theme? My understanding is that Diff will be the blog housing active any development for the shared theme (which already has its own separate development instance) - or are you envisioning a separately developed fork of that theme's codebase?
Comment Actions
The point was (and is) that I do not know who may contribute to the code base. That's one of the advantages and challenges of an open source project.
Also, how do you see the workflow working with the other blogs which will be sharing the blog's theme? My understanding is that Diff will be the blog housing active any development for the shared theme (which already has its own separate development instance) - or are you envisioning a separately developed fork of that theme's codebase?
That is all based on information that did not exist at all at the time this bug was written. And honestly I have had zero communication from anyone about how the shared theme project might work in practice. If you are telling me that somebody else is going to become the responsible party for techblog's PHP code base, that sounds great but also new information. Is there a wiki page or Phabricator project or git repo where I can follow the development of the shared theme?
Comment Actions
I think the list of contributors is available on the GitHub page, but we control who has commit access and right now I think it is only Foundation staff for the Tech Blog (in addition to VIP - but they do not do development work - they do code and security review on our development work).
Also, how do you see the workflow working with the other blogs which will be sharing the blog's theme? My understanding is that Diff will be the blog housing active any development for the shared theme (which already has its own separate development instance) - or are you envisioning a separately developed fork of that theme's codebase?
That is all based on information that did not exist at all at the time this bug was written. And honestly I have had zero communication from anyone about how the shared theme project might work in practice. If you are telling me that somebody else is going to become the responsible party for techblog's PHP code base, that sounds great but also new information. Is there a wiki page or Phabricator project or git repo where I can follow the development of the shared theme?
I was not in the conversations, so do not have the specifics. This is what was reported back to me from discussions before the launch of Tech Blog between Brand Studio and Sarah about the theme design becoming aligned with other Foundation sites. I would check with Sarah or Hang in Brand Studio - but the shared theme is the one developed for the community blog which was just launched: https://meta.wikimedia.org/wiki/Diff_(blog)
One advantage to using VIP's existing setup is that they have a very customized security and SRE setup for their sites, so we have had the experience of something working on a private setup but not working exactly the same on VIP's setup. They do provide info on how to mimic their setup, but it seems something is always missed. Having tried to mimic Wikimedia's MediaWiki setup on other servers, I can empathize with how this sounds easier than it actually becomes in execution. I certainly have NO problems with more development environments being setup, but have seen how challenging it can be and would just hate to see folks invest a lot of time into something that may not work as expected, will require a fair amount of long-term maintenance (whereas VIP does that maintenance work for us on instances hosted with them), and might be duplicating something we are already paying for.