slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Brian Duff PowerPoint Presentation
Download Presentation
Brian Duff

Loading in 2 Seconds...

play fullscreen
1 / 20

Brian Duff - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Brian Duff' - mabyn

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
brian duff

Brian Duff

Principal Engineer

JDeveloper Team

Oracle Corporation

team development best practices

Team Development Best Practices

With Oracle JDeveloper 10g

team development process
Team Development Process
  • Change control
  • Day to day development
  • Testing and auditing
  • Building and releasing
change control
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
  • 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
  • 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
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
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
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
code auditing and metrics
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
building code
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
jdeveloper build system
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
Further Reading
  • Configuration Management Best Practices Wiki
  • Streamed Lines
  • Ed Saikali’s J2EE Environment Article, OTN