brian duff principal engineer jdeveloper team oracle corporation
TRANSCRIPT
Brian DuffPrincipal EngineerJDeveloper TeamOracle Corporation
Team Development Best Practices
With Oracle JDeveloper 10g
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– http://www.cmwiki.com/
Streamed Lines– http://cmcrossroads.com/bradapp/acme/branching/
Ed Saikali’s J2EE Environment Article, OTN– http://otn.oracle.com/oramag/webcolumns/2003/techar
ticles/saikali_jdev.html
AQ&Q U E S T I O N SQ U E S T I O N S
A N S W E R SA N S W E R S