Build Cycle Lecture II EEE493 2000

1
Build Cycle - Lecture II EEE493 2000
Royal Military College of Canada Electrical and
Computer Engineering

• Major Greg Phillips
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

Dr. Scott Knight knight-s_at_rmc.ca 1-613-541-6000
ext. 6190
2
Refs

• Pressman, R.S., Software Engineering a
  Practitioners Approach 5th Ed., McGraw-Hill,
  2001, Section 18.4
• http//www.construx.com/survivalguide/dailybuildpr
  oc.htm
• http//www.extremeprogramming.org

3
Teaching Points

• Integration Strategies
• Software Release Strategy
• Patch Releases

4
Review

• In Rational build cycle what is a subsystem, view
  and configuration?
• Why do we need these different build spaces
  (developer, integration, build, etc.)?

5
Subsystems, Views and Configurations
Bobs personal configuration
Messaging subsystem
Messaging
rev.1.wrk
SimObject
stable.1.rel
SimObject subsystem
Build configuration
Messaging
rev.1.wrk
SimObject
stable.1.rel
6
Configurations
Integration Configuration
Developer Configurations
System Release Configurations
Build Configuration
Baseline Configuration
7
Daily Build and Smoke Test Cycle

• What is a smoke test?
• A series of tests designed to expose errors that
  will keep the build from properly performing its
  function
• The intent should be to uncover show stopper
  errors that have the highest likelihood of
  throwing the project behind schedule
• The smoke test should exercise the entire system
  from end to end (does not have to be exhaustive
  but should expose major problems)
• The smoke test should be thorough enough that if
  the build passes, you can assume it is stable
  enough to be tested more thoroughly

8
Daily Build and Smoke Test Cycle
Developer Build
Developer Smoke Test
Merge
Check In
Fix
Daily Smoke Test
Develop
Daily Build
9
Merge code changes

• The developer compares his or her private copy of
  the source files with the master source files,
  checking for conflicts and inconsistencies
  between recent changes made by other developers
  and the new or revised code to be added.
• The developer then merges his or her code changes
  with the master source files. Merging is usually
  supported by automated source code control tools,
  which warns the developer of any inconsistencies.

10
Build and test a private build

• The developer builds and tests a private release
  to be sure that the newly implemented feature
  still works as expected.

11
Execute the smoke test

• The developer runs the current smoke test against
  the private build to be sure the new code wont
  break the build.

12
Check in

• The developer checks his or her private copies of
  the source code into the master source files.
• Some projects establish times during which new
  code can and cant be added to the daily build
  for example, new code must be added no later than
  500 p.m. and no earlier than 700 am.

13
Generate the daily build

• The build team (or build person) generates a
  complete build of the software from the master
  sources.

14
Run the smoke test

• The build team runs the smoke test to evaluate
  whether the build is stable enough to be tested.

15
Fix any problems immediately!

• If the build team discovers any errors that
  prevent the build from being tested (that break
  the build), it notifies the developer who checked
  in the code that broke the build, and that
  developer fixes the problem immediately.
• Fixing the build is the projects top priority.

16
Extreme Programming
17
Parallel Integration

• With parallel integration of source code modules
  there is a combination of source code which has
  not been tested together before
• Numerous integration problems arise without
  detection
• There is no clear cut latest version
• This applies not only to the source code but the
  unit test suite which must verify the source code
  correctness.

18
Sequential Integration

• Strictly sequential (or single threaded)
  integration by the developers themselves in
  combination with collective code ownership
• All source code is released to the source code
  safe or repository by taking turns
• only one development pair integrates, tests and
  releases changes to the source code repository at
  any given moment
• All code must pass all unit tests before it is
  released

19
Integrate Often

• Developers should be integrating and releasing
  code into the code repository every few hours
• In any case never hold onto changes for more than
  a day
• Everyone needs to work with the latest version
• Changes should not be made to obsolete code
  causing integration head aches.

20
Next ClassInspections