More RUP and Configuration
Management
CS3300
Fall 2015
Releases and Iterations
Release : an operational delivery for customer use. It may
version 0.01, but it is something the customer can run and get
business value out of.
•
Iteration: a short period that the team uses to develop a set of
use cases.
•
XP uses 1 week iterations and a “short” release schedule
For Example
Release 0.1 = Player login/registration and create a portfolio.
•
Release 0.2 = Player buy/sell stock, prices pulled from yahoo
•
Iteration 1 , 2, 3, 4 support Release 0.1
Iteration 5, 6, 7, 8 support Release 0.2
RUP
Uses longer iterations 4-6 weeks
•
Inception:
•
•Brainstorm
•Earlier
use cases, gather requirements, evaluate feasibility
iterations spend more time in this phase
•Release
planning
Elaboration:
•
•For use
cases supporting this iteration, detail them
•Develop
analysis diagrams and architecture
Final phases
Construction: Detailed design, coding and testing for the use
cases in this iteration
•
Transition: Deployment to customer site for Alpha/Beta testing
•
RUP does not specify processes for coding/testing. Design is
UML-centric
•
Software Configuration
Management (SCM)
Why have SCM/CCM
Simultaneous updates
•
Multiple developers
•
Multiple teams
•
Multiple sites
•
Multiple variants and versions
•
Multiple iterations and releases
•
Multiple projects
•
Multiple platforms
•
Communications between developers
•
Without some kind of control === CHAOS!!!
•
Configuration Management
Configuration identification
•
Configuration control
•
Configuration status accounting
•
Release management and delivery
•
This is normally documented in the SCM Plan
Identification
A unique identifier for each configuration item (CI)
•
A definition of the baseline
•
A version identification scheme
•
Baseline
A stable version against which error reports and change requests can
•
be filed.
A snapshot of versions of all the components.
•
•Informal
baseline: minimum control over access to CI, common repository
for development artifacts.
•Formal
baseline: official standard on which work is based. Only authorized
changes can be made to a formal baseline.
•
Three benefits of baselines:
•Reproducibility
– can go back in time and reproduce the exact software
product of a release.
•Traceability
•Reporting
– design meets requirements, implementation meets design
– compare one baseline against another.
Baseline
Once code is formally baselined, can be changed only through
ECP process.
•
Baseline code when in use at customer facility and bad changes
would cause real problems.
•
Not normally baselined (except informally) during early
development.
•
Might baseline your API formats early so that changes don’t
catch team by surprise.
•
Control
Record changes (Tool helps here)
•
Review change proposals/incident report (CP/IR) for baselined
code.
•
Set up Configuration Control Board.
•
Configuration Control Board
Reviews changes to the baseline configuration
•
•Incident
Report : Same as a bug report. Describes a problem. Developer
looks at problem and recommends a solution. CCB can approve, table, or
disapprove.
•Change
Request: New functionality needs to be added. This normally is
supported by an Impact Assessment. CCB approves this as either in-scope
(we absorb costs) or out of scope (customer pays more), table or reject.
•Impact Assessment:
Supports a change request. Studies the requirements
and impacts of a new feature on the code, documentation and tests.
Analysis of impact on schedule, labor and cost. Any viable alternatives are
also considered.
•Software
Change Notice: Records actual changes made to baseline to
support an IR or CR
Status Accounting
Measurements to check the state of the product
•
•Functional and
•Baseline
•Defect
Physical Audits
configurations
counts and reports against CI
•Build report:
the product
list all files and versions used to build a specific version of
Functional Audit
Verify that actual performance of the software CI complies with
the requirements
•
•Verify
that all change requests have been implemented
•Document discrepancies
•Establish
corrective actions
•Maps CI to
requirements
Physical Audit
Verify that artifacts baselined are the correct versions
•
•Create
a list of items under config mgmt (CM)
•Inspect items
under CM
•Check pending unresolved
•Check artifacts
•Create
problems
are compatible
a discrepancy list
•Check compiler
builds, library versions, etc. The physical audit is
everything involved in the development to get a repeatable product.
Release management and
Delivery
Maintain master copies of releases.
•
Safety-critical or Security-critical CI are protected.
•
Example:
Release 0.1:
•
•SDP
v1.0
•SRS
v1.12
•SDD
v1.01
•foo.php
v43
•index.html
•setup.sql
v32
v31
•MyServlet.java
•build.xml
•logo.png
v43
v1
v89
Release Management guides
Lehman’s law: If you add a lot of new functionality to a system in
a release, the next release will be limited to repairing problems
and fixing performance.
•
Release many need to fix major issues with code. Minor issues
are normally resolved via patches rather than a full release
•
Releases may be required after OS upgrades released.
•
Release Guides
Release may be required if competitors release new features.
•
Release may be required to meet a marketing promise
•
Release may be required to address customer change proposals.
•
Most common: Planned Release after set of iterations.
•
SCM Best Practices
Workspaces – where engineers edit code
•
•Don’t share
workspace
•
Single developer
•
Product build/release
•Don’t work outside
a managed workspace
•Don’t use
Jello views – files should change due to something you do,
not external events (don’t have symlinks into another workspace)
•Stay
in sync with the codeline/baseline
•Check-in often
Laura Wingerd, Perforce, High-Level Best Practices in SCM
SCM Best Practices
The Codeline/Baseline
•
•Give
each baseline a policy: how to document changes, criteria for
check-in, etc. For example:
Development codeline: interim code changes may be checked in; affected
components must be buildable.
•
Release codeline: software must build and pass regression tests before checkin; check-ins limited to bug fixes; no new features or functionality may be
checked in; after check-in, branch is frozen until entire QA cycle is completed.
•
Mainline: all components must compile and link, and pass regression tests;
completed, tested new features may be checked in.
•
Laura Wingerd, Perforce, High-Level Best Practices in SCM
SCM Practices
Codeline/Baseline continued
•
•Give
each codeline an owner. Need someone to answer questions
about policy
Use a mainline/trunk: a branch of the code that evolves forever.
The ultimate destination for most changes
•
Laura Wingerd, Perforce, High-Level Best Practices in SCM
SCM Practices
Branching: creation of variant codelines. Probably the most
problematic area
•
•Branch only when necessary
•Branch on
(probably not applicable with git)
incompatible policy (need different check-in procedures)
•Branch late.
Do as much testing and work on the mainline as possible
before branching
•Branch instead
of freeze.
Laura Wingerd, Perforce, High-Level Best Practices in SCM
SCM Practices
Change propagation: getting changes deployed across branches
•
•Make original
changes in branch that has evolved the least since
branching
•Propagate
•Get
early and often or risk complex merge
right person to do the merge (owner or person making changes)
Laura Wingerd, Perforce, High-Level Best Practices in SCM
SCM Practices
Build: Construct software from original source files.
•
• Source +
tools = product : do not require written procedures, sticky notes etc.
Use a build tool!
•Check-in all
original source. This includes the build files and resources.
Repeatable builds!
•Segregate
built objects from original: Make new directories for items created by
build. Do not pollute original directories in version control.
•Use
common build tools.
•Build often
•Keep build
logs and build outputs for future reference
Laura Wingerd, Perforce, High-Level Best Practices in SCM
SCM Practices
Process : Things related to SCM plan
•
•Track
change packages. For seeing project trends, a single file change
may not tell whole story. Want to know what other related files
changed with this one.
•Track
change package propogation. Which change packages have been
applied to branches, which are pending, which branches need packages
•Distinguish
change requests from change packages. What to do vs.
What was done
•Give
•Use
everything an owner
living documents
Laura Wingerd, Perforce, High-Level Best Practices in SCM
Agile SCM Practices
Avoid branches especially for customized versions. Use
configuration files and build scripts to support multiple
configurations.
•
Use a single repository to store all project artifacts.
•
Keep repository clean. Never check in broken code.
•
Iteration versions are ready for stakeholders
•
Release versions are production-ready.
•
Never share your sandbox (workspace)
•
Time travel : go back to an earlier revision to help track bug
sources.
•
Agile SCM Code Status
Broken: this only happens in your sandbox/workspace
•
Builds and passes all tests: All versions in repository are at this
level
•
Ready to demo to stakeholders: Version marked with “Iteration
X” tag
•
Ready to release to real users and customers: Version marked
with “Release Y” tag
•
Branching Strategies
Release Branches
•
Feature Branches
•
See SVN Redbook:
•
http://svnbook.redbean.com/en/1.5/svn.branchmerge.commonpatterns.html