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