Configuration Management

1. Configuration Management Aviva Dayan Arik Gendelman Pablo Galiana Seminar in Software Design - 2005/6

2. What is Configuration Management? • The control of changes made throughout the system lifecycle. • Allows changes to be evaluated before they are approved. • Considers interrelationships among system components. Configuration Management

3. Software Configuration Management • A software engineering discipline • Comprised of tools and techniques • used to manage change to software assets. • A set of activities to control change by: • identifying the products & establishing relationships • defining mechanisms for management, control, auditing and reporting on changes made. In short: “A methodology to control and manage a software development project.” Configuration Management

4. Why do we need SCM? • To manage: • Many people working on the same code. • Projects delivered in several releases (builds). • Rapid evolution of software and hardware. • Project surveillance: • i.e. project’s status, bugs, features, etc. • Concurrent support and development. • Stress time requirements of projects. Configuration Management

5. Goals of SCM • Configuration Control • Controlling product release and its updates. • Status Accounting • Recording and reporting components’ status. • Review • Ensuring completeness and consistency of all parts. • Build Management • Managing the build process and its tools. Configuration Management

6. Goals of SCM – cont. • Process Management • Ensuring adherence to the development process. • Environment Management • Managing the components that host our system. • Teamwork • Facilitate team interactions Configuration Management

7. SCM – How it is accomplished? All these goals are accomplished through Version control Management of multiple revisions of the same unit of information. Configuration Management

8. Version control • Commonly used in engineering and software development. • Changes identified by incrementing an associated number or letter code - “revision number”, or “revision level”. • Revision numbers (levels) are associated historically with the person making the change. Configuration Management

9. Vocabulary • Repository • A server where the files are stored. • Check-Out • copies a working copy from the repository • (the opposite of an import). • Change • A specific modification to a document under version control. • The granularity of the modification considered a change varies between version control systems. Configuration Management

10. Vocabulary – cont. • Change List • The set of changes made in a single commit. • A sequential view of the source code. • Commit or Check-in • Copy the changes on the local files to the directory. • (the VC software takes care of changes since the last synchronization). • Update • copies the changes that were made to the repository into your working directory. • (opposite of a commit). Configuration Management

11. Vocabulary – cont. • Merge / Integration • brings together (merges) concurrent changes into a unified revision. • Revision or version • one version in a chain of changes. • Conflict • Occurs when two changes are made by different parties to the same document or place within a document. • Resolve • The act of user intervention to address a conflict between different changes to the same document. Configuration Management

12. Version A Branch Version A.1 Branch Check Out Check In C A B Version B Branch Check Out D Merge E Check In Example CM Clients CM Server Trunk Machine A Machine B Configuration Management

13. History • CM systems save the files’ history. • Old versions can be viewed, compared, and downloaded. • New versions can be (irreversibly) replaced with old versions and ‘wiped off the map’. Configuration Management

14. Central repositories • Files are saved in a central file server. • Developers can view the files in the repository, through the use of filters. Configuration Management

15. Labels • Several files can be labeled together. • Allows : • Access to the label as a whole set of files. • Changes to the labeled files as a unit. • Useful for marking product releases. Configuration Management

16. Check-in • Copies a file into the database. • The version you see is (usually) the latest version that was checked in. • The old version is kept and can be accessed later. Configuration Management

17. Checkout • Copies the database file to your personal folder, and raises a flag on the database copy. • Need to check out before checking in. Configuration Management

18. Undo check out (uncheck-out) • The “undo checkout” command does just that – the file returns to the status it had before it was checked out. • This can be done even if changes have been made to the local copy – of course, these do not go into the database! Configuration Management

19. Versioning Models Lock-Modify-Unlock Solution: • Only one person can change a file at a time. • Example: VSS. Copy-Modify-Merge Solution: • Users modify private copies only - in parallel • Private copies are merged together into a new, final version. • Example: CVS, Subversion. Configuration Management

20. Problems With Locking • Administrative problems: • A user can lock a file and forget about it. • Time is wasted while others wait to edit the file. • Unnecessary serialization: • Different parts of a file don’t necessarily overlap. • E.g.: Alice works on the beginning of a file, Bob wants to edit the end of the same file. Configuration Management

21. Problems With Locking – cont. • False sense of security: • Let’s say Alice locks and edits file A, while Bob simultaneously locks and edits file B. • Let’s say A and B depend on one another, and the changes made to each are semantically incompatible. • Suddenly, A and B don't work together anymore. Configuration Management

22. A A A The Copy-Modify-Merge Solution Aviva and Arik both check out file A. Here, checkout has no locking effect – it’s just a local copy. Repository Read Read Configuration Management

23. A Arik Aviva The Copy-Modify-Merge Solution Both edit their local files. Repository Configuration Management

24. Aviva Arik Aviva The Copy-Modify-Merge Solution Aviva checks in her file to the repository first. Repository Write Configuration Management

25. Aviva Arik Aviva The Copy-Modify-Merge Solution Now, Arik tries to check-in his file. He gets an “up-to-date check error” Repository Write Configuration Management

