Source Control

1
Source ControlBuild
CSC444F'07
Lecture 5
1
2
Source Control

• THE most important tool for commercial software
  development.
  
• Source
• as opposed to generated intermediate or final
  files
  
• code docs anything else
• Maintains a central copy of version-controlled
  files
  
• the depot or repo
• Server-class hardware
• Clients
• sync-out
• change locally
• check-in
• Want
• atomic check-in
• efficient file storage
• low network use
• meta-data

CSC444F'07
Lecture 5
2
3
Want Powerful Branch / Merge

• Must branch 1000s of files at once.
• Should be efficient
• Should use COW
• Imagine find and fix a bug in file,v3 to generate
  file,v4
  
• Tools required to analyze the delta and
  automatically suggest an appropriate change to
  branch/file,v2
  
• Method 1 use file,v3, file,v4 and
  branch/file,v2
  
• Method 2 also use file,v1 and all other changes

?
merge bug fix ?
?
CSC444F'07
Lecture 5
3
4
Want Powerful Labeling

• Allows for a set of files, each at their own
  revision to be labeled (e.g., as R3.2.3)
  
• Want to sync to a label
• Want to retroactively branch at a label

CSC444F'07
Lecture 5
4
5
Uses For Source Control

• Repository
• always know where to find the most up-to-date
  versions of any files
  
• Structure
• Structure of depot defines module structure of
  software
  
• History
• Complete history of changes who, what, when, and
  how
  
• good for tracking down tough bugs
• good for discovering how code got to be the way
  it is
  
• Control
• Management can control what goes into the source
• Can see the changes / review them
• Can apply check-in policies
• Collaboration
• can sync to latest
• can choose not to sync while working
• a sub-group can stay in sync
• Multiple Maintenance Streams
• enabled via branch merge
• Reproducible System State

CSC444F'07
Lecture 5
5
6
Coder / Build Team Communications

• Want a hard and fast rule
• nothing ever gets shipped without
• coder checks in
• build team checks out
• Counter-example
• in a very tense moment, the coder has on her
  desktop the dll that will solve the customers
  problem
  
• temptation to just ship it to them
• say they do
• after 24 hrs straight, coder goes home
• coder comes back, continues to make changes to
  the file, then checks it in
  
• 1 week later customer has a similar problem
• try to reproduce, cannot
• try to go back to customers exact source code
• cannot!

CSC444F'07
Lecture 5
6
7
Codeline Policy

• To use a sophisticated sccs must establish
  codeline policies.
  
• Codeline policy
• specifies the conventions whereby the sccs is
  used to maintain multiple code streams
  
• specifies the rules regarding who can check
  things in, when, and what kinds of things.
  
• No one codeline policy
• Heres mine
• main
• maintenance
• shipping
• private

CSC444F'07
Lecture 5
7
8
Main Codeline

• Consistently used for ongoing development, across
  all releases
  
• Any developer may check-in changes
• The only codeline into which new features are
  coded
  
• and only at certain times
• between fork and dcut
• Defect corrections are coded in at any time
• all defect corrections must be coded here
• of any priority
• except when management overrides
• When sufficiently stable after dcut, and when new
  feature work must begin on the next release
  
• a maintenance codeline is branched off the main
  codeline
  
• new feature work may then begin again in main.
• timing of this is critical
• too soon fix too many defects in one extra
  place
  
• too late new feature work goes in private
  codelines that do not incorporate defect
  corrections an awkward, time-consuming merge
  later

CSC444F'07
Lecture 5
8
9
Example
main
ongoing
CSC444F'07
Lecture 5
9
10
Maintenance Codelines

• Branched from main when getting ready to start
  new features on the next release
  
• Only defect corrections
• All defect corrections into this codeline if
  active and not retired
  
• Any developer may check-in
• As point releases get closer and recede, codeline
  policy for defect priority changes
  
• only higher priority defects as point release
  gets close
  
• any priority defect after shipping codeline is
  branched

CSC444F'07
Lecture 5
10
11
Example
main
maintenance R1
X
retired
maintenance R2
maintenance R3
active
ongoing
active
CSC444F'07
Lecture 5
11
12
Shipping Codelines

• Branched from an active maintenance codeline a
  day or two before a point release is scheduled to
  go out.
  
• Only build team members may check-in changes
• no developers allowed
• dev team member will fix in main and maintenance
• build team member will pull the fix from
  maintenance and integrate into shipping.
  
