Oracle ADF Architecture TV - Development - Version Control


Real World ADF Design & Architecture Principles

Version Control

15th Feb 2013 v1.0


Learning Objectives

•  At the end of this module you should be able to:

– Have a basic understanding of SVN and JDev features –  Identify different SVN installation types – Consider different SVN repository layouts suitable for ADF

projects – Acknowledge that you must devise a SVN branching strategy

Image: imagerymajestic/ FreeDigitalPhotos.net


Program Agenda

•  Subversion Introduction •  Subversion Architecture •  Subversion Repository Layout •  Subversion vs ADF Architecture

– Single Workspace Layout – Multiple Workspace Layout

•  Subversion Best Practices •  Git


Subversion Introduction •  Free open-source version control system (VCS) •  Java EE enterprise defacto VCS •  Allow teams to version files, directories, source code •  Not a collaboration tool

•  Single shared enterprise repository •  Uses efficient delta solution for tracking file changes •  Accessed via file:// svn:// http:// https://


Program Agenda




7 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 7 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Subversion Architecture

Image: SVN Book

Image Attributed under CC2.0 to Subversion Redbean: http://svnbook.red-bean.com/


SVN JDeveloper Features

•  SVN Client (SVNKit) •  Create repositories (local only) •  Versioning Navigator (repository browser) •  Pending changes window •  SVN commands: check-out, commit, merge etc •  IDE features: visual file diff, history, visual merge


Program Agenda





Subversion Repository Layout

•  SVN repository mimics a file system: directories and files •  What can you store in a file system?: SVN is flexible by design •  However there is a set of conventions:

<RootDirectory>

/trunk Current development code /tags Snapshots of code /branches Use is variable (& debatable!)


Program Agenda





Subversion vs ADF Architecture

•  ADF allows applications to be: –  Self contained in one workspace –  Separated across multiple workspaces

•  How to layout the SVN repository?

Single Workspace

Multiple Workspaces

#1 SVN First

#2 Domain First


Single Workspace SVN Layout

One directory maps to JDev

workspace name Standard

SVN directories

JDev workspace

code

Branches/ tags also contain

workspace code


Branches/tags reflect same structure

Each JDev workspace

Further logical

directories if needed Each JDev

workspace code

Standard SVN

directories at root level

Multiple Workspace SVN Layout #1


Multiple Workspace SVN Layout #1 •  Advantages

–  Checkout at trunk (or unique tag/branch) results in all source code checked out (though you can still check out individual workspaces)

–  All versioned together, little library dependency management needed, less requirement on clear team communications

–  No cross version dependencies / all or nothing build and release –  Suitable for single uber apps where all parts roll out as 1 release

•  Disadvantages –  No separate versioning –  With multiple applications, all must roll out in an update/release even

though only one may have changed


Each JDev workspace

code

Standard SVN

directories at workspace

level

Each JDev workspace

Logical directories

at root level


Branches/ tags only contain

workspace code



•  Advantages –  Can version each workspace separately –  Suitable for multiple applications requiring separate release cycles

•  Disadvantages –  Have to track version dependencies across applications –  Build and dependency management tools required –  Team communications need to be clear –  Messy release cycles


Program Agenda





Subversion Best Practices

•  Define a standard checkout location for developer PCs •  SVN working copy directory structures should match SVN directory

structures exactly –  Easier for build scripts –  Easier for developers –  Easier to document

•  Developers who check out multiple copies of an application need to handle the unique directory names themselves


Subversion Branching Strategies •  Allows multiple teams or application versions to be developed consecutively •  You need to define your own branching strategy – one size doesn't fit all •  Start with a simple branching strategy then evolve it when required

•  Attempting to mimic dev/test/prod as branches doesn’t work –  Overtime you will have many different dev/test/prod releases

•  Some known branching strategies –  Branch per feature –  Branch per iteration/release –  Branch per team


Subversion Branch/Release Strategies •  Use a formal numbering scheme (e.g. 1.2, 1.3, 2.0 etc)

–  Perpendicular to existing software dev/test/prod rollouts –  What designates a release is at your discretion –  You may need a "development" and "user/customer" release numbering

scheme ... do users need to know you're at release 4.2.3.54.1234?

•  Guidelines for release/branching naming schemes –  Each name must be unique –  Devise a naming scheme that shows progression –  Don’t try and invent the perfect naming scheme

•  If Oracle, Microsoft and Apple can't get it perfect, neither will you!


Program Agenda





Git

•  Popular contemporary VCS •  Seen as replacement for SVN •  Not widely adopted in enterprises (yet)

•  Decentralized repository model –  1 or more central repositories –  Developers can create 1 or more local repositories (~branch) –  Developers responsible for merging repositories

•  Required for Oracle’s Developer Cloud Services


What do you think the pros and cons of a

decentralized repository model would be?

Image: imagerymajestic/ FreeDigitalPhotos.net


Is Git Suitable for the Enterprise?

•  Or more accurately, is the Enterprise ready for Git?

•  10 things I hate about Git http://bit.ly/PQfT3e •  Using Git in the Enterprise http://bit.ly/P6PH8Q •  Git based source control in the Enterprise http://bit.ly/MVskur •  Subversion 1.8 Released But Will You Still Use Git? http://bit.ly/12YWcmo

•  Can you trust your developers to merge code? •  Can you trust your developers to backup their repository?

•  But do all of your developers have access to the central SVN repository?


Conclusion

•  Version control is not a nice to have, it is critical to a well oiled software development effort

•  Your goal is to create an "ADF factory" where version control rolls many different releases off the factory floor repeatedly & efficiently

•  The more effort you put in the more transparent & automatic it becomes •  Your SVN branching strategy needs careful consideration

–  Don't trust your developers –  Version control is tedious to them –  They'll devise an ad hoc mechanism with no thought to the future


Further Reading

•  Versioning applications in JDeveloper http://bit.ly/Slnf7i •  Branching and merging primer http://bit.ly/Vj6p8d •  Branching strategies #1 http://bit.ly/13iv6Vk •  Branching strategies #2 http://bit.ly/UNxrpU

Oracle ADF Architecture TV - Development - Version Control

Technology

Transcript of Oracle ADF Architecture TV - Development - Version Control