Difference between revisions of "SoC geeklog2 continuous builds"
(→Further Reading) |
m (outdated - added link to current list) |
||
| Line 1: | Line 1: | ||
| − | + | This is an old project idea for our (now defunct) sister project, AptitudeCMS (aka Geeklog 2). This project outline is therefore only of historical interest and you can not apply for this project in future instances of the Google Summer of Code. Please see our [[Google Summer of Code|ideas page]] for a current list of GSoC project ideas. | |
| + | |||
== Incentive == | == Incentive == | ||
Latest revision as of 20:44, 4 March 2010
This is an old project idea for our (now defunct) sister project, AptitudeCMS (aka Geeklog 2). This project outline is therefore only of historical interest and you can not apply for this project in future instances of the Google Summer of Code. Please see our ideas page for a current list of GSoC project ideas.
Incentive
Geeklog 2 is a sophisticated system. A balance between rich features and ease of use must be struck which places a high emphasis on quality. A big part of establishing quality is to implement testing as a core part of the project. Additionally, there are key parts to the Geeklog 2 that require special processing such as building the models (the "M" part of MVC). Geeklog 2 makes heavy use of Propel, an object relational mapper, to limit the amount of SQL a developer has to write and enhancements to Propel make it possible to isolate all SQL from the rest of the system.
Because of these and a number of other complexities having a system in place that polls SVN for changes, checks out the code, runs unit tests and produces builds (i.e. PEAR-installable packages) would take some of the time and complexity with getting a new version out and it forces testing to be an integral part of the system.
Objective
- Research Open Source build tools such as Phing, Xinc and Cruise Control to provide continuous builds
- Establish the actual build process including
- Checking out code from SVN
- Running Unit tests
- Running regression tests
- Upon test failures notification of the development team
- Upon successful testing tagging the code and doing full builds
Goals
- Define the requirements we have of a build tool
- Systematically compare products available
- Define our exact build process
- Pick the best tool
- Implement it against the process we defined
Level of Difficulty
Hard
Continuous builds in PHP is a relatively new concept. A good candidate must be willing to push forward and trudge new ground in a developing area within the PHP community.
