Wikimedia Labs/Development Process

Tools

 * create-wiki -b  [-c ] [-d ] [-p ] [-s ]
 * -b,--branch Branch to create (Required; Default: none)
 * -c,--config Which pre-made configuration to use (Default: based on --data)
 * -d,--data Wiki data to load (ie: enwiki, enwikinews, dewiki, jawiktionary) (Default: defaultwiki)
 * -p,--project Labs project that will be given access on this branch (Default: testproject)
 * -s,--source Source branch (Default: trunk)


 * create-sub-wiki -s 
 * -s,--source Source branch

create-wiki is a tool for creating a shared or solo working environment. Assuming git, create-wiki will do the following:


 * 1) Create a branch in Gerrit, based on a source branch
 * 2) Create a DNS name for the branch
 * 3) Create a wiki, with the specified data and/or configuration
 * 4) Give review and merge access to the specified Labs project
 * 5) Give filesystem access to the specified Labs project
 * 6) Give database access to the specified Labs project
 * 7) Add an Apache configuration file to /etc/apache2/sites-(available|enabled) and reload Apache

create-sub-wiki is a tool for creating a wiki to test changes that will be merged into a shared working environment. create-sub-wiki will do the following:


 * 1) Create a local git repo, clones from the source branch, in a solo space
 * 2) Create a wiki, pointing at that local repo
 * 3) Add Apache configuration for this specific wiki, requiring Apache authentication limited to your user, and will reload Apache

Process

 * 1) Developer will create a wiki using create-wiki
 * 2) Optionally, developers will run create-sub-wiki, if the branch is meant to be shared between a number of developers
 * 3) Solo developers can work directly in the created wiki
 * 4) Developer(s) will push for review to the branch (via git push-for-review)
 * 5) Branch code-reviewers will review the change, and merge
 * 6) Branch code-reviewers will merge their branch with the upstream branch, and will push for review to the upstream branch
 * 7) Upstream branch code-reviewers will review the change, and merge

Wikis that have not had activity in 30 days or more will be disabled in the Apache configuration. Wikis can be reactivated by resuming activity. Wikis can avoid this by being added to an exceptions list.

Automated testing
When a review request is made (via git push):


 * A pre-receive hook will run lint tests
 * A post-recieve hook will create a new wiki, run a full suite of tests, update the request comments with the test results, and mark the request valid or fails

When a change is merged to the branch:


 * A post-merge will do a git-pull on the branch's wiki, will run update.php, then will run a full suite of tests
 * The test results will be added to the request's code review comments, and will mark the request valid or fails