Source Control & Build

1
Source ControlBuild
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

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

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

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!

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

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

9
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

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

11
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

12
Example
13
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

14
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

15
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

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

17
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