Page MenuHomePhabricator

Wikimedia Technical Conference 2019 Session: Local development environment - complex multi-service Mediawiki development
Closed, ResolvedPublic



  • Track: Local Development and onboarding
  • Topic: Local development environment - complex multi-service Mediawiki development


Is it feasible to try to create and maintain an environment on developers' computers for complex multi-service MediaWiki development? What options do we have and how can they be improved?

Questions to answer and discuss

Question: What are the use cases/personas that require a tailored development environment?
Significance: Creating a one size fits all environments is unrealistic, so if we know the different use cases we can work out how to provide a good development environment for different groups.

Question: What are the needs for each use case?

Related Issues

  • T234632 - Wikimedia Technical Conference 2019 Session: Local development environment - MediaWiki core
  • ...

Pre-reading for all Participants

Notes document(s)

Notes and Facilitation guidance

Session Leader(s)

Session Scribes

  • Will

Session Facilitator

  • Aubrey

Session Style / Format

  • [what type of format will this session be?]

Session Leaders please:

  • Add more details to this task description.
  • Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc).
  • Outline the plan for discussing this topic at the event.
  • Optionally, include what this session will not try to solve.
  • Update this task with summaries of any pre-event discussions.
  • Include ways for people not attending to be involved in discussions before the event and afterwards.

Post-event summary:

  • Dockerize lots of stuff
  • Defined a set of personas for complex environment
  • No one size fits all solution
  • Focus instead on providing common tooling

Wikimedia Technical Conference
Atlanta, GA USA
November 12 - 15, 2019

Session Name / Topic
LocalDev: complex multi-service MediaWiki development
Session Leader: Jeena; Facilitator: Aubrey; Scribe: Will

Session Attendees
Niklas, Addshore, Tpt, Lars, Stephen, James, bd808, Alex, Guiseppe, JR, Timo, Tyler, Zeljko, tgr, Cormac, Fisch, Petr, Daniel Z., …


  • Multi-service envs may not fit a one sizes fits all model
  • Individual teams have individual needs and laptops may not have the capacity to run all services together
  • Interested in:
    • Cloud resources available
      • Not necessarily that you have to have really good bandwidth but if you do the ability to spin up resources in the cloud
      • shared database, services that you don't want to configure but only access
      • Also want to be able to say here is a patch set and here is a running version of it - when it's not possible to have all pieces running in a local env
  • Break out Session 1
    • Generate post it notes capturing usecases or personas that would need a tailored development environment
      • Group 1 General Themes
        • Defining tailored
        • The need to test services in production
        • Interdependency of services, chained dependencies needed even if you're not working on those specific upstream services
        • Production like env that new services can be pushed to take it down to determine how they will be bring prod down
        • Need a reasonable opportunity to catch large clear issues that would hit production in advance
        • Production levels of data and traffic can't be a requirement but it is a concern
        • Testing against different configuration
        • Q: Is dev env the same as test env?
        • A: Yes, kind of
      • Group 2 General Themes
        • User testing/UX changes
        • SRE easily ensure the dev env is in sync with prod, and make sure it's updated, who is responsible
        • Being able to have replications in dev env to reproduce production bugs
        • Different levels of complexity, from basic through to full replication of prod
        • In order to test clustered services, they need to be preconfigured
        • Roles within vagrant can break each other
      • Group 3
        • As a dev I want to click a button to live test a patch
        • as a dev I want to be able to efficiently iterate on my work
        • Ability to use different host platforms
        • Share and deploy configs for and across teams
        • Easy to mix and match prod and non-prod elements
    • Breakout Share back
      • Group 2
        • Persona: Developer
          • No annoying set up of things
          • Easy to transfer ownership
          • Easier to switch between differnet environments
            • Lower context switching cost
          • Roles that can be configured
          • Multi-wiki set up should be easier
          • More independent from your laptop, could conceivably use a cloud device
          • Content within the environment, loading content packages to test
          • Closer to production, so easier to test and reproduce
          • DB replica could be easier to test
        • Role: UX
          • User testing, can send out a WIP and ask for feedback
          • Designers: can view patches and verify changes
          • Sharing across and within teams of WIP
        • SRE
          • Ensure the dev env is in sync with the prod env
          • With vagrant there are no real tests or guarantees
      • Group 3
        • Developer
          • Efficiently iterate on my work, can see impacts of changes immediately
          • Dependencies that I'm not deving should just work
          • Want to easily mix prod and dev env
            • Prod like but I want to use xdebug or npm
          • Want to be able to easily test prod data
          • Use different host platforms
            • Not just osx or linux
          • Easily reproduce bugs in local env
          • Want to be able to easily switch out pieces
        • Non-dev
          • Easily use features that are in development
        • Reviewer
          • I'd like to just click a button to test out the patch live
        • As a team mate I want to be able to share what I'm working on with others
      • Group 1
        • Service owner/QA
          • Want to test with a MW like stack
        • SRE
          • Test locally part of the new service infrastructure before I test in prod
        • Bryan
          • Stryker, needs a huge number of pieces
        • Release Engineering
          • On release scripts, I want a standalone clone of gerrit
          • New extension, how does it take prod down and can I see that before
          • As I'm writing helm charts I want to test locally
        • Dev on single extension
          • May be I don't need anything
  • Break out Session 2
    • For your group's persona, what is needed for a complete dev environment?
      • How production-like should it be?
      • What is the right balance of push button vs manual setup?
      • ...any other ideas you have
    • Breakout Share back
      • Group 1 - SRE
        • How prod like: very
        • Push button is better but modification has to happen somewhere, need sensible defaults but configurable
        • Same software and versions as prod but ability to change
        • Same deploymenet tooling as production
        • BUT: Impossible to have one for SRE? Too complicated?
          • Small but disposable use vagrant
        • MW mem consumption means testing locally is impossible
        • For testing puppet locally this would be useful when testing config changes
      • Group 2 – Developer
        • Split into 3:
          • What is your main focus/main work env? Stable, reproducible, shareable with team mates
          • Special case env - simple to set up and fast to get started on work
          • Complex dev env - extension dev of complex extensions that need multi-wiki
      • Group 3 – ???
  • Bryan: IME I believe every proper team needs to have a devops/automation person as part of the team -- I can't fathom that we're ever going to come up with one thing that works for every team -- a lot of these discussions seem to be wishing for magical ways to bring them things they want
  • _joe_: mostly agree w/Bryan, but I think there is a point to having a common base and trying to evolve it. A standard base from which a team can evolve is important.
  • brennen: what is the tooling or framework that we can provide that allows evolution to happen. Obviously we can't solve everyone's problems.
  • Alex: a way to build dev enviornoments -- meta meta meta
  • Adam: in terms of the MW docker dev thing I made, one way that becomes more powerful is if all components have their own docker images. It becomes easier to plugin things. This comes back to sensible defaults. There needs to be better sensible defaults. Even if it's not deployed in prod with the docker image
  • _joe_: eventually we will need to use the same set of images or similar
  • Timo: I want to echo what Bryan said, while highly configed env is ideal, for your own team you need something that covers all your needs but draws a boundary - for example - not adding pieces simply because they exist, like kafka. QA and PMs on the other hand do need broader envs. On that I haven't given up on a magical solutioSn, something more like a beta cluster. Doesn't work offline but I think that's ok
  • Stephen: To tie this back to a concrete usecase, if you have a skin that does not have a lot of additional dependency, it would be good to improve reviewer productivity by providing the ability to run patches to verify
  • Ricardo: Keeping the env in sync with prod is important to support testing.
    • Having something in gerrit that you can click -- that's a long time to keep resources
    • Anyone can send a patch -- which makes this a security issue

