DevmoIdeas: Difference between revisions
Jump to navigation
Jump to search
(New page: = Ideas for a better devmo = * Work on using one copy of mediawiki instead of one per language * daily db backup pushes to a developer box (like khan) * Documents on production server layo...) |
(initial plans) |
||
Line 1: | Line 1: | ||
= Ideas for a better devmo = | == Ideas for a better devmo == | ||
* Work on using one copy of mediawiki instead of one per language | * Work on using one copy of mediawiki instead of one per language | ||
* daily db backup pushes to a developer box (like khan) | * daily db backup pushes to a developer box (like khan) | ||
Line 10: | Line 10: | ||
* Pull directly from mediawiki's svn repo and maintain or own repo with only patches | * Pull directly from mediawiki's svn repo and maintain or own repo with only patches | ||
* Something else? | * Something else? | ||
==Tentative plan== | |||
* IT will create a new development server, so that instead of just developer-stage.mozilla.org and developer.m.o, we will have: | |||
**developer-test.mozilla.org (development server; whatever name IT thinks makes sense of course) | |||
**developer-stage.mozilla.org (staging server) | |||
**developer.mozilla.org (production server) | |||
* developer-test will be the server on which development work is actually done by MDC contributors | |||
**should sync to MediaWiki trunk | |||
**provide access to logs | |||
**include a script that can be run at any time to replace the MediaWiki databases with the most recent backup from the production server | |||
* developer-stage will be used for wider-scale testing. | |||
**IT will pull this from developer-test when Evangelism requests it; Evangelism will provide an svn tag to use (or trunk if we've not gotten around to setting up tags yet, although that's a high-priority goal) | |||
**should replace its database with a copy of the production database nightly | |||
* developer will be the deployment server | |||
**IT will pull this from developer-stage after appropriate testing has been done | |||
Sheppy will make up a list of what changes we've made to MediaWiki core code and look into ways to either do without them or try to get them into extensions so we can move toward our goal of using pure MediaWiki code. |
Revision as of 18:44, 5 October 2007
Ideas for a better devmo
- Work on using one copy of mediawiki instead of one per language
- daily db backup pushes to a developer box (like khan)
- Documents on production server layout
- Import current script for updating devmo in to subversion
- Find a place for dev ops (set up a vm or use khan)
If we come to the conclusion that it is better for IT to take care of it like in the past then we need to figure out if we are:
- Going to merge in the mediawiki code
- Pull directly from mediawiki's svn repo and maintain or own repo with only patches
- Something else?
Tentative plan
- IT will create a new development server, so that instead of just developer-stage.mozilla.org and developer.m.o, we will have:
- developer-test.mozilla.org (development server; whatever name IT thinks makes sense of course)
- developer-stage.mozilla.org (staging server)
- developer.mozilla.org (production server)
- developer-test will be the server on which development work is actually done by MDC contributors
- should sync to MediaWiki trunk
- provide access to logs
- include a script that can be run at any time to replace the MediaWiki databases with the most recent backup from the production server
- developer-stage will be used for wider-scale testing.
- IT will pull this from developer-test when Evangelism requests it; Evangelism will provide an svn tag to use (or trunk if we've not gotten around to setting up tags yet, although that's a high-priority goal)
- should replace its database with a copy of the production database nightly
- developer will be the deployment server
- IT will pull this from developer-stage after appropriate testing has been done
Sheppy will make up a list of what changes we've made to MediaWiki core code and look into ways to either do without them or try to get them into extensions so we can move toward our goal of using pure MediaWiki code.