Retail:Release Process
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.
Concepts
freeze: we call freeze to promote the changesets to main and branch out backport repositories. for erp, the promotion is done by int-promote. for retail promotion is manual
Servers involved
Package
Check issues target (normal and emergencies)
- Check in issues that all the issues targeted for the current RRyyQn are close (example for 17Q1.1)
- Check that it is not needed to wait for a specific commit.
Remove permissions to push to the retail repositories (normal)
- Comment the allow_push for the current release in hgrc file
ssh code.openbravo.com -p 19198 -lubuntu ubuntu@code ~ $ su - code ~ # vi /scm/hg/config/hgrc [web erp/pmods/org.openbravo.retail.posterminal erp/pmods/org.openbravo.retail.discounts erp/pmods/org.openbravo.retail.config erp/pmods/org.openbravo.mobile.core erp/pmods/org.openbravo.retail.returns erp/pmods/org.openbravo.retail.pack erp/pmods/org.openbravo.retail.poshwmanager erp/pmods/org.openbravo.retail.poshwmanager.sources erp/pmods/org.openbravo.retail.sampledata erp/pmods-branches/org.openbravo.retail.posterminal-ehub] #allow_push = @core allow_push = staff.rm
Remove permissions to push to the 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.
- Comment the allow_push for the current release in hgrc file
ssh code.openbravo.com -p 19198 -lubuntu ubuntu@code ~ $ su - code ~ # vi /scm/hg/config/hgrc [web erp/backports/3.0RRxxQy.z] #allow_push = @core, @packagers allow_push = staff.rm
- reload apache
code ~ # /etc/init.d/apache2 reload
Create config file (normal and emergencies)
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.
Check for the version of the modules (normal & emergency)
Modules that needs to be published are:
- Normal: ALL
- Emergencies: Only the ones that have changes. Execute the script below to get the list of packages with changes. The ones that have to be published will have the P in the config file.
Create config file (normal and emergencies)
1. Create a local copy of the repositories
ssh packager@releaser-14.openbravo.com -p19198 cd /home/packager/releaser/retail TAG=3.0RRyyQx.y e.g: TAG=3.0RR16Q4.1 ./make_release_repo.sh $TAG cd ~/repos/TAG
2. Get the repos that have changes
cd ~/repos/$TAG for repos in $(ls -1 | grep org) ; do echo $repos ; hg log -l1 -R $repos | grep -e "summary" | grep -v "Updated the module version"; done
3. Copy the last config file, e.g:
cd ~/releaser/retail cp config_3.0RR16Q4 config_3.0RR16Q4.1
4. And update the TPN and version numbers inside the file.
Important: The org.openbravo.retail.pack must always be TP
Things to be taken care on creating the config file:
- T Tag the module. Select this letter if there are no changes
- TP Tag and publish the module, when the repo has changes
- N Just update the module dependency, for the external modules
- Numbering increment, only to modules that are going to be published(the ones with changes):
- by 200 for main release (Note*)
- IMPORTANT: in normal releases update ALL the modules, needed to avoid to major version to share one module and when one relase move to qaa, if the package is already in cs is not moved back to qaa.
- by 10 for emergency release, if case of more than 10 emergencies, raise topic to team.
- by 1 for each repackage
- by 200 for main release (Note*)
- Note* : the increment should be done taking as base the first previous release package, for example Q1 -> 500, Q1.8 -> 580, then for Q2 should be 700
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
Update the version in erp/pmods (normal)
This script will update the ad_module and ad_module_dependency to set the base version for the revision (eg: RR17Q2), so retail team can publish other modules based on this depedency
Note: check there are not outgoing changesets from retail/main to erp/pmods/<reatail-repo>
ssh code.openbravo.com -p 19198 -l ubuntu cd /scm/hg/repos/main for repos in $(ls -1 | grep org); do echo $repos ; hg out -R $repos; done # if you see changests, then some of the previous emergency release tag is not merged to erp/pmods/<retail-repos> # Please do Merge_main_back_to_pi # if there are no changesets can proceed to update the update_retail_pi_version as below ssh packager@releaser-14.openbravo.com -p19198 cd /home/packager/releaser/retail ./update_retail_pi_version 3.0RRyyQn 2>&1 | tee ~/logs/update_retail_pi_version-3.0RRyyQn.log Example: ./update_retail_pi_version 3.0RR17Q2 2>&1 | tee ~/logs/update_retail_pi_version-3.0RR17Q2.log
Update the main repo and branch out the current release (normal)
- Update the retail/main/<retail_repos> to include changesets from erp/pmods/<retail_repos> (automated in make_backport script)
- Create clone of main to retail/backport/<current_release>
ssh code.openbravo.com su - su - apache ./make_retail_backport_repo.sh 3.0RRyyQn e.g: ./make_retail_backport_repo.sh 3.0RR17Q2
Enable access to retail repos and backport (normal)
ssh code.openbravo.com -p 19198 -lubuntu ubuntu@code ~ $ su - code ~ # vi /scm/hg/config/hgrc
[web erp/pmods/org.openbravo.retail.posterminal erp/pmods/org.openbravo.retail.discounts erp/pmods/org.openbravo.retail.config erp/pmods/org.openbravo.mobile.core erp/pmods/org.openbravo.retail.returns erp/pmods/org.openbravo.retail.pack erp/pmods/org.openbravo.retail.poshwmanager erp/pmods/org.openbravo.retail.poshwmanager.sources erp/pmods/org.openbravo.retail.sampledata erp/pmods-branches/ org.openbravo.retail.posterminal-ehub] allow_push = @core ... [web retail/backports/3.0RR17Q2] allow_read = @core, @qa, @contrib, @packaging, issues-ob allow_push = @packagers, @core
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 if there are new issues (repackage)
To decide if a repackage is required, verify if there are new changesets added to the repositories
cd /home/packager/output/3.0RR17Q2/repos for repos in $(ls -1 | grep org); do echo $repos; hg in -R $repos; done
Package the release
(Use screen for release process)
Note : Make sure the retail is packaged when erp is packaged, so the retail has the latest erp verion (for normal release only)
- (normal)
cd /home/packager/releaser/retail ./package 3.0RRyyQn 2>&1 | tee ../../logs/package-3.0RRyyQn.log
- (emergency)
./package 3.0RRyyQn build-qa 2>&1 | tee ../../logs/package-3.0RRyyQn.log
Update qa machine (normal)
Machines:
- qa-retail
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
Note : There exist multiserver environment for testing (* qa-ms-central, qa-ms-store1, qa-ms-store2), update the application to latest (update steps) only when QA team ask for it, and set "AutoStart=yes"
Release Notes (normal and emergencies)
 | 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. |
