VIEWS: 131 PAGES: 20 POSTED ON: 8/2/2009
Oracle Best Practices
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
"Oracle Best Practices"