1. 1 Software Configuration Management (SCM) and Software Reuse Presented By: Edmund Leng (HT052446J) Choo Zhi Min (HT052430X)

2. 2 Agenda Software Configuration Management (SCM) Relationship between SCM and Software Reuse Use of SCM to promote Software Reuse SVN in Action Use of SVN in Plone and FRS Q&A

3. 3 Software Configuration Management Software Configuration Management: the discipline of identifying the configuration of a system at distinct points in time for the purpose of systematically controlling changes to the configuration and maintaining the integrity and traceability of the configuration throughout the system life cycle Source: IEEE, SWEBOK (Ber97)

4. 4 Goals of SCM The goals of SCM are generally:  Configuration identification - What code are we working with?  Configuration control - Controlling the release of a product and its changes.  Status accounting - Recording and reporting the status of components.  Review - Ensuring completeness and consistency among components.  Build management - Managing the process and tools used for builds.  Process management - Ensuring adherence to the organization's development process.  Environment management - Managing the software and hardware that host our system.  Teamwork - Facilitate team interactions related to the process.  Defect tracking - Making sure every defect has traceability back to the source

5. 5 SCM Essentially, SCM helps several developers who are working on the same code base to collaborate, minimizing the risk of them stumbling over each other Items that are placed under configuration control:  Requirement Specification  Project Plan  Design Specifications  Test Plan and Test Cases  Source Codes  User Documentations  Data Dictionaries  Quality Plan

6. 6 Version Control in Action

7. 7

8. 8 Version Control Version Control is the most essential part of the SCM With Version Control, software developers are able to work simultaneously on updates Implicit in this control was the ability to return to any earlier state of the design It is extremely common for multiple versions of the same software to be deployed in different sites At the simplest level, developers could simply retain multiple copies of the different versions of the program, and number them appropriately