Event Timeline

See the comment in T234632#5571246 - I think this makes a lot more sense without the word "development".

The existing options are MediaWiki-Vagrant and Meza, I think?

See the comment in T234632#5571246 - I think this makes a lot more sense without the word "development".

The existing options are MediaWiki-Vagrant and Meza, I think? also has the ability to provide a "complex" environment with whatever services you want, just not much effort has been put in there yet due to wanting to see the outcomes of the k8s based development environment that has been developed over the past year.

The main issues I see with this area as a whole however is that it either needs dedicated development time to maintain the environment or buy in and maintenance by all of the teams involved that are expected to have services run in the environment.

Yeah, docker / local-charts can also handle services, as long as it's a single predefined configuration of what those services are. Vagrant and meza are fairly flexible about what services to add.

josephine_l updated the task description. (Show Details)
josephine_l added a subscriber: jeena.
debt triaged this task as Medium priority.Oct 22 2019, 6:55 PM

(Programming note)

This session was accepted and will be scheduled.

Notes to the session leader

  • Please continue to scope this session and post the session's goals and main questions into the task description.
    • If your topic is too big for one session, work with your Program Committee contact to break it down even further.
    • Session descriptions need to be completely finalized by November 1, 2019.
  • Please build your session collaboratively!
    • You should consider breakout groups with report-backs, using posters / post-its to visualize thoughts and themes, or any other collaborative meeting method you like.
    • If you need to have any large group discussions they must be planned out, specific, and focused.
    • A brief summary of your session format will need to go in the associated Phabricator task.
    • Some ideas from the old WMF Team Practices Group.
  • If you have any pre-session suggested reading or any specific ideas that you would like your attendees to think about in advance of your session, please state that explicitly in your session’s task.
    • Please put this at the top of your Phabricator task under the label “Pre-reading for all Participants.”

Notes to those interested in attending this session

(or those wanting to engage before the event because they are not attending)

  • If the session leader is asking for feedback, please engage!
  • Please do any pre-session reading that the leader would like you to do.

Sticky's from session:

T238261-1.JPG (4×3 px, 851 KB)
(idea land)

T238261-2.JPG (4×3 px, 641 KB)

Thanks for making this a good session at TechConf this year. Follow-up actions are recorded in a central planning spreadsheet (owned by me) and I'll begin farming them out to responsible parties in January 2020.