Oracle Best Practices by isbangee

VIEWS: 131 PAGES: 20

More Info
									Brian Duff
Principal Engineer JDeveloper Team Oracle 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 CVS, Oracle SCM, ClearCase, SourceSafe Moving to Oracle SCM in next twelve months

 Use version control software

 JDeveloper team uses ClearCase

    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

 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 Automate unit testing after each check in

 Important metric of tip quality for a team

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) After each check in, or during builds

 Automate auditing and metrics

 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 Any successful build should be reproducible Provides a branch point for release branching

 Label successful builds
– –

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


To top