9. 9 History Model Changeset: A specific collection of changes with a unique name Different version control tools manage changes in the repository differently Subversion manages versioned trees as first order objects (the repository is an array of trees) and the changesets are things that are derived (by comparing adjacent trees Arch or Bitkeeper are designed to manage changesets as first order objects (the repository is a bag of patches), and trees are derived by composing sets of patches together

10. 10 Branching and Merging Branching, tagging, and merging are concepts common to almost all version control systems A branch is a line of development that exists independently of another line Branching allows you to work on a complex changes without interfering with the stability of the trunk, feature branch or release branch Merging enables you to compare the differences between 2 branches and apply the differences to your working copy

11. 11 Software Reuse Benefits of Software Reuse:  Abstracts the user away from the inherent complexities of software  Provides better quality software by reusing a component that are tested and verified  Shorter time-to-market Because of the benefits that Software Reuse brings, reuse is not ad hoc or by chance but integrated into the SDLC => SCM can be used to support Software Reuse

12. 12 Problem in Software Reuse? 2 philosophies exist on how to manage the idea of software reuse: Provide the software, along with any required dependencies in one monolithic package. Used by most Microsoft Windows application Provide smaller single purpose package that requires the dependent packages are already installed. Used by most developers of Linux and UNIX packages today The 2 nd approach is more conducive for the reuse of code but pose its own set of problems: Dependency Management  Example: A basic Mozilla application consists of 495 files scattered through 10 different directories. When upgrading, a user must replace all these files. To operate, Mozilla requires 50 other executables and libraries (many of which, in turn, require still other libraries)

13. 13 Build Automation The sheer number of reuse code made manual management of the software dependencies is impossible Automated environment for builds are a common feature of software development Build Automation not only manage software dependencies, but also automate activities like packaging binary code, running tests and deployment A number build automation software are available: GNU Automake Apache Ant Apache Maven MSBuild Ruby Rake

14. 14 Continuous Integration Continuous integration describes a set of best practices in software engineering  Maintain a single code repository  Automate the Build  Make the Build self-testing  Commits everyday  Automate Deployment Much of these best practices are achieved through SCM Continuous Integration is one of the cornerstones of Agile Programming

15. 15 Subversion Introduction (1) Subversion (SVN) is a free/open-source version control system. Version 1 released in 2004. Now in version 1.4x. Manages files and directories, and the changes made to them, over time. Recover older versions of your data, or examine the history of how your data changed. “time machine” Can be used to manage any collection of files. Flexible enough to be used as software configuration management (SCM) systems.

16. 16 Subversion Introduction (2) We will look at:  Revision  Changesets  Externals Definitions  How do Changesets and Externals Definitions help in reuse?

17. 17 Revision (1) Commit treats changes to any number of files and directories as a single atomic transaction. You can create, delete, rename, and copy files and directories; then commit a complete set of changes as an atomic transaction. This creates a new state of the filesystem tree, called a revision. Revision is a unique natural number, incremented by 1 for each commit.

18. 18 Revision (2) Revision numbers apply to entire trees, not individual files. Revision N represents the state of the repository filesystem after the Nth commit.

19. 19 Changesets In SVN, a changeset is a collection of changes with a unique name -- textual edits to file contents, modifications to tree structure, or tweaks to metadata. So, revision N as not just a tree, but a changeset as well. Read the commit history ( svn log -r 9238 ) to read about the exact changeset that fixed the bug. Run svn diff to the patch itself. Run svn merge to merge specific changesets from one branch to another. See the previous figure on revision

20. 20 Externals Definitions (1) If we want different subdirectories in a checkout to come from different locations in a repository

21. 21 Externals Definitions (2) An externals definition is a mapping of a local directory to the URL— and ideally a particular revision—of a versioned directory. Declare externals definitions in groups using the svn:externals property. Example: third-party/sounds http://sounds.red-bean.com/reposhttp://sounds.red-bean.com/repos third-party/skins http://skins.red-bean.com/repositories/skinprojhttp://skins.red-bean.com/repositories/skinproj third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-makerhttp://svn.red-bean.com/repos/skin-maker svn update and commit command will take effect directly on the target external directories.

22. 22 Applying externals definitions - an example from Plone Plone (www.plone.org) is a ready-to-run content management system that is built on the Zope application server, written in Python.www.plone.org Group a release in a “bundle” folder. Each bundle folder is nothing but a empty folder with externals definitions that point to components to assemble the release. Example:  http://dev.plone.org/plone/browser/bundles/3.1  http://dev.plone.org/plone/browser/bundles/2.5  Components: PloneLanguageTool and kupu

23. 23 Applying changesets – FRS To develop FRS USER,BR, we select FRS USER as our baseline and add BR (block reservation) to it. The customization of FRS USER includes:  Finding components affected by feature BR in FRS DATE,USER,PAY,BR, and extracting relevant code,  Analyzing the impact of feature BR on FRS USER,  Implementing feature BR on FRS USER. If information on modifications made for PAY in BR is not available, implementation becomes more difficult.

24. 24 Applying changesets – FRS When developing new feature, branch out (M) to isolate the changes. When the changes are committed and merged (N), the revisions from branching to merging (denote as rM:N) become the changeset for the new feature.

25. 25 Applying changesets – FRS BR FRS Date,User,Pay Revision 43 FRS Date,User,Pay,BR Revision 58 Extract and merge changeset r43:58 svn merge -r 43:58 BR FRS User Revision 61 FRS User,BR Revision 75 Implement BR

26. SPC X-frame 26 Discussion MDD vs Agile Programming Can we use SVN Externals Definitions to manage XVCL?

27. 27 References No Silver Bullet - essence and accidents of software engineering by Fred Brooks Software Configuration Management Tools by Angus K. F. Chan and Sheung-lun Hung High-level Best Practices in Software Configuration Management by Laura Wingerd & Christopher Seiwald Version Control with Subversion, http://svnbook.red- bean.com/http://svnbook.red- bean.com/ www.plone.org and svn.plone.org www.plone.org Evolution of versions and configuration management, LINK LINK

28. 28 Thank you Q&A