Release Management/Managing code.openbravo.com
Openbravo ERP and POS use Mercurial as SCM, hosted in code.openbravo.com. We could say that the ERP uses a controlled collaboration practice, so that there is a pre-integration and development repository called pi and integration and QA repository called main. On the contrary the POS project uses a more centralized model, mainly due to the low number of developers on it.
Openbravo follows the one repository per branch model, so named branches are not allowed in the Openbravo repositories.
The Openbravo repositories follow a topology described as follows.
URL scheme: http://code.openbravo.com/[project]/[stage]/[subproject]
List of projects:
- erp: Openbravo ERP.
- pos: Openbravo POS.
- tools: Tools (QA, Release Management, etc).
Openbravo ERP stages and repositories:
- devel: development.
- pi: Pre-Integration repository. This repository is used for development and project merging.
- main: the Main development repository. Only QA approved changesets get promoted from pi to main. Developers never push to this repository.
- pi-branch-1: branch of pi for a new feature.
- stable: stabilization branches.
- 2.40: stable branch for version 2.40.
- 2.3x: stable branch for version 2.3x.
- mods: Openbravo ERP modules for version >=2.50.
Openbravo POS stages and repositories:
- devel: development.
- main: the Main development repository.
- stable: stabilization branches.
- 2.10: stable branch for version 2.10.
- 2.20: stable branch for version 2.20.
- 2.30: stable branch for version 2.30.
Tree View of Repository
ssh email@example.com -p 19198 su - su - apache cd /scm/hg/repos/ tree -L 2
|-- erp | |-- devel | | |-- api-checks | | |-- cr2 | | |-- main | | |-- pageddatagrid | | |-- pi | | |-- pi-epic | | |-- ui-dojo-prototype | | `-- upgrader-2.40_2.50 | |-- mods | | |-- org.openbravo.accountingalerts | | |-- org.openbravo.base.seam | | |-- org.openbravo.bpdebtconsolidation | | |-- org.openbravo.directdebit | | |-- org.openbravo.document.massinvoicing | | |-- org.openbravo.hcm.common | | |-- org.openbravo.interco | | |-- org.openbravo.massadvancedpayments | | |-- org.openbravo.pos.sync | | |-- org.openbravo.spanishaccountingmodgral | | |-- org.openbravo.spanishaccountingmodpyme | | |-- org.openbravo.spanishtaxes | | |-- org.openbravo.taxreportlauncher | | |-- org.openbravo.userinterface.extjs | | `-- org.openbravo.utility.multiplebpselector | |-- pmods | | |-- org.openbravo.apparel | | |-- org.openbravo.butler | | |-- org.openbravo.butler.ops | | |-- org.openbravo.butler.template | | |-- org.openbravo.invoicesregisterbook | | |-- org.openbravo.spainaeatmodelo347 | | `-- org.openbravo.xidl | `-- stable | |-- 2.3x | |-- 2.40 | `-- 2.40_pageddatagrid |-- pos | |-- devel | | `-- main | |-- pro | | `-- network | `-- stable | |-- 2.10 | |-- 2.20 | `-- 2.30 |-- retired | |-- erp | | `-- devel | | |-- cyclone | | |-- ops-security | | `-- tax-report-launcher | `-- stable | `-- 2.40_cyclone `-- tools |-- automation | |-- 2.3x | |-- 2.40 | `-- main `-- rm |-- automation |-- erp-setup-tool |-- hudson |-- mantis |-- mercurial |-- packages | `-- ubuntu `-- rapa-plugin-ops
The development team usually needs a shared location to store repositories. Depending on the kind of request, these repositories must be created in different stages.
Branches of pi should go under erp/devel, and named pi-featurename. These branches are usually used for new features. The server only needs a cloned repository, e.g. no working directory files. To create the repository:
$ cd /scm/hg/repos/erp/devel $ hg clone -U pi pi-featurename $ chown -R apache:apache pi-featurename
Now we need a useful description and a contact e-mail for this repository. This should be added into /scm/repos/hg/config/hgrc.
Public modules should go under erp/mods and private modules under erp/pmods. Compared to branches, modules most frequently will start as an empty repository:
$ cd /scm/hg/repos/erp/mods $ hg init org.openbravo.modulename $ chown -R apache:apache org.openbravo.modulename
And we also need to provide a useful description and contact e-mail in /scm/repos/hg/config/hgrc.
QA and Release Management repositories are stored under tools/automation and tools/rm respectively. The new repository creation procedure is the same as with the modules.
Read and push access
We use the reposettings extension to manage all the permissions in a single file.
[web <path_to_repo>] allow_push = <users> [web <path_to_repo>] contact = <team name <team-mailing-list-id> description = <short description>
Authentication is provided by Apache httpd, using HTTPS and Basic Authentication. The stages are distributed, based on the authentication, as follows:
- devel and mods: no auth needed for reading/pulling, auth required for pushing.
- stable and pmods: auth needed for reading/pulling/pushing.
All the authentication credentials are stored using MD5 or SHA1 hashes in /scm/hg/config/hg-auth-file.
To add a new user:
$ htpasswd -m /scm/hg/config/hg-auth-file user_name (enter password twice)
You can use the following command to generate a pseudorandom password:
$ cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 10 | sed 1q
This e-mail template can be used to notify new users about their accounts:
Your credentials for code.openbravo.com are the following: username: password: You can change your password in the following address: https://code.openbravo.com/hgpasswd We recommend you reading the Mercurial at Openbravo guide: http://wiki.openbravo.com/wiki/Mercurial_Manual_for_Openbravo_Developers
- Also is needed to add the new user and email to MAIL_MAP in Get email of ci.openbavo.com
To remove a user from the authenticated list, edit hg-auth-file and remove the entire line containing the user name and the password hash.
Mercurial takes care of the authorization. And this is managed in the /scm/hg/config/hgrc file, by using the allow_read, deny_read, allow_pull, deny_pull, allow_push and deny_push directories. However we usualy just use allow_read and allow_push. Read the reposettings extension wiki for complete usage instructions.
There are some hook scripts running for different purposes.
Forbid 2 heads
We want all the merge to be done in the developer side and we don't want multiple heads in the reference server. So we set up the hook script in the pretxnchangegroup, which means before the changeset transaction is finished:
pretxnchangegroup.forbid_2heads = /scm/hg/hooks/forbid_2heads.sh
We expect to see a user name with the format 'Real Name <firstname.lastname@example.org>'. And it is really annoying not to know who did a commit because it's shown as 'Fred'. So we abort the push transaction if one of the changesets does not contain the author name in the required format.
pretxnchangegroup.author_format = /scm/hg/hooks/author_format.sh
Depending on the commit message a note can be automatically added to the issue or even it can be automatically set to resolved. Check our Mercurial manual for more information. This hook script is run once the changeset has entered the repository:
incoming.hgmantis = /scm/hg/hooks/hgmantis.sh
We have to control that the licensing of the newly added files make sense and that they licensing years are also coherent. For this purpose the RM team receives an e-mail every time a new file is added into the pi repository:
changegroup.license_fileadds = /scm/hg/hooks/license_fileadds.sh
Some developers do not follow our commit message guidelines. This hook script automatically warns them about this.
changegroup.summary_length = /scm/hg/hooks/summary_length.sh
Repositories that are no longer useful or have already been merged are retired until some period of time has passed. The process involves 2 tasks:
1. Remove any reference to the repository in the hgrc file
$ ssh code.openbravo.com -p 19198 -lstaff.rm staff.rm@code ~ $ su - code ~ # su - apache apache@code ~ $ cd /scm/hg apache@code /scm/hg $ vi config/hgrc
2. Move the repository to the retired folder
apache@code /scm/hg $ python retire_repo.py <path to the repo> e.g: apache@code /scm/hg $ python retire_repo.py repos/erp/devel/pi-customerimprovementsmerge
We maintain Mercurial and Git mirrors of Openbravo ERP and POS, maintained in sourceforge.net. The Mercurial mirrors (ERP, POS) are straightforward, by just pushing to the remote mirror. And the Git mirrors (ERP, POS) and used by using the hg-fast-export tool. For more details check /usr/local/bin/sf-hgsync.sh and /usr/local/bin/sf-hg2git.sh.