Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Process: Difference between revisions

From MoodleDocs
(Adding pointer to developer status information.)
(Adding link to deprecation)
Line 180: Line 180:
==See also==
==See also==


* [[Deprecation]]
* [http://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11350 Integration dashboard]
* [http://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11350 Integration dashboard]



Revision as of 09:19, 13 September 2012

This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.

Here are some terms we'll use in this document:

  • STABLE = the next stable minor version (point release) of Moodle (eg 2.0.1, 2.0.2 ... etc)
  • STABLE backlog = the queue of bugs to be fixed in STABLE (eg 2.0.x)
  • DEV = the next major version of Moodle (eg 2.1, 2.2, 2.3 ... etc)
  • DEV backlog = everything to be looked at for upcoming major versions (eg 2.X)


Integration workflow in the tracker

The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

Workflow.jpg

A number of roles make this work:

Users

Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.

Developers

Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle. If you're interested in becoming a recognised developer, see Tracker groups and permissions.

Component leads

Component leads are developers with some responsibility for particular components (plugins or modules) in Moodle. They have the authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core, by adding their git branches to the integration queue. This can happen at any time.

Integrators

On Monday and Tuesday of each week, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

Testers

On Wednesday each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

Production maintainers

On Thursday each week, production maintainers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git, cvs, and download packages.

Stable maintenance cycles

Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.2.1, 2.2.2, 2.2.3 etc only include fixes based on the latest major release (2.2) and never any significant new features or database changes.

At Moodle HQ there is a team of developers using a SCRUM-based process to work on these releases.

Minor release (point release) timing

Between major releases there will be three minor releases.

  • x.x.1 will occur approximately one month after each major release (eg. 2.x).
  • There will then be another point release every two months after that.

See the General release calendar for details.

Triage team

Triagers evaluate new issues, making sure that they are labelled correctly. One of the most important jobs they do is to identify issues that should be fixed in the stable branch. These are added to the STABLE backlog with a priority ranging from "Trivial" up to "Blocker".

Other larger issues go into the DEV backlog for consideration as part of the next major release.

See Bug triage for more details.

Scrum team

Every three weeks, the Stable Scrum team takes a number of the most urgent issues from the STABLE backlog and starts working on solving them during a period known as a sprint. The team meets daily to discuss solutions and progress, as well as to organise testing and peer reviews of code. The team has a "Scrum master" to help everyone stay organised, to "unblock" any barriers to progress and to protect the team from distracting influences (mostly people attempting to add to the developers' workloads) during the sprint. The team's work is documented publicly in the tracker.

Whenever a solution for an issue is finished, it is submitted into to the standard integration workflow process described above.

Major release cycles

Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months: in June and December. See the General release calendar for more details.

Each release can be different, but generally the cycles work like this:

Define roadmap

The product owner (Martin Dougiamas) defines the likely roadmap based on community wishes, third-party developments and important issues within the existing code. The DEV backlog is also a factor.

Sometimes these might be based on earlier features, sometimes they may be evaluating something developed by a third party, sometimes it might be something completely new.

Development team

The DEV team (employed at Moodle HQ) work on major new features one or two at a time. The aim is always to try and finish things completely before moving on to the next features, as this helps to avoid delays in delivering a release on time.

All this code goes through the standard weekly integration workflow described above.

QA Team

Finally, in the last month before the release, a feature freeze is called (no new features can be added) and our QA team performs a full functional test of Moodle features (manually, one at a time) to make sure there are no regressions caused by new features.

The current list of functional tests is listed in the tracker in the MDLQA project. This list of tests is extended on every release to include new developments.

New feature development

Major new features in Moodle usually should go through the following process.

Specification

The developer should create a detailed spec (here in Moodle Docs) outlining their goals for the development and their design for meeting those goals. The more detail the better.

You should also create an issue in the tracker (linking to your docs) to keep track of the project status.

Community consultation

Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. The forums on moodle.org are good for this, but you could also blog/tweet about it etc.

You probably also want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.

Develop the code using git

Develop your code on an open git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

It is essential that your code follows the Moodle Coding Guide.

Submit your code for peer review

Use the workflow buttons in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on.

This would be a good time to fill in the testing instructions for how to verify your fix is correct. You may also wish to add a comment in the bug. (... or should you put that information in the commit comment?)

Component owner does the peer review

The component owner should peer-review the change. They will either give you comments about why the code needs more work, or they will ...

Ideally, peer reviews should check all items in the Peer reviewing checklist.

Submit the code for integration

This is much the same as for any Moodle code. See the information about the integration workflow above.

Fixing a bug

Bug fixes, and minor features or enhancements should go through the following process.

Make sure there is a tracker issue

Every change must have an issue in the tracker. If you are fixing a bug, there is probably one there already, but if not, create one.

Decide which branches the fix is required on

Bugs should normally be fixed on all the supported stable branches that are affected. New features should just go into master, but sometimes minor enhancements are made on the most recent stable branch.

Develop your change using git

Develop your fix and push the change to an open git repository, for example on github.com.

It is essential that your code follows the Moodle Coding Guide.

You will need to push one commit for each branch the fix needs to be applied to. Often people use branch names like wip_MDL-12345_2.1_brief_name so it is clear what each branch is. git cherry-pick can help with replicating the fix onto different branches.

Submit your code for peer review

Use the workflow buttons in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on.

This would be a good time to fill in the testing instructions for how to verify your fix is correct. You may also wish to add a comment in the bug. (... or should you put that information in the commit comment?)

Component owner does the peer review

The component owner should peer-review the change. They will either give you comments about why the code needs more work, or they will ...

Ideally, peer reviews should check all items in the Peer reviewing checklist.

Submit your code for integration

It will then be reviewed the following week by one of the integration team and either integrated or rejected. Once integrated, the fix will be tested, and then included in the next weekly release.

See also