26. Aviva A’ (=Aviva+Arik) Aviva The Copy-Modify-Merge Solution Arik updates his local copy to contain the changes made by Aviva. Changes are added to the local file. During this merge, conflicts may occur. Repository Read Configuration Management

27. Aviva B Aviva The Copy-Modify-Merge Solution A new merged file is created on Arik’s machine. Repository Configuration Management

28. B B Aviva The Copy-Modify-Merge Solution Arik commits his file to the repository. Repository Write Configuration Management

29. B B B The Copy-Modify-Merge Solution Aviva updates her file from the repository. Repository Read Configuration Management

30. Check-out etiquette • If two people have a file checked out, they have to merge their changes before check-in • Merging files can be messy! • This requires coordination and responsibility on the part of developers, not to make unnecessary check-outs, and not to hold check-outs for too long. Configuration Management

31. File Comparison • Users can graphically compare two versions of files, in or out of the database. • Tools: BeyondCompare, Windiff, AraxisMerge… • This helps with manual merges • Also helps people decide which version to access Configuration Management

32. SourceSafe • Central repository of read-only files. • Everybody sees the same version. • Only one user can check in at once. • No branching. • Limited merge capabilities. Synchronized with Visual Studio Configuration Management

33. Advantages of SourceSafe • Synchronized with Visual Studio. • Relatively inexpensive. • Relatively simple to administrate. Configuration Management

34. Disadvantages of SourceSafe • Does not support branching • Requires verbal coordination. • Poses a problem for large projects. • Complicates development of features • Not compatible with other OS’s. Configuration Management

35. Get Latest Version (?) • Getting the latest version copies (rather than links) the file from the database to your personal directory - And so: • Getting latest version overwrites files in personal folders. • Rename local files beforehand if you want to keep them. • Database updates do not update local copies. • Changes to database necessitate manual merges. Configuration Management

36. Preserving Database Integrity(or: watch SourceSafe limp…) • Before a SourceSafe check-in: • Verify thoroughly that the modified file works with other files • Otherwise there could be big trouble… • Other systems allow for new branches • Files can be updated there. • Branch is merged with main trunk only after integrity checks. • Advantage: source control throughout the checking process! Configuration Management

37. Demo- SourceSafe Demo – SourceSafe Configuration Management

38. Concurrent Versions System • CVS has UNIX origins. • Available also for Linux and Windows. • Stores only the differences between versions. Configuration Management

39. Clients • Command line. • GUI (i.e. WinCVS, tkCVS, etc) • NOTE: Most GUI/Plugins are wrappers around the basic CVS command line client. Configuration Management

40. Revisions • Each version of a file has a unique Revision number. Revision numbers look like ‘1.1’, ‘1.2’, ‘1.3.2.2’ or even ‘1.3.2.2.4.5’. 1.1 1.2 1.3 1.4 Main.c Configuration Management

41. Revision Numbering • By default: • revision 1.1 is the first revision of a file. • Successive revisions incremement the rightmost number. Configuration Management

42. Tags • Tags are used to give a symbolic name to a certain collection of file revisions. 1.1 1.2 1.3 1.4 Main.c TAG_XXX 1.1 1.2 Main.h 1.1 1.2 1.3 Lala.c Configuration Management

43. Branching • Like ClearCase, CVS allows branches: • Allows changes to be isolated into a separate development line. • Branches are good for: • Fixing bugs in historical releases. • Developing features without disrupting primary development. Configuration Management

44. Trunks and Branches • The main branch is called the “main trunk”. • A branch can be merged back to the main trunk, or left as a branch. Configuration Management

45. Branches and Revisions 1.2.2.2.2.1 1.2.2.2.2.2 Branch 1.2.2.2.2 -> 1.2.2.1 1.2.2.2 Branch 1.2.2. -> 1.1 1.2 1.3 1.4 Main Trunk Main.h 1.2.4.1 1.2.4.2 1.2.4.3 Branch 1.2.4. -> Configuration Management

46. ClearCase - Overview Rational ClearCase is a software tool for revision control of source code and other software development assets. Basic concepts: Items under ClearCase are generally referred to as “elements”. For example: design models, source files, project files, DLLs, etc. Configuration Management

47. VOB All elements stored in VOBs – Version Object Bases. Depending on the size and complexity of your SW development environment – ClearCase elements may be distributed across more than one VOB. For example: • elements used by the Documentation group can be stored in one VOB, while elements contributing to software builds can be stored in a different VOB. Configuration Management

48. VOB – Illustration This diagram illustrates a VOB that contains the file elements : prog.c, util.h, msg.cat, and lib.c Configuration Management

49. View • To access an element under ClearCase, you set up and work in a view, • A view shows a directory tree of specific versions of the element. Configuration Management

50. Two kinds of views: • Snapshot views • copy files from VOBs to your computer. • Dynamic views, • use the multiversion file system (MVFS) of ClearCase to provide immediate, transparent access to the data in VOBs. Configuration Management