• Developer will look over their shoulder
  anxiously!
  
• Only the highest priority, most critical, last
  minute, defect corrections allowed into this
  codeline
  
• Codeline required to promote stability
  immediately before a shipment
  
• right before ship, a lot of work has gone into
  validating the build
  
• do not want to negate that work for the sake of
  low priority fixes
  
• may never get it out!

CSC444F'07
Lecture 5
12
13
Example
main
maintenance R1
X
retired
maintenance R2
maintenance R3
shipping R2.2
R2.2.a
active
ongoing
active
CSC444F'07
Lecture 5
13
14
Private Codeline

• Owned by an individual or a sub-group of
  developers
  
• Free to check in new features
• Free to, but not required to, check in defect
  corrections
  
• May be only a part of the source
• the other codelines are the whole source
• used for feature work occurring outside of
  fork-dcut
  
• will eventually be merged back into main

CSC444F'07
Lecture 5
14
15
Example
CSC444F'07
Lecture 5
15
16
Builds Installs

• Build
• running build tools against the source files to
  create
  
• executables
• other release support files (e.g., static
  database files, conf files, .)
  
• end result
• set of files that may be conveniently used to run
  the app
  
• Nest step install
• starts with the built files installer sources
• results in an installer image
• typically burned onto optical media or prepd for
  download
  
• one click install / de-install by end-users
• either
• complete releases
• patches that bring the software from one release
  to a higher one
  
• All files used to support build/install must be
  in source code control

CSC444F'07
Lecture 5
16
17
Automation

• As few manual steps a possible in build or
  install image creation
  
• Creates exposure
• single individuals
• can mitigate via documentation, but gets out of
  date fast and no guarantees of accuracy
  
• should document build steps in a script that is
  used to build!
  
• Manual steps are error prone
• lots of details to consider
• do no want to mix up files from different
  codelines
  
• introduces last-minute, untested-for errors
• Consistent builds
• developers and qa use same build / install steps
• eliminates problems due to inconsistent buidls

CSC444F'07
Lecture 5
17
18
Development Builds

• A full install is too cumbersome for coders /
  testers to deal with all the time
  
• Therefore use a tiered approach
• tier 1 dev debug build that includes a mini
  dev debug install.
  
• tier 2 dev release build that includes a mini
  dev release install.
  
• tier 3 production build that includes a full
  production install.
  
• Dev builds have lots of debug info turned on
• never shipped because inefficient
• if bug manifests in dev build, generally easy to
  track down and fix
  
• if not, then will in a dev release build
• same as dev debug build, but with certain debug
  switches turned off
  
• still not a production build
• If not in dev release then must resort to
  cumbersome full production
  
• will usually be an installer problem
• Be builds are very convenient to work with
• change code, push button to build/install, test
• Developers will maintain the dev build / install
  scripts
  
• QA will use dev release builds / install to test
  on
  
• Automated regression testing also

CSC444F'07
Lecture 5
18
19
Production Builds

• Step 1 is usually a dev release build
• Carries on to create an installer image
• Carries on to create a CD ISO image or
  downloadable image
  
• These are shipped out the door
• a final manual release checklist is gone through
• auto-testing is good, but want humans involved
  also!
  
• Company maintains a list of all future scheduled
  production builds
  
• gold builds intended to go out to customers
• intermediate builds leading up to the gold
• List stored in a workflow management system
• processes followed
• data recorded
• Weekly company meeting to discuss status and
  priorities on production builds
  
• what points, what patches, what versions,

CSC444F'07
Lecture 5
19
20
Automated Builds

• Coders should integrate their work as often as
  possible with that of other coders.
  
• continuous integration
• If working on a stable base for a while
  (necessary to preserve sanity)
  
• before checking in changes, check out all others
  changes, build and do one last test.
  
• race condition
• Also, tested on dev platform, not on all versions
  may have broken a different version
  
• Nightly automated builds
• scripted process fires off
• deletes all previous source, intermediate, and
  final files
  
• returns system to pre-install state (e.g., delete
  any registry entries)
  
• does a complete check out of latest sources
• runs a build records results in a database
• errors and warnings should be at 0
• does an install records results in a database
• sees if app starts up records results in a
  database
  
• across all supported versions on all platforms
• across all active codelines
• Build a web app to report on database

CSC444F'07
Lecture 5
20