ERP 2.50:Release Timeline
Contents |
Introduction
This document describes the different phases of the release engineering process leading up to the actual build and publication of a 2.50 maintenance pack.
Goals
- The main goal is to release a Openbravo ERP 2.50 minor version at the end of every month (aka maintenance pack).
- Developers should know what commits they push go into what release. This way they can organize their work more efficiently.
- The QA team should know the exact dates in which the QA starts and the project merges happen.
- The Release Management team should know the exact dates in which to freeze and release.
- The Support team should know the exact date ranges in which their issues will get into which release. And these ranges need to comply with the SLAs.
- Users and customers like to know the exact release dates, e.g. at the end of every month.
So it is clear that releasing like a clock at the end of every month is beneficial for all the parties. Now we will see what we need to do to coordinate all the teams in this effort.
These policies are a result of discussing the topic with developers, the QA Team, the Support Team and Engineering managers.
Scheduling overview
Developers: commit guarantee threshold
So the first thing we need to do is to put it clear for the developers which of their commits will go into which release. When they can perform project reintegrations. To sum up, how they should organize their teams and their time.
As a first policy, every push done to erp/devel/pi until the 15th of every month will be guaranteed to go into the release. The Release Management team will work together with the developers to guarantee this. If all the tests pass the 15th then the RM team will do nothing. But if some tests do not pass then RM will work closely with the developer to fix the issue. If it's not solved within 12 hours then the commit will be backed out.
The freeze will happen the 18th of every month, taking the code available in erp/devel/main. So that the RM team and the developers will have 3 days to get all the commits from the 15th pass all the tests. There is no guarantee that commits done between the 15th and the 18th get into the release.
So the QA process beings the 19th 00:00 (night between 18th and 19th). And it finishes at the end of the month.
Developers: projects reintegrations into erp/devel/pi
Project reintegrations are prone to cause more issues than when there are no reintegrations. As a consequence these merges will be done in a specific date range: from the 22th till the 5th.
Developers should merge from erp/devel/pi into their branches very often (1-2 days) for their own good. But the reintegrations into erp/devel/pi must be done within this range.
Example by roles
Developers
- 18th of month A till 15th of month B: Developers do commits into /erp/devel/pi. All these commits will go into the month B release.
- 22nd of month A till 5th of month B: Developers reintegrate some projects into erp/devel/pi. All these projects will go into the month B release.
- 15th of month A till 18th of month A: Developers do commits into /erp/devel/pi. All these commits are not guaranteed to go into the month A release. It depends if they changesets of pi pass the tests.
So from a developer's point of view the release process starts the 22nd of month A and it ends the 15th of month B.
FAQ
- There are some months like May 2010 were the 15th is Saturday and the 18th Tuesday. What happens in those cases?
We believe that having fixed dates has more benefits than drawbacks. Variable dates depending on vacation days are difficult to remember and this is why we have avoided them. In principle the days will be taken strictly. But of course we are not machines and we will act with common sense. So as a general rules the dates with be taken as explained, and exceptions will be studied individually.