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

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


Release Process



This document describes the different phases of the release engineering process leading up to the actual build and publication of a 3.0 release, both the Community Edition and the Professional Subscription.

Overall process

  1. package
  2. pass the machine to QA for testing
  3. QA will mail all fine to proceed with publish
  4. we do publish in QAApproved status
  5. for 17Q1.1 the plan is to put in CS
  6. CS: get okay with DME and PLU for final promotion to CS and do promote_cs for both erp and retail together

Package 1st of each month (normal)

Check issues target (normal and emergencies)

Disable int-promote (normal)

Disable job

Create backport repo (normal)

Create the backport repo for the current release, so pi is not blocked for next release. Note that backport repositories are created based on main, so they cannot be created at this stage.

su - 
su - www-data
./ 3.0PRyyQn
./ 3.0PR17Q2

Update the release status in aha (normal & emergency)

Login using ismael account
Navigate to Releases -> Details
Select the current release version in the top tab bar
Check 'Status' and update it
* For normal first package status must be "Send to QA"
* On publish of normal release must be "QAA"
* On first CS of the emergency release it must be "CS"

Email pi open for next mp (normal)

Send an email to release management list

PI is now open for PRyyQn commits.

The dates for PRyyQn are the usual ones [1].


e.g: for sending erp + retail email saying repos are opened

subject: erp & retail repos open for 17Q3 and Backports available for 17Q2


erp/devel/pi and erp/pmods open for 17Q3

Backports for 17Q2 available at:


Update the cloud image (normal)

Check for the latest image (at the bottom) in [ ubuntu_cloud_images]

ssh -p19198
cd /home/packager/releaser
nano config

# Edit this the UBUNTU_CLOUD_IMG line and set it to the last version
e.g.: UBUNTU_CLOUD_IMG="20160406.1"
# Execute 

Update the releaser14 (normal)

Update the packing machine and put the current date in last-update column for releaser14 in server-update-sheet

# connect to release14
sudo su -
apt-get clean
apt-get update
apt-get dist-upgrade
apt-get autoclean
apt-get --purge autoremove

Remove permissions to push backport repo (emergencies)

Before run the package of a emergency release is needed to remove push permissions to the repo , so no new commits come unexpectedly during the process.

ssh -p 19198  -lubuntu
ubuntu@code ~ $ su -
code ~ # vi /scm/hg/config/hgrc

[web erp/backports/3.0PRxxQy.z]
#allow_push = @core, @packagers
allow_push = staff.rm
code ~ # /etc/init.d/apache2 reload

commit the change to the repo e.g:

cd /scm/hg/
hg ci -m "Revoke access to 3.0PR16Q3.5 repo" -u "Rafa Alonso <>"

Run the package (normal and emergencies)

Connect to the releaser

ssh -p19198

Check for disk space

df -h

Remove the old releases in ~/outputs/

 cd ~/output
# criteria to delete
* Not latest emergency releases
* The releases promoted to CS

Clean the folders from ~/repos/

 cd ~/repos
# criteria to delete
* Remove old release repos. If the release is published remove it.

Clean the folders from ~/build/

cd build
rm -rf 3.0*

For all packages it is needed to create the qa instances, except for the repackages of normal releases, and also it is needed to be careful to not delete the instance that they are using for this normal releases. This is pending to automate.

cd ~/releaser

Normal :

./package 3.0PRyyQn 2>&1 | tee ../logs/package-3.0PRyyQn.log

Emergency :

./package 3.0PRyyQn.o build-qa 2>&1 | tee ../logs/package-3.0PRyyQn.o.log
note: build-qa is same as executing ./build_qa_instance 3.0PRyyQn.o after ./package

2 emails should be received at

Update qa machine (normal)

Amazon search

ssh -lopenbravo
sudo su -
/etc/init.d/tomcat stop
apt-get -qq update && echo '------- >> finished update' && apt-get -qq dist-upgrade && echo '------- >> finished dist-upgrade' && apt-get -qq autoclean && echo '------- >> finished autoclean' && apt-get -qq --purge autoremove && echo '------- >> finished --purge autoremove' && reboot

