Brian Duff Principal Engineer JDeveloper Team Oracle Corporation

Team Development Best Practices With Oracle JDeveloper 10 g

Team Development Process  Change control  Day to day development  Testing and auditing  Building and releasing

Change Control  Essential for most teams – Safety – Accountability – Flexibility  Use version control software – CVS, Oracle SCM, ClearCase, SourceSafe  JDeveloper team uses ClearCase – Moving to Oracle SCM in next twelve months

Components  Main division of a product  Should have well defined dependencies  Organize for future growth  Don’t be afraid to reorganize as they grow – Helps to have a version control system that makes this easy

JDeveloper Components

Files  Logically structured – Primary organization by type or subcomponent – Use “parallel source tree” pattern for unit testing  Version control almost everything  Derived objects – Usually better not to version control – Can use a derived object cache in large products

JDeveloper Files  A bit messy…  Newer components (e.g. adfc_modelers) have a more organized internal structure  8,990.java files in “java”  2.2M Lines of code

Parallel Development  Developers can work on tasks concurrently  Developers control when their workspace picks up changes  Developers can use micro-versioning within a task

Unit Testing  Run unit tests before checking in  Essential part of refactoring – Refactoring without unit testing is just “moving stuff around” – Only way to prove that refactoring is just reorganizing code without altering functionality  Important metric of tip quality for a team – Automate unit testing after each check in

Code Auditing and Metrics  Use a coding standard – Structural changes can be distracting when comparing files – Developers have a natural aversion to changing messy files (including large files)  Automate auditing and metrics – After each check in, or during builds  Make it easy for developers to audit

Building Code  Build frequently and automatically – After each check in is ideal  Developers should be able to verify they won’t break the build by checking in – Use a build tool such as ant or make – Version control third party libraries  Label successful builds – Any successful build should be reproducible – Provides a branch point for release branching

JDeveloper Build System  Automated system using Java, JMS, EJB  Builds several releases of the product at once in parallel – Multiple “workhorse” build machines – A single controller & scheduler – Highly parallel, e.g. debug build happens at same time as nondebug build  After build, check in comments are mailed to team

Further Reading  Configuration Management Best Practices Wiki –  Streamed Lines –  Ed Saikali’s J2EE Environment Article, OTN – ticles/saikali_jdev.html ticles/saikali_jdev.html

A Q & Q U E S T I O N S A N S W E R S