* 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=
* https://www.mediawiki.org/wiki/Developer_Satisfaction - Optional if you want to delve deeper into fundamental issues. Relevant problems will be presented briefly before discussion of this topic.
=Notes and Facilitation guidance=
=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.
* 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
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
* Ensure the dev env is in sync with the prod env
* With vagrant there are no real tests or guarantees
* Group 3
* 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
* Easily use features that are in development
* 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
* Test locally part of the new service infrastructure before I test in prod
* 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