Openbravo ERP 2.50 has a time based release plan. This helps us get bug fixes and new features into our user’s hands more quickly and improve our planning process.
Up to now we’ve been releasing Maintenance Packs on a monthly basis. However we have detected some improvement areas, mainly two:
- We want to release like a clock: same time, same day, every month. Everyone gets benefited by this:
- End users appreciate knowing the release dates without even reading a release calendar. They simply know that they’ll have an update at the end of every month.
- Our engineering team can organize more effectively: developers, QA, Support, Release Management.
- Developers should know what commits they push go into what release. This way they can organize their work more efficiently.
So let’s start! We already have the list of desired improvements and we know that we need to set the key dates. So first we need to identify the different kind of events involved in the development process:
- Regular commits (e.g. bugfixes or small features).
- Large project merges (e.g. a new large feature).
- QA automatic tests.
- Feature freeze for the release.
- Release packaging.
- QA manual tests.
- Publish the release.
Now we need to set some dates and deadlines. The QA manual work – bug found – fix it loop lasts around 10 days. So the freeze and packaging should be before the 20th. And we want to provide a guarantee to developers, so that they know which commits go into what release. Here’s a proposal:
- All the commits pushed before the 15th of a month will go into that month’s release. We’ll make sure all the tests are passed, working together with the developers in case there’s a failure.
- We’ll freeze the code the 18th and start the packaging right after this moment. This means we have 3 days to make the code pass all the automatic test suite. It should be more than enough. It also means that commits pushed between the 15th and the 18th might go into that month’s release. If it passes the tests of course.
- From that moment on QA can start the manual work. If they find issues the affected developer will work on the fix and they’ll iterate on this process till QA happy is happy with the result.
- Afterwards the Release Management team can publish the release.
And last but not least, project merges tend to create instabilities in the code main line, compared to having no reintegrations at all. So taking this into account the project merges must be done a specific time frame: from the 22nd of one month until the 5th of the next one. So that we give it enough room (10 days) to get the code stable for the freeze time.
We can see these policies summarized in the following graph:
Improving a release process is usually an evolution, not a revolution. And I believe this is the first step towards better timely releases.
Tagged: Release process, Releases