Release Management/Continuous Integration Vision
 | This document is still a work in progress. It may contain inaccuracies or errors. |
This is a page which describes the current status of Continuous Integration aka CI and what are we working now to make it more useful for organization/business.
Contents |
High Level Values of CI
CI helps you identify and handle risks. It will make things easier to evaluate and create report on the current status of project based on evidence.
- Reduce Risks by running continious unit tests, integration tests
- Produce deployable software at any time and at any place
- Enhances project(s) visibility (especially when we have lot of choose from)
- Helps improve confidence in the software product from the development team
How does CI reduce risks
- Defects detected and reported (integration with issue tracker)
- We can measure the health of the software (looking at failed build count)
- Reduce assumption that it will work safe in customer location by continious testing in clean environments.
Why should we CI, and reduce repetitive processes
- Reduce human mistakes.
- Less repetitive works means we can engage in better productive work.
CI helps generate deployable software
- Quickly able to take decision based on recent build status.
- Frequeny integration helps us understand sucess, failure & quality parameters
- This means Sale / Marketing team can be confident of delivering a usable software.
Approach We take
Let's aim for step-by-step growth. Lets not try to automate everything. We need to consider the cost of automation as well. An iterative approach is a good approach. Just like refactoring a lot of code at once isn't the best approach when writing software, but refactoring is required. Like ways we need automation but lets do it step by step. A possible steps for automation is
- Get it to work first
- Get developers using it,
- Add other automated processes as needed based on the project risks.
CI and YOU, ask yourself
On average, is everyone on your team committing code at least once a day?
- What percentage of each day's integration builds is successful (that is, the most recent build run has passed)?
- Is everyone on your team running a private build before committing to the repository so that integration errors are reduced?
- Have you scripted your builds to fail if any of your tests or inspections fail?
- Is a broken integration build a priority to fix on your projects?
- Do you avoid getting the latest code from the version control system when there is a broken build?
- How often do you consider adding automated processes to your build and CI system—on a continuous or even periodic basis?
We are ready
The above has proved to be a good success in terms of error detection in recent MP releases. I would say our foundation for builds.openbravo.com is ready and now we are ready to scale up. In terms of CI, scaling up means more and more automation and in theory this is nothing but usable software after every commit. The key work for automation is this "I Build So Consistent"
| I - Identify what to automate | Developer(s) can get assistance from platform or from RM team |
| B - Build | " |
| S - Share | http://wiki.openbravo.com/wiki/Mercurial_Manual_for_Openbravo_Developers |
| C - Continuous | This is job of CI tool (in our case builds.openbravo.com) |
Road Map
Milestone 0
Starting Date: April 2009 Ending Date: June 2009
MileStone 1
Starting Date: July 2009 Ending Date: Aug 2009
MileStone 2
Starting Date: Sep 2009 Ending Date: Oct 31 2009
| Automatically promote code from pi to main | |
| Create obx and make it available for partners | |
| Create upgrade test which checks upgrade process from the last released MP to latest ready to be released obx. | |
| Latest branch available as context for developers to test the functionality (tecnicia14) |
MileStone 3
Starting Date: January 19th 2010 Ending Date: March 31st 2010
| HIGH LEVEL TASK. IMPLEMENT CI FRAMEWORK FOR MODULES DEVELOPMENT - THIS MEANS SIMILAR TECHNOLOGIES AND TOOLS THAT WE HAVE FOR THE CORE ERP (WHICH IS ALSO A MODULE :-)) DEVELOPMENT PROCESS FOR ALL OTHER EXTENSION MODULES. | |
| Build farm | |
| Auto-tests farm: sanity checks (descriptions and so on), installation / uninstallation checks against various Openbravo configurations (Oracle, PostgreSQL, etc.), modules co-existence checks, functional checks. | |
| Publication farm. | |
| Not in the scope but to take care about during the system design - in future to give to Partners / Module developers possibility to use our modules development CI framework. |
MileStone 4
Starting Date: April 1st 2010 Ending Date: May 31st 2010
| HIGH LEVEL TASK. MAKE SURE THAT MODULES, PUBLISHED IN THE CR, ARE WORKING. | |
| Check modules (builds and tests, taking them from the previous stage ) before publishing. | |
| Check published modules (with a new MPs, new dependencies). Notify authors, mark modules with a special status visible for end-users (Forge, Exchange, MMC). | |
| "Certified" by Openbravo for registered modules (modules which passed different levels of checks, on top could be functional testing) with a reflection of this status in the Forge, Exchange, MMC. |
MileStone 5
Starting Date: January 1st 2010 Ending Date: February 28th 2010
| Unit tests | |
| Coding standards | |
| Performance test 2.50 |
MileStone (not scheduled)
Starting Date: March 1st 2010 Ending Date:
| ??? Test that modules can co-exist ??? | |
| build the last released minor version and update until the last commit then build | |
| build the last former major version (2.40 MPx) and update until last commit (pi) then build | |
| promote ant diagnostic | |
| Multiple jdk support (sun jdk, open jdk, etc) | |
| Multiple environment test (windows, linux, solaris, freebsd) | |
| Automated maintaince release or MP's | |
| Automated appliance creation (OPS) | |
| Latest build of availalbe as Amazon Machine Image (AMI) | |
| Automated virtual image creation (XEN, Vmware, virtualbox) | |
| Openbravo ERP Live CD (based on knoppix, ubuntu) | |
| multiple web container (tomcat, jetty, websphere...) | |
| test the packages (.deb) for ubuntu, or gentoo | |
| ??? Test that the modules work functionally ??? |
What is that you need to be doing ?
Look at the above mentioned test(s) and new features that we are planning to add.
See if its gonna value add YOUR work.
If NOT please WRITE back to sree {at} openbravo {dot} com or staff.rm {at} openbravo {dot} com with your comments / suggestion/ feedback.
If there are no suggestion, a reply with "you guys r0cks ! " will be good motivation for the team. :) Insert non-formatted text here