CSCE 431 Lecture 6
Jump to navigation
Jump to search
« previous | Thursday, January 30, 2014 | next »
Software Configuration Management (SCM)
(See wikipedia:Software Configuration Management→)
- config identification
- Identify configs, config items and baselines
- config control
- implement controlled change process
- e.g. change control board to approve/reject change requests against a timeline
- config status accounting
- record/report all necessary information on status of development process
- config auditing
- ensure configs contain all intended parts and are sound with respect to spec docs, including requirements, arch. specs, and user manuals
- build management
- manage process and tools used for system builds
- e.g. Jenkins, Hudson, Travis
- process management
- ensure adherence to development process
- environment management
- manage hardware/software that hosts the system
- e.g. Heroku, Rackspace
- teamwork
- facilitate team interactions related to the process
- defect tracking
- make sure every defect (bug) has traceability back to the source.
Version Control
Aspect of SCM
- mgmnt of changes to documents, source code, etc. over time
- a.k.a. revision control, source control
Version Control System
(See wikipedia:Revision control→)
A tool for maintaining a record of changes in a set of documents
Common tools:
- CVS
- Subversion
- Git
- Darcs
- Mercurial
Included in SCM product:
- IBM/Rational ClearCase
- Visual Studio ALM
- JIRA
- Eclipse
Record of changes could be, for example, a patch generated with a diff type tool
Set of documents:
- source code
- documentation, scripts, Makefiles, etc.
- Works best for plain text files.
Reasons to use:
- collaboration/coordination (avoid conflicting changes)
- rolling back mistakes
- maintain different configurations (e.g. for different platforms)
- avoid divergent code bases that each provide different features
Terminology
- repository
- Database with complete revision history of all files under version control
- stored as files, relational DB, patches, etc.
- workspace or working tree
- current set of files being modified, that are tracked by VCS
- A checkout of the repository, plus local changes not committed (and in Git's case, the index staging area
Centralized vs. Distributed
Centralized
- one central shared repository
- working tree does not contain history
- e.g. SVN, CVS, Perforce
Distributed
- entire repository stored with working tree
- local changes first committed to local repository, then synchronized
- One repository can be dedicated to the central one, if desired
- e.g. Git, Darcs, Mercurial