View source | Discuss this page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Add page
Show collection (0 pages)
Collections help

Search

Release Management/Managing code.openbravo.com

Release Management/Internal

Index


Contents

Introduction

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.

Topology

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.

Openbravo ERP repositories structure

URL scheme: http://code.openbravo.com/[project]/[stage]/[subproject]

List of projects:

Openbravo ERP stages and repositories:

Openbravo POS stages and repositories:


Tree View of Repository

/scm/hg/repos/
|-- 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

New repository

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

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.


Modules

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.

Others

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.

Authentication

Authentication is provided by Apache httpd, using HTTPS and Basic Authentication. The stages are distributed, based on the authentication, as follows:

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

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.

Authorization

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.

Hook scripts

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

Check author format

We expect to see a user name with the format 'Real Name <some@email.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

Mantis integration

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

Licensing control

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


Summary length

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

Retirement

Repositories that are no longer usful or have already been merged are moved into /scm/hg/repos/retired, respecting the subtree in which it was located. For example erp/devel/pi-cyclone should be moved to /scm/hg/repos/retired/erp/devel/pi-cyclone.

Mirrors

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.

Retrieved from "http://wiki.openbravo.com/wiki/Release_Management/Managing_code.openbravo.com"

This page has been accessed 4,541 times. This page was last modified on 14 November 2011, at 14:27. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.