1 / 20

Brian Duff

Brian Duff. Principal Engineer JDeveloper Team Oracle Corporation. Team Development Best Practices. With Oracle JDeveloper 10 g. Team Development Process. Change control Day to day development Testing and auditing Building and releasing. Change Control. Essential for most teams Safety

mabyn
Download Presentation

Brian Duff

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Brian Duff Principal Engineer JDeveloper Team Oracle Corporation

  2. Team Development Best Practices With Oracle JDeveloper 10g

  3. Team Development Process • Change control • Day to day development • Testing and auditing • Building and releasing

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

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

  6. JDeveloper Components

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

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

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

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

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

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

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

  14. 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/techarticles/saikali_jdev.html

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

More Related