- Create the wiki document Retail:Release_Notes/RRyyQnX and copy the structure of the template.
- Write the estimate publish date
- (normal) Run the job https://ci.openbravo.com/view/rm/job/int-release-notes/ to get the 'what's new' and 'extension' sections.
- (normal) Prepare the Release Notes for the next release based on the this Retail template
Complete list of fixed issues in the RR (normal)
Add the list of issues/features fixed from last MP to the retail release changelog.
Complete list of fixed issues in the RR (emergency)
1. Get the text about the issues fixed in the release from:
$ ssh issues.openbravo.com -p 19198 -lstaff.rm $ su - # /rt/changelog_script/get_backport_issues.sh RRyyQn.x e.g: # /rt/changelog_script/get_backport_issues.sh RR16Q4.1
2. Edit http://wiki.openbravo.com/wiki/Release_Changelog
- add a new entry for the release.
- paste the text returned by the script above
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:
- Rename PI to RRyyQn, e.g. RR14Q2.
- Create a new empty section for PI.
Email of release notes (normal)
Send an email to team leaders to write the "Fixed issues" section with meaningful messages.
To: antonio.moreno@openbravo.com, dmitry.mezentsev@openbravo.com, staff.rm@openbravo.com Subject: 17Q2 Retail release notes to fill fixed issues Hi Please update the fixed issues section of 17Q2 Release Notes: http://wiki.openbravo.com/wiki/Retail:Release_Notes/3.0RR17Q2 List of issues: http://wiki.openbravo.com/wiki/Retail:Release_Changelog#3.0RR17Q2 Regards RM
Email of packaging (normal and emergencies)
For announce this change search for previous release mail, and edit it accordingly:
- maintain the receivers of the mail
- if gmail create links in the copy paste, put the mouse in the link and remove it
- read the entire mail, to try to avoid copy paste errors
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 update the version and TP string in file /home/packager/retail/config_3.0RRyyQn
T (tag the module) and P (publish/upload to CR).
- Increase the module version by 1 for the modules that has new transplants
- Add 'P' letter to the modules for which there is changes
- Remove 'P' letter from modules which don't have changes
- For the pack: add the 'P' and also increase the version in 1
Update the release changelog
Get the changelog
cd /home/packager/releaser/retail ./make_release_repo.sh 3.0RR17Q1 cat ~/logs/3.0RRyyQn-changelog.log Example: cat ~/logs/3.0RR17Q1-changelog.log Add the new issues to Release_Changelog Note: Check for the issues sorted in ascending order
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)
ssh ubuntu@code.openbravo.com -p 19198 su - su - apache vi /scm/hg/config/hgrc # e.g. for RR16Q4.1 [web erp/backports/3.0RR16Q4.1] # allow_push = @core, @packagers allow_push =
Publish artifacts (normal and emergencies)
- push the tag to repositories.
cd /home/packager/releaser/retail ./publish 3.0RRyyQn 2>&1 | tee ../../logs/publish_3.0RRyyQn.log
Stop QA Machines (normal)
List of machines to be stopped
- qa-ms-central.openbravo.com (eu-west-1)
- qa-ms-store1.openbravo.com (eu-west-1)
- qa-ms-store2.openbravo.com (eu-west-1)
Test that Retail can be installed in the ERP
- Search for the base ERP AMI ERP AMI in Amazon (example if we are testing retail RR16Q2.4 use ERP 3.0PR16Q2.4)
- Start an AMI of the ERP
- In the ERP
- login with Openbravo/openbravo as System Administrator
- select testing as instance use
- accept the heartbeat
- menu instance activation
- activate online
- copy the demo key (/srv/ci/etc/SystemKey.demo-2016.txt in ci.openbravo.com)
- menu Module Management
- submenu settings -> life cicle
- change both upper and down combos to QA Approved (leave the one in the middle untouched)
- save
- submenu add modules
- search for Openbravo for Retail
- select it and click the install button
- verify that the version to install is the one that has been published
- submenu settings -> life cicle
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)
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.
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
Push the automation tag (normal & emergency)
automation/pi-mobile is branched to backports path for all release of retail.
- For normal releases the pi-mobile need to tagged (mandatory)
- For emergeny if any new changesets in retail/backports/3.0RRyyQn.x/pi-mobile and retag the existing 3.0RRyyQn.
- Example : Current release is 16Q2.2 and there are new changesets in retail/backports/3.0RR16Q2.1/pi-mobile, it is must to retag 3.0RR16Q2 to include the new changesets.
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 backport 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
ssh ubuntu@code.openbravo.com -p 19198 su - su - apache cd /var/www ./make_retail_backport_repo.sh 3.0RRyyQx.y
- Verify that the old release folder in retail/backports has been removed and that the old repository is no longer shown in the list of backports https://code.openbravo.com/retail/backports
Restore permissions to the repos
Change permissions
ssh ubuntu@code.openbravo.com -p 19198 su - su - apache cd /scm/hg/config vi hgrc # e.g. for RR17Q1.2 [web retail/backports/3.0RR17Q1.2] allow_read = @core, @qa, @contrib, @packaging, issues-ob allow_push = @packagers, @core
commit changes to the config repo
hg ci -m "Grant access to RR17Qx.y backport repo" -u <username <email>>
reload apache2 as root
ctrl+d /etc/init.d/apache2 reload
Mantis (normal and emergencies)
Go to https://issues.openbravo.com , and select manage -> projects -> retail modules.
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)
- If was needed to do any transplant, remember to recreate the fixed issues section in the release notes
- Add in release notes the new MP released.
- Clean up the MP release note document http://wiki.openbravo.com/wiki/Retail:Release_Notes/3.0RRyyQn
- Remove the WorkInProgress banner
- Remove the "Great feature" texts
- Correct the 'release date and version'
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:
- maintain the receivers of the mail
- if gmail create links in the copy paste, put the mouse in the link and remove it
- read the entire mail, to try to avoid copy paste errors
Update demo (normal and emergency if last)
1. Run the retail demo package job
Retrieve the resulting demo ip from the https://ci.openbravo.com/job/int-demo-prepare-clone/ 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 team.retail@openbravo.com, (get the ip from the mail sent by demo-pacakge job)
e.g.: Demo machine for yyQn.m is ready for testing backend : http://<ip>/retail webpos : http://<ip>/retail/web/org.openbravo.retail.demologinpage/?terminal=VBS-1#login
3. If ok, run the demo publish job.
build_with_parameter CONTINUE="yes" SERVERS demo-eu1 demo-us1 DEMO = retail NOTE: This job is the same of the ERP.
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,
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.
Update the status in the Retail Release Notes page from QAA to CS
Update the Release Notes of the particular release, e.g: 3.0RR16Q4.2
Check update to CS works
- Start an ec2 instance with old release version
- Change the maturity to CS
- Scan for updates and check it updates all the modules to version released
Test CS
- Start an ami of erp in CS just published (example if we are testing retail 16q2.4 use erp 16q2.4)
- Activate the instance (ci retail demo key)
- Check that is configured to search in CS status
- Search for 'Openbravo for Retail'
- Press install and accept heartbeat
It should offer to install the just promoted retail cs
Release Notes (normal and emergencies)
- Set Maturity level column to CS in the the general Retail Release Notes page.
- Update the Release Notes page of that release and remove the message about the module being available in QA Approved.
Announcement (normal and emergencies)
For announce this change search for previous release mail, and edit it accordingly:
- maintain the receivers of the mail
- if gmail create links in the copy paste, put the mouse in the link and remove it
- read the entire mail, to try to avoid copy paste errors
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