Difference between revisions of "Software Development Procedure"

Revision as of 04:40, 15 November 2010

STATUS: This concept is under work.

This is a suggestion to replace the PMC Head Concept (http://www.adempiere.com/index.php/PMC_Head_Concept).

Goals

This document is about establishing processes, rules and teams to achieve the following:

• produce high quality ERP software
• regular and plannable releases
• an all the time stable trunk
• clear rules how to get code into trunk
• have several complex features under development at the same time
• documentation for all new features
• teams are to be responsible not single persons
• lean project organisation

Software Production Cycle

Development Phase (3 Months)

• A stabilization branch is created from trunk which is the main line of development.
• new functionalities are implemented in seperate development branches with the aim to get them into stabilization branch
  • Developers have 3 months time for integrating new functionalities, changes, Bug fixing and Integration testing in their branch
  • Before integrating new/ changed Funtionality in "stabilization" the Developers/ Implementors have to apply for approval by Technical and Functional Team

Stabilization Phase (1 month)

• After development phase is over there is 1 month stabilization phase where the stabilization branch is frozen for new features. In this time only Bugfixing and User Acceptance Tests (UAT) are allowed.

Release

• stabilzation branch is reintegrated into main line of development and a release is done (svn tag).
• The next stabilization branch cycle starts. The old branch is deleted. The new one is again created from main line of development trunk.

Developer working in Development Branch

Responsibilities

• code has 100% compliance with Adempiere Best Practices (ABP)
• code is formated using the official formatting definition (need to be defined and agreed on, but in meantime you can take this as an example)
• respect Subversion Best Practices (see [1])
• Anounce any data model change in order to discuss and vote it in technical and/or functional team (example: the placed were we store some well known informations like contact phone changed)
• Anounce structural changes (e.g. file, directory, rename, move, delete) should be announced and approved by Technical team before applying it
• keep Master Data Models (organizations, bpartners, contacts, warehouses etc) consistent and do not use different ways of defining the relations between this entities (examples: storing the organization details like addresses, phones, faxes in Organization Info tab or in the linked business partner)
• in case of complex functionalities, define ADempiere Generic Workflows in order to guide the user how to setup the functionality and which is the designed the business process (example: take a look at Manufacturing Management Setup workflow from your ADempiere main menu)
• provide necessary documentation:
  • forum post anouncing the development in forum
  • wiki page (template and content to be defined)
  • feature request in tracker
  • entry in feature development collaboration wiki page
• keep his branch up-to-date with stabilization branch and therefore must merge hotfixes into his branch.
• provide immediate effort if the integration harms the "stabilization" branch.
• delete "Dead" or "unmaintained" branches that he has created in the past

Process

• Every Developer can open an own experimental or feature development branch. The branch can be taken from trunk or "stabilization". The developer who opened the branch is the maintainer of the branch.
• The Maintainer can prepare the reintegration of his branch into "stabilization" branch by informing Release Manager, Technical and Functional teams. This shall be done as early as possible, so that Release Manager can oversee the complexity of new Implementations and can give early consultancy about when to integrate.
• Once the maintainer gets the approval of Technical and functional team he can merge his branch into stabilization branch
• after integration into "stabilization" Integration testing is performed

Technical Team

Responsibilities

• ensures that all contributions meet technical requirements in respect to quality
  • code is documented
  • backward compatibility is achieved
  • migration scripts complete
  • technical documentation sufficient
  • backward comparability analysis
  • migration scripts are provided (when needed)
• provides a release manager from amongst their members

Process

• When a feature in a development branch is ready for approval the developer contacts the technical team and applies for approval
• Technical Team meets on a regular basis and discusses the applications
• If all criteria are met the team approves the feature from a technical perspective and allows the developer to merge his feature into stabilization branch

Initial Staff

• Teo Sarca
• Karsten Thiemann
• Tobias Schöneberg
• Victor Perez (Libero MFG and HR)
• <please contact the team to become member>

Release Manager

Responsibilities

• organize contributions to keep release schedule

Process

• creates stabilization from trunk when new development cycle begins
• produces a release from stabilization branch after stabilization phase

Functional team

Responsibilities

• ensures that all contributions meet functional requirements in respect to quality
  • requirement makes sense
  • feature is needed in trunk or to be kept as optional extension
  • requirement is solved
  • acceptance criteria are defined
  • test cases are complete
  • user documentation is sufficient
  • system documentation is sufficient

Process

• The Functional team has got the final decision on which feature is accepted and merged from development to stabilization branch.

Initial Staff

• Victor Perez
• Ramiro Vergara
• Mario Calderon
• Mark Ostermann
• (Kai Schaeffer)
• <please contact the team to become member>

Other teams

There are already other teams that could be integrated into this Integration Process where it makes sense. For example Usability, Security team.

Reverting policy

• technical team has the responsibility to revert code that has been comitted without approval
• The revert should be motivated precisely and without any doubt.
• Any other person outside of the technical team (including the functional team) are not allowed to revert, but are advised to call for a revert where they specify the concrete reasons.

Team Policy

Voting

• In order to approve a contribution at least 2/3 of team members need to vote positively

Membership

• Everybody can become a member of one of the teams
• The team can expell a member when one of the following applies
  • member does not show up for three meetings without informing the other members in advance
  • 2/3 of the team vote for expelling the member