Software Configuration Management

1. Software Configuration Management William W. McMillan 21 March 2013

2. Goals of Configuration Management • Know state of system. • Support quality standards: • Documentation • Regression testing • Work efficiently. • Minimize frustration. • Archive project versions. • Facilitate and control change process. • Deliver versions of system to users.

3. Included in Configuration Management • Common code storage. • Way to check out code and check back in. • Way to merge modules changed by multiple authors. • Assignment of version identifiers. • Record of component versions included in system versions. • Facilities to build system.

4. Included in Configuration Management • Testing and reporting facilities. • Method to request and approve changes. • Change history. • Release planning.

5. What examples can give you give from your own background where configuration management was a challenge?

6. Version Control • Systems are composed of many interrelated modules. • Team of software developers required. • Members work on different parts and some common parts. • Need “master” copies of modules, e.g., on server. • Developers check out modules and work in own workspace. • Check modified code back in.

7. What tools exist to support version control?What problems can arise in their use?

8. Version Control • Changes made might be stored as “deltas”: • List of changes made by developer. • Conflicts if more than one updated version checked in of same module. • Might have to resolve manually. • System version defined as collection of specific versions of components. E.g., • Ver. 1.0 consists of H 1.7, J 2.0, K 1.3, and imports Q2 and Q5

9. System Builds • Version control specifies components. • Build script, configuration spec., or manifest specifies dependencies and inclusions. • Build server compiles where it needs to and assembles executable. • Target system might be different platform. • Tests run automatically. • Reports and documentation produced.

10. What can go wrong in a system build?

11. System Releases • New versions add functionality, • … correct errors, • … improve security, • … adapt to new environments (like OS), • … improve usability and style, • … work better with new tech (like mobile, XML), • … make use of new hardware features (like touch screen, faster external connections).

12. Give examples of changes across versions of real software products.

13. What risks are there in releasing a new system version?

14. System Releases • Need careful definition of component versions included. • Define changes in deployment needs. • Consider pluses and minuses of changed styles, formats, and functions. • Users will do cost-benefit analysis before adopting. • Keep lookout for open-source or low-cost competition. • E.g., IBM-PC Pascal compiler vs. Turbo Pascal

15. What are some rules of thumb to guide release management?

16. Change Management • New requirement: • Function, data • Performance issue or resource consumption • Interface • Security,… • Corrected requirement: • We got something wrong in the requirements analysis. • Bug report: • We got something wrong in design or implementation.

17. What has been your experience in submitting bug reports?

18. Change Management • Resource intensive. (Why?) • Changes across a host of artifacts. (Which?) • If things frequently shake off the shelves when a change is made … ? • Process needs to be controlled, with defined and documented authorization chain. • Need as formal a way to request a change as possible.

19. List some items you would include in a change request web form.Would a bug report be a different form?