If needed, QA will ask for another machine to test update, check with QA if needed an instance with previous QAA or CS release

./build_qa_instance 3.0RRyyQn.o 2>&1 | tee ../logs/build_qa_instance-3.0PRyyQn.log

Modules reminder (normal)

Note: only normal releases, no emergencies. And in the first package. Important: Retail should be also packaged and the merge of release versions merged into pi (pmods) repos of retail should be done

cd ~/releaser
# Do a first check without send mails , check that no appear personal emails, only should appear the usual teams ones (erp engineering support one should not appear also)
./ package 3.0PR17Q1.1 emails-no 2>&1 | tee ../logs/modules-reminders-package-3.0PR17Q1.1.log
# real run sending the mails to teams
./ package 3.0PRyyQn.o emails-yes 2>&1 | tee ../logs/modules-reminders-package-3.0PRyyQn.o.log

After the first notification remind weekly to the teams till done.
Note : Add calendar entry in time span of one week to check of confirmation mail from teams.

Create the automation tag (normal)

ssh -p19198
cd /home/packager/repos/automation_pi
hg pull -u
hg tag 3.0PRyyQn

Complete list of fixed issues in the PR (normal)

Add the list of issues/features fixed from last MP to the release changelog.

Complete list of fixed issues in the PR (emergency)

1. Get the text about the issues fixed in the release from:

 $ ssh -p 19198 -lstaff.rm
 $ su -

 # /rt/changelog_script/ 3.0PRyyQn.x
 e.g: # /rt/changelog_script/ 3.0PR16Q4.1

2. Edit

Optionally can be checked with roadmap page to ensure that is correct:

Release Notes (normal and emergencies)

Bulbgraph.png   In order to allow developers to write the release notes when they commit some issue/project, the release notes for the next release should be also available.

e.g, for PR16PR4.1

Update API changes wiki (normal and emergencies)

Update the API changes list, as follows:

Email of release notes (normal)

Send an email to team leaders to write the "Fixed issues" section with meaningful messages.

Subject: 17Q2 ERP release notes to fill fixed issues


Please update the fixed issues section of 17Q2

Release Notes:

List of issues:


Email of packaging (normal and emergencies)

Send an email to following this template example:

Subject: 17Q1 Final package (erp and retail)


17Q1 repackaged, QA Machines can be updated via MMC with QA maturity.

Version: 3.0.31087
35371: Wrong orders shown in "Create Invoices From Orders" window

Version: 1.8.2502
35021: Copyright year extend to 2017 for pos hardware manager

Second package (normal and emergencies)

Do the package (normal and emergencies)

Run the package

cd ~/releaser
./package 3.0PRyyQn 2>&1 | tee ../logs/package-3.0PRyyQn.v2.log  
Note : If QA request to rebuild the test machine pass 'build-qa' as parameter to package command ./package 3.0PRyyQn build-qa

Update the release changelog

Get the changelog

cat ~/logs/3.0PRyyQn-changelog.log
Example: cat ~/logs/3.0PR17Q1-changelog.log
Add the new issues to Release_Changelog
Note: Check for the issues sorted in ascending order

Email of the package (normal and emergencies)

For announce this change search for previous release mail, and edit it accordingly:


Subject: yyQn packaged (erp and retail)


YYQn for ERP and Retail packaged for testing

ERP version : 3.0.<version> - PRyyQn
Changelog :
QA Machine :

Retail version : 1.8.<version> - RRyyQn
Changelog :
QA Machine :


Dummy (normal and emergencies)

When QA ask for a obx to test the update, run in releaser instance:

cd ~/releaser
./build_upload_dummy 3.0PRyyQn 2>&1 | tee ../logs/dummy-3.0PRyyQn.log

Publish (normal and emergencies)

Wait for the Product manager and QA to approve the publishing

Check for 'lost' commit done after last package (normal)

The repository was closed to further pushes when the packaging started, so this step can be skipped.

If for any reason new pushes have been added, stop all publish and check.

Run the publish script (normal and emergencies)

In the releaser machine

ssh -p19198
cd ~/releaser
./publish 3.0PRyyQn 2>&1 | tee ../logs/publish-3.0PRyyQn.log

Verify that the process exits with status 0

Modules reminder (normal)

Note: Should be done only once when the version is first promoted to QAA maturity.

cd ~/releaser
# Do a first check without send mails , check that no appear personal emails, only should appear the usual teams ones (erp engineering support one should not appear also)
./ publish 3.0PR17Q1.1 emails-no 2>&1 | tee ../logs/modules-reminders-publish-3.0PR17Q1.1.log
# real run sending the mails to teams
./ publish 3.0PR17Q1.1 emails-yes 2>&1 | tee ../logs/modules-reminders-publish-3.0PR17Q1.1.log

After the first notification remind weekly to the teams till done.

API docs

This step is fully automated. The javadoc is created on packaging, uploaded to and its index page is updated.

API check

Ths package/publish is also taking care of re-genearing the api-checks data on every (non-emergency) release and pushes it to api-checks.


Merge to main. Rearrange tags (normal and emergencies)

This step sorts the tags in the repository. Sorted tags are required for other RM scripts to work. No steps required for normal release. No steps required for the last version. You can also verify if the tags must be rearranged, looking at the tags in the repository If the published version is not the first one, rearrange is required.

Partially automated for emergency release publish. Re-ordering of tag is required. Check of the publish script message "NEED to ORDER the releases"

ssh -p19198
cd /home/packager/output/3.0PRxxQn.m/merge-main
# Manually reorder the entries in .hgtags and .hgsigs
hg resolve -a -m
hg ci -m "Merge temporary head for $TAG"
# Check that everything it is fine and push
hg glog | more
hg out

hg push

Merge main to pi (normal and emergencies)

NOTE: if publishing a emergency release during release process of a normal release, then not needed to do the merge of tags form main to pi, since when done this merge for the normal release this will automatically done. Is possible to do the merge from main to pi of emergencies without wait to the normal release, but ensure when merging the normal release from main to pi that the tags are correctly merged and none is lost.

1. Merge tags from main to pi:

ssh -p 19198
su - 
su - www-data
./ 2>&1 | tee merge-main-pi-3.0PRyyQn.log

2. Verify the merge

cd /tmp/merge_main_pi_erp_temp
hg tags
hg log -G | less

3. Finally

hg push

Create new backport repo in code (emergencies)

Note that the backport repository is created based on main, so, once the publish script has finished, the backport can be created

ssh -p 19198
su - 
su - www-data
cd /var/www
./ 3.0PRyyQx.y
e.g: if publishing PR16Q4.1
./ 3.0PR16Q4.2

Restore permissions to the repos

Change permissions

ssh -p 19198
su - 
su - www-data
cd /scm/hg/config
vi hgrc
# e.g. for PR16Q4.1
[web erp/backports/3.0PR16Q4.1]
allow_push = @core, @packagers

commit changes to the config repo

hg ci -m "Grant access to PR16Qx.y backport repo" -u <username <email>>

reload apache2 as root

/etc/init.d/apache2 reload

Push the automation tag (normal)

Usually it is not needed to do in emergencies updates

Verify that the changeset is the correct one

  1. check the email of the push that passed try
  2. if any doubt ask QA


cd ~/repos/automation_pi
hg in
# hg pull --rebase
hg out
hg push

SourceForge (normal and emergency if last)

Check the vmware of the current MP is the default download for Openbravo project.

Update status in AHA (normal)

Refer to Update_the_release_status_in_aha

Mantis (normal and emergencies)

Release notes (normal and emergencies)


In 3.0 release notes, add a new entry for the new release, copying another and updating the links

Add CS date to calendar (normal)

Add to calendar the day to pass CS, it is fixed date, the last day of moth in two months after the publish in qaa.


Pre-Sales (normal and emergencies)

need to be sent to

Xavier Places <>, Dmitry Mezentsev <>, "Staff.RM OB" <>

Email template example:

Recipients: Xavier Places <>, Pablo Rueda <>, Dmitry Mezentsev <>, "Staff.RM OB" <>
Subject: Released 16Q4.1 in 'QA Approved' and 16Q3.5 'Confirm Stable' status

New versions of ERP and Retail are published in 'QA Approved' and 'Confirm Stable' maturity. Also ready to announce

16Q4.1 QA Approved Maturity:

16Q3.5 Confirm Stable Maturity

Email backports are available (normal and emergencies)

Email template

To: team.platform <>, Team ERP Engineering <>, Team Retail <>, Team StoreServer <>, Staff.RM OB <>, Sofware Factory <>
Subject: 17Q1.1 backport repositories available


17Q1 is published in 'QA Approved' status and 17Q1.1 repos are
available for backport.




Enable int-promote (normal)

Enable job

Make POST_PUBLISH_ERP=true in ci To disable the 'SystemValidatorTest and check.module.consistency' for modules and retail job.

Note: Remember to make POST_PUBLISH_ERP=false after one int-promote is completes.

Check log update (normal)

Update the "Check log" script in jenkins and replace all the 99999 with the version of the erp published.

Update demo (normal)

1. Run the demo package job

Retrieve the resulting demo ip from the job. Note that both ERP and Retail execute this job

2. Check version in clone

 login http://<ip>/openbravo 
 Help -> about (check for version)

Send an email to, (get the ip from the mail sent by demo-pacakge job)

Demo machine for erp version yyQn.m is ready for testing
backend : http://<ip>/openbravo

3. If ok, run the demo publish job.

SERVERS demo-eu1 demo-us1
DEMO = erp

NOTE: This job does a system update + reboot of the demo machines (update server_update_sheet for date of demo system update)

4. check if the login works correctly in demo-eu1 and demo-us1

Confirmed Stable promotion (normal and emergencies)

When the MP was for 40 days in QA Approved it's needed to promote it to Confirmed Stable, execute in releaser machine:

Note: erp can only be promoted to Cs only after retail is published in QAA

example : if 16Q3.3 to CS make sure 16Q3.3 is already in QAA and ready for CS promotion

cd ~/releaser
./promote_cs 3.0PRyyQn 2>&1 | tee ../logs/promote_cs-3.0PRyyQn.log
INFO: Folders for 3.0PRyyQn in ~/repos, ~/output can be removed after promote to Confirmed stable maturity.

Update the status in the Release Notes page from QAA to CS

Update the Release Notes of the particular release, e.g: 3.0PR16Q4.3

Check update to QAA works

Modules reminder (emergency)

Note: Should be done only once when the version is first promoted to CS maturity.

cd ~/releaser
# Do a first check without send mails , check that no appear personal emails, only should appear the usual teams ones (erp engineering support one should not appear also)
./ cs 3.0PR17Q1.1 emails-no 2>&1 | tee ../logs/modules-reminders-cs-3.0PR17Q1.1.log
# real run sending the mails to teams
./ cs 3.0PR17Q1.1 emails-yes 2>&1 | tee ../logs/modules-reminders-cs-3.0PR17Q1.1.log

After the first notification remind weekly to the teams till done.

Release Notes (normal and emergencies)

Announcement (normal and emergencies)

For announce this change search for previous release mail, and edit it accordingly:

Cancel the pending previous confirm stable emergencies (normal and emergencies)

For example if q3.x is promoted to cs, all the q2.x not published needs to be canceled.

In issues:

Example email for send to release management:

Subject: Canceled erp >= 15q2.7 and retail >= 15q2.6 releases

Hi all,

ERP and retail 15q3.x have been promoted to confirmed stable (CS), so all the pending (not yet published) 15q2.x releases of erp and retail are canceled.

As a consequence we have:
- retired the backports repositories
- rejected all the backports with that target version
- made this target version unavailable for new backports


Retrieved from ""

This page has been accessed 54,044 times. This page was last modified on 11 December 2018, at 12:13. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.