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

PDF Books
Show collection (0 pages)
Collections help

Search

Retail: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 openbravo retail release.

Package

Check issues target (normal and emergencies)

Remove permissions to repo (emergencies)

Remove push permissions to backport repo.

Update the main repo and branch out the current release (normal)

log in to code.openbravo.com as apache user execute
./make_retail_backport_repo.sh 3.0RRyyQn

Email retail pmods repos are open for next mp (normal)

Send an email to release management list

pmods retail repo are open for next release.

Any issue in current release must have separate issue with type "backport" and  target_version 3.0RRyyQn, and the changesets must get in to backport repos
https://code.openbravo.com/retail/backports/3.0RRyyQn/
 
The dates for RRyyQn are the usual ones [1].
 
[1] http://wiki.openbravo.com/wiki/Release_Policy#ERP_release

Check for the version of the modules (normal & emergency)

Modules that needs to be published are:

Normal: ALL

Emergencies: only with new commits. To check this open the backport repo and the ones that don't have last commit with our hg user (RM packaging bot).

The ones that have to be published will have the P in the config file.

Check org.openbravo.agingbalance module version (normal)

org.openbravo.agingbalance is external module added to dependency list of retail.pack.

Send mail to Álvaro Ferraz,Víctor Martínez, David Miguélez to confirm on the module version and promote to QA and the tag of the version exist in mercurial repo.

Create config file (normal and emergencies)

Use screen for release process

Things to be taken care on creating the config file

Note : For emergencies, update the version for the modules which has new changeset and need to be published.

Example:

 T 1.3.2120 org.openbravo.retail.discounts
 TP 1.2.2130 org.openbravo.retail.posterminal
 T 1.0.1410 org.openbravo.retail.config
 T 1.0.1010 org.openbravo.mobile.core
 T 1.0.320 org.openbravo.retail.returns
 T 1.0.120 org.openbravo.retail.sampledata
 T 1.0.1510 org.openbravo.retail.poshwmanager
 TP 1.8.330 org.openbravo.retail.pack
 N 3.1.31 org.openbravo.agingbalance
 N 1.0.1 org.openbravo.financial.cashflowforecast

Run the package

Note : Make sure the retail is packaged when erp is packaged, so the retail has the latest erp verion (for normal release only)

cd /home/packager/releaser/retail
./package 3.0RRyyQn 2>&1 | tee ../../logs/package-3.0RRyyQn.log
./package 3.0RRyyQn build-qa 2>&1 | tee ../../logs/package-3.0RRyyQn.log

Update qa machine (normal)

Machines:

Do system update off all

/etc/init.d/tomcat stop
apt-get update
apt-get dist-upgrade
apt-get autoclean
apt-get --purge autoremove
reboot

Since the update of the erp is quite dificult we do it instead of qa, here is the doc , check the end part: udpate.

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 RR (normal)

TODO: create changelog script to get this from backport repo !!

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

Complete list of fixed issues in the RR (emergency)

$ /rt/changelog_script/get_backport_issues.sh RRyyQn.x
example : $ /rt/changelog_script/get_backport_issues.sh RR16Q2.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 "Whats New" and "Extension" section with meaningful messages.

Recipients: Antonio, Dmitry, staff.rm

Email of packaging (normal and emergencies)

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

Second package

Edit config file (normal and emergencies)

Check new commits

cd /home/packager/output/3.0RRyyQn/repos
for repo in $(ls -1) ; do hg in -R $repo ; done

For the modules with new changesets updfate the version and TP string in file /home/packager/retail/config_3.0RRyyQn

T (tag the module) and P (publish/upload to CR).

Package (normal and emergencies)

cd /home/packager/releaser/retail
./package 3.0RRyyQn 2>&1 | tee ../../logs/package-3.0RRyyQn.v2.log 

Note : If QA request to rebuild the test machine pass 'build-qa' as parameter to package command ./package 3.0RRyyQn build-qa

After that can be followed the normal process to send email and create qa machine.

Email of the package (normal and emergencies)

Sent email of the repackage done, and include the new issues added.

Publish

Remove permissions to repo (only normal)

Remove push permissions to repo in code.

Publish artifacts (normal and emergencies)

cd /home/packager/releaser/retail
./publish 3.0RRyyQn 2>&1 | tee ../../logs/publish_3.0RRyyQn.log

Test QAA

  1. Start an ami of erp in QAA just published (example if we are testing retail 16q2.4 use erp 16q2.4)
  2. Activate the instance (ci retail demo key)
  3. CHANGE configuration to search in QAA status
  4. Search for 'Openbravo for Retail'
  5. Press install and accept heartbeat

It should offer to install the just promoted retail qaa


Merge to main (normal and emergencies)

After run the previous script, if we are releasing a emergency update run

Note: Check if new modules in pi, if no call the script

cd /home/packager/releaser/retail
./merge-retail-to-main.sh 3.0RRyyQn 2>&1 | tee ../../logs/merge-retail-to-main_3.0RRyyQn.log

Merge main back to pi (normal and emergencies)

Connect to code and using the user that is owner of repos execute:

./retail-merge-main-pi.sh 3.0RRyyQn 2>&1 | tee retail-merge-main-pi_3.0RRyyQn.log

Note: currently is under development, needed manually to ensure to pass the module and dependencies versions from main to pi.

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.

Push the automation tag (normal & emergency)

automation/pi-mobile is branched to backports path for all release of retail.

cd /home/packager/releaser/retail
./merge-pi-mobile-tags.sh 3.0RRyyQn 2>&1 | tee ../../logs/merge-pi-mobile-tags-3.0RRyyQn.log

Create new repo in code (normal & emergencies)

Close the current used backports repos and create new ones for the next version.

Example: if we publish Q3 create repo for Q3.1, if we publish Q3.1 create Q3.2

./make_retail_backport_repo.sh 3.0RRyyQx.y

Mantis (normal and emergencies)

Go to https://issues.openbravo.com , and select manage -> projects -> retail moduels.

In the versions mark the current RRyyQn version as released.

Create a new target versions of the type of the just published. Idea is that should be two actives branches in each thread. For example should be 2 normal released available, 2 target versions of q1.x and 2 target versions of q3.x.

Release notes (normal and emergencies)

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 (normal and emergencies)

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

Update demo (normal and emergency if last)

Run the retail demo package job .

Send email to retail team to check the demo.

After they ok, run the demo publish job . 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,

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

Test CS

  1. Start an ami of erp in CS just published (example if we are testing retail 16q2.4 use erp 16q2.4)
  2. Activate the instance (ci retail demo key)
  3. Check that is configured to search in CS status
  4. Search for 'Openbravo for Retail'
  5. Press install and accept heartbeat

It should offer to install the just promoted retail cs


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)

This is common for erp and retail: Link to this part in the erp release process

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

This page has been accessed 4,040 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.