More RUP and Configuration Management

CS3300Fall 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 use cases, gather requirements, evaluate feasibility

•Earlier 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 – design meets requirements, implementation meets design

•Reporting – 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 Physical Audits

•Baseline configurations

•Defect counts and reports against CI

•Build report: list all files and versions used to build a specific version of the product

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 problems

•Check artifacts are compatible

•Create 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 v32

•setup.sql v31

•MyServlet.java v89

•build.xml v43

•logo.png v1

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 check-in; 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 (probably not applicable with git)

•Branch on 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 early and often or risk complex merge

•Get 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 everything an owner

•Use 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.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html