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