2. Brian Duff Principal Engineer JDeveloper Team Oracle Corporation

3. Team Development Best Practices With Oracle JDeveloper 10 g

4. Team Development Process  Change control  Day to day development  Testing and auditing  Building and releasing

5. 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

6. 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

7. JDeveloper Components

8. 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

9. 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

10. Parallel Development  Developers can work on tasks concurrently  Developers control when their workspace picks up changes  Developers can use micro-versioning within a task

12. 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

13. 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

14. 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

16. 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

18. Further Reading  Configuration Management Best Practices Wiki – http://www.cmwiki.com/ http://www.cmwiki.com/  Streamed Lines – http://cmcrossroads.com/bradapp/acme/branching/ 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 http://otn.oracle.com/oramag/webcolumns/2003/techar ticles/saikali_jdev.html

19. A Q & Q U E S T I O N S A N S W E R S