Oracle Best Practices

Document Sample
Oracle Best Practices Powered By Docstoc
					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
–

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

http://www.cmwiki.com/ http://cmcrossroads.com/bradapp/acme/branching/

 Streamed Lines
–

 Ed Saikali’s J2EE Environment Article, OTN
–

http://otn.oracle.com/oramag/webcolumns/2003/techar ticles/saikali_jdev.html

QUESTIONS ANSWERS


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:131
posted:8/2/2009
language:English
pages:20
Description: Oracle Best Practices