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 Process

Contents

Introduction

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.

Package 1st of each month (normal)

Disable int-promote (normal)

Disable job http://ci.openbravo.com/job/int-promote/

Check issues target (normal and emergencies)

Update the release status in aha (normal)

Update the cloud image (normal)

Check for the latest image in [ http://cloud-images.ubuntu.com/releases/14.04/ ubuntu_cloud_images]

cd releaser
# Edit the config file for folder name (yyyymmdd)
UBUNTU_CLOUD_IMG="20160406"
# Execute 
./get_ubuntu_cloud_img

Create backport repo (normal)

Create the backport repo for the current release, so pi is not blocked for next release

As apache user in code.openbravo.com

./make_erp_backport_repo.sh 3.0PRyyQn

Ensure the repo has the needed permissions and is accesible by developers for read and write.

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.


Run the package (normal and emergencies)

Check for disk space

Remove the old releases in ~/outputs folders and clean ~/builds/*.

 cd ~/outputs 
# criteria of release folders to delete
* Not latest emergency releases
* The releases promoted to CS
# Note: Remove old release repos: check the folders in path '~/repos', if the release is published remove it.

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.

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

Update qa machine (normal)

Start qa-erp (i-f0280b3c) and do system update

/etc/init.d/tomcat stop
apt-get update
apt-get dist-upgrade
apt-get autoclean
apt-get --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)
./modules-reminders.sh package 3.0PRyyQn emails-no
# real run sending the mails to teams
./modules-reminders.sh package 3.0PRyyQn emails-yes 2>&1 | tee ../logs/modules-reminders-package-3.0PRyyQn.log

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

Create the automation tag (normal)

cd ~/repos/automation_pi
hg pull -u
hg tag 3.0PRyyQn

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.

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)

$ /rt/changelog_script/get_backport_issues.sh 3.0PRyyQn.x
example : $ /rt/changelog_script/get_backport_issues.sh 3.0PR16Q2.3

Optionally can be checked with roadmap page to ensure that is correct: https://issues.openbravo.com/roadmap_page.php

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.

Recipients: Asier Lostale, Eduardo Argal, Victor Martinez, Egoitz, Pablo Sarobe, staff.rm, Dmitry

Email of packaging (normal and emergencies)

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

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

[1] http://wiki.openbravo.com/wiki/Release_Policy#ERP_release

Second package (normal and emergencies)

Update repo (normal)

Get the changesets included in the second package

hg in -R main-3.0PRyyQn | grep changeset | cut -d: -f3 | sed -r 's#(.*)#https://code.openbravo.com/erp/devel/main/rev/\1#'

Update the repo of the release

hg pull -u -R main-3.0PRyyQn

Update repo (emergencies)

Get the changesets included in the second package

hg in -R main-3.0PRyyQn

Update the repo of the release

hg pull -u -R main-3.0PRyyQn

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

Email of the package (normal and emergencies)

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

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 always till last day of month to run the publish.

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

As we are inside publish we know last (re-)package was the last one. This means there are no commit allowed in the backport repo which are not included in this last package.

If there are stop all publish and check.

Run the publish script (normal and emergencies)

In the releaser machine

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

Stop QA test machines (normal)

Check with QA and stop the testing machines qa-erp and qa-retail machines

Modules reminder (normal)

Note: only normal releases, no emergencies

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)
./modules-reminders.sh publish 3.0PRyyQn emails-no
# real run sending the mails to teams
./modules-reminders.sh publish 3.0PRyyQn emails-yes 2>&1 | tee ../logs/modules-reminders-publish-3.0PRyyQn.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 code.openbravo.com/docs 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.

Repositories

Merge to main (normal and emergencies)

No steps required for normal release.

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

# 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 di -r $MAIN_ID
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.

To run the merge of the tags from main to pi, connect to code and using the apache user run this script:

./merge-main-pi-erp.sh 2>&1 | tee merge-main-pi-3.0PRyyQn.log

Once that finish check that all the output is fine, and do the push

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

Create new repo in code (emergencies)

#login to code and execute the below as apache user 
./make_erp_backport_repo.sh 3.0PRyyQx.y
#remove the previous erp version from repos/backports

Push the automation tag (normal)

Usually it is not needed to do in emergencies updates.

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.

Mantis (normal and emergencies)

Release notes (normal and emergencies)

Note : If emergency release, mark the previous release to 'C' in release-history and actual release notes

Email of modules (normal)

Send an email to team leaders that owned a module published in the release to move the status of the modules to QAA maturity status.

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.

Announcements

Email (normal and emergencies)

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

IRC announce (normal and emergency if last)

Change the topic of the IRC channel #openbravo :

/msg chanserv op #openbravo <your nick>
/topic  Openbravo | Latest: 3.0PRyyQn | http://wiki.openbravo.com | POS support in forums: http://goo.gl/h2kRS
/msg chanserv op #openbravo -<your nick>

Also in #openbravo-es :

/topic  Openbravo | Última versión: 3.0PRyyQn | http://wiki.openbravo.com | Soporte de POS en foros: http://goo.gl/h2kRS

Enable int-promote (normal)

Enable job http://ci.openbravo.com/job/int-promote/

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

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)

Run the demo package job .

Send email to functional team to check the demo.

After they ok,

check if the login works correctly

NOTE: This job does a system update + reboot of the demo machines

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.

Check update to QAA works

Modules reminder (normal)

Note: only normal releases, no emergencies

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)
./modules-reminders.sh cs 3.0PRyyQn emails-no
# real run sending the mails to teams
./modules-reminders.sh cs 3.0PRyyQn emails-yes 2>&1 | tee ../logs/modules-reminders-cs-3.0PRyyQn.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

Regards,
--

Retrieved from "http://wiki.openbravo.com/wiki/Release_Process"

This page has been accessed 47,025 times. This page was last modified on 7 December 2016, at 12:51. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.