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
(Fixing headings)
Line 1: Line 1:
This document summarises the development processes used in developing Moodle.
This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.
 
==Terms==


Here are some terms we'll use in this document:
Here are some terms we'll use in this document:
* STABLE = the next stable minor version of Moodle (eg 2.0.1, 2.0.2 ... etc) Note that database changes and new features are not allowed in STABLE
* STABLE = the next stable minor version 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)
* 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 = 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)
* DEV backlog = everything to be looked at for upcoming major versions (eg 2.X)


==Development Processes==
We have a number of different processes that operate at different levels.




===Integration workflow in the tracker===
==Integration workflow in the tracker==


The Moodle tracker keeps track of the status of all bug fixes and new features.  
The Moodle tracker keeps track of the status of all bug fixes and new features.  
Line 25: Line 19:
A number of roles make this work:
A number of roles make this work:


====Users====
===Users===


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


====Developers====
===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.
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.
Line 35: Line 29:
While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle.
While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle.


====Component leads====
===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.
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====
===Integrators===


On Monday 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.
On Monday 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.
Line 45: Line 39:
If they find problems they reject the issue and send it back to the developer for further work.
If they find problems they reject the issue and send it back to the developer for further work.


====Testers====
===Testers===


On Tuesday 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.
On Tuesday 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.
Line 51: Line 45:
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.
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.


====Committers====
===Committers===


On Wednesday each week, committers 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.
On Wednesday each week, committers 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===
 
 
==Stable maintenance cycles==


Moodle releases regular updates of the stable version of the software to fix bugs and other issues.  Releases like 2.0.1, 2.0.2, 2.0.3 etc only include fixes based on the latest major release (2.0) and never any significant new features or database changes.
Moodle releases regular updates of the stable version of the software to fix bugs and other issues.  Releases like 2.0.1, 2.0.2, 2.0.3 etc only include fixes based on the latest major release (2.0) and never any significant new features or database changes.
Line 62: Line 58:
At Moodle HQ there is a team of developers using a SCRUM-based process to work on these releases.  
At Moodle HQ there is a team of developers using a SCRUM-based process to work on these releases.  


====Triage team====
===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".
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".
Line 68: Line 64:
Other larger issues go into the DEV backlog for consideration as part of the next major release.
Other larger issues go into the DEV backlog for consideration as part of the next major release.


====Scrum team====
===Scrum team===


Every three weeks, the Stable Scrum team takes a number of the most urgent issues from the STABLE backlog  (approx 30, but it varies) and starts working on solving them.  The team meets daily to discuss solutions and progress, as well as conducting peer reviews of code.  The team has a "Scrum master" to help everyone stay organised and to "unblock" any barriers to progress.  Everything is documented publically in the tracker.
Every three weeks, the Stable Scrum team takes a number of the most urgent issues from the STABLE backlog  (approx 30, but it varies) and starts working on solving them.  The team meets daily to discuss solutions and progress, as well as conducting peer reviews of code.  The team has a "Scrum master" to help everyone stay organised and to "unblock" any barriers to progress.  Everything is documented publically in the tracker.
Line 75: Line 71:




===Major release cycles===
 
 
==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.
Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months: in June and December.
Line 81: Line 79:
Each release can be different, but generally the cycles work like this:
Each release can be different, but generally the cycles work like this:


====Define roadmap====
===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.
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.
Line 88: Line 86:




====Development team====
===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.
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.
All this code goes through the standard weekly integration workflow described above.


====QA Team====
===QA Team===


Finally, in the last weeks of the release, 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.  This list of features is extended on every release to include new developments.
Finally, in the last weeks of the release, 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.  This list of features is extended on every release to include new developments.


===Feature development===
 
 
 
==New feature development==


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


====Specification====
===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.
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.
Line 108: Line 109:
You should also create an issue in the tracker (linking to your docs) to keep track of the project status.
You should also create an issue in the tracker (linking to your docs) to keep track of the project status.


====Community consultation====
===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.
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 might also want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design and so on.
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 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.
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.


====Submit the code for integration====
It is essential that your code follows the [[Coding|Moodle Coding Guide]]
 
===Submit the code for integration===


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

Revision as of 05:28, 27 April 2011

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 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.

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 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 Tuesday 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.

Committers

On Wednesday each week, committers 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.0.1, 2.0.2, 2.0.3 etc only include fixes based on the latest major release (2.0) 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.

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.

Scrum team

Every three weeks, the Stable Scrum team takes a number of the most urgent issues from the STABLE backlog (approx 30, but it varies) and starts working on solving them. The team meets daily to discuss solutions and progress, as well as conducting peer reviews of code. The team has a "Scrum master" to help everyone stay organised and to "unblock" any barriers to progress. Everything is documented publically 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.

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 evauluating 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 weeks of the release, 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. This list of features 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 the code for integration

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