CSCE 606: Configuration Management - PowerPoint PPT Presentation

brina
csce 606 configuration management n.
Skip this Video
Loading SlideShow in 5 Seconds..
CSCE 606: Configuration Management PowerPoint Presentation
Download Presentation
CSCE 606: Configuration Management

play fullscreen
1 / 49
Download Presentation
CSCE 606: Configuration Management
193 Views
Download Presentation

CSCE 606: Configuration Management

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. CSCE 606: Configuration Management Some material from J. Freeman, TAMU

  2. Outline • Software Configuration Management • Git Basics • Branching • Working with Remotes • Branch Models CSCE 606 Configuration Management

  3. Software Configuration Management (SCM) Software configuration management goals: • Configuration identification - identify configurations, configuration items and baselines • Configuration control - implement controlled change process; e.g. change control board to approve/reject change requests against a baseline • Configuration status accounting – record/report all necessary information on status of development process • Configuration auditing – ensure configurations contain all intended parts and are sound w.r.t. specifying documents, including requirements, architectural specs and user manuals • Build management – manage process and tools used for system builds • Process management - ensure adherence to development process • Environment management – manage HW/SW that hosts the system • Teamwork – facilitate team interactions related to the process • Defect tracking – make sure every defect has traceability back to the source http://en.wikipedia.org/wiki/Software_configuration_management CSCE 606 Configuration Management

  4. Version Control • Aspect of software configuration management • Management of changes to documents, source code, web sites,… • Also known as revision control, source code control • Track/control changes over time CSCE 606 Configuration Management

  5. Version Control System A tool for maintaining a record of changes in a set of documents • Common tools • CVS, Subversion, Git, Darcs, Mercurial • Also in SCM product, e.g. IBM/Rational ClearCase, Visual Studio ALM • A record of change • E.g. a patch generated with a diff type tool • Set of documents • Source code • Documentation, scripts, Makefiles,… • Works best for text files (contrast to binary files) CSCE 606 Configuration Management

  6. Reasons to Use Version Control • Helps in collaboration/coordination • Avoid conflicting changes in code/documents • Allows rolling back mistakes • In modules and system • Can maintain different configurations • E.g. different platforms • Avoid divergent code bases • Each providing different features CSCE 606 Configuration Management

  7. Reasons Not to Use Version Control THIS PAGE INTENTIONALLY LEFT BLANK CSCE 606 Configuration Management

  8. Reason to Use Version Control For Everything You Do • You find a set of files like this in a directory: Report_draft.txt Report.doc Report2.doc Report2a.doc Report_2011_03_02.doc ... NewReport_2011_05.doc NewReport_submitted.doc NewReport_submittedv2.doc • Can I just use the newest? CSCE 606 Configuration Management

  9. Terminology • Repository • Database with complete revision history of all files under version control • Maybe stored as files, relational database,… • Stored as full files and patches to them • Workspace or working tree • Files you are working on, that are tracked by version control system • A checkout of the repository, plus your local changes not committed http://en.wikipedia.org/wiki/Revision_control CSCE 606 Configuration Management

  10. Centralized vs. Distributed Version Control Systems • Centralized version control systems • One central shared repository • Working tree does not contain history • Subversion, CVS, Perforce • Distributed version control systems • With every working tree, entire repository stored as well • Local changes first committed to local repository, then repositories synchronized • One repository can be dedicated to be the central one, if desired • Git, Darcs, Mercurial CSCE 606 Configuration Management

  11. Centralized vs. Distributed • Centralized • Relatively straightforward workflow • Distributed • Flexible, supports wide variety of workflows • Can get very complex CSCE 606 Configuration Management

  12. Outline • Software Configuration Management • Git Basics • Branching • Working with Remotes • Branch Models CSCE 606 Configuration Management

  13. Git • Widely used distributed version control system • Started as system to support Linux kernel development • Pragmatic philosophy • Many tools • Many ways to accomplish tasks and arrange work • Many ways to share repositories/patches • Each VC system has its own terminology, but similar basic concepts • Our discussion will use established Git terms CSCE 606 Configuration Management

  14. Git References • Quick to learn the basic commands • Commands not used every day, hard to remember, but many places to refresh memory: • The Git Community Book • Pro Git book • Git Cheat Sheet • http://byte.kde.org/~zrusin/git/git-cheat-sheet-medium.png CSCE 606 Configuration Management

  15. Git Cheat Sheet CSCE 606 Configuration Management

  16. Creating Repository > mkdirmyproject > cd myproject > gitinit Initialized empty Git repository in ... /myproject/.git/ CSCE 606 Configuration Management

  17. Clone • As an alternative to an empty repository, one can clone an existing repository (repo) • Cloning allows us to create a copy of another repo • Other repos are called remotes • Our clone is called the local repo CSCE 606 Configuration Management

  18. Remotes • A repo can keep track of multiple remotes • Allows one to share work with multiple collaborators CSCE 606 Configuration Management

  19. Index • Git provides a special feature called the index • Allows us to compile our commit in pieces, slowly and selectively adding the changes we wish to record • Without the index, we have to specify our changeset in one command • Changes can be removed from the index without affecting the repo CSCE 606 Configuration Management

  20. Outline • Software Configuration Management • Git Basics • Branching • Working with Remotes • Branch Models CSCE 606 Configuration Management

  21. Traditional Storage Model CSCE 606 Configuration Management

  22. Git’s Storage Model CSCE 606 Configuration Management

  23. Commit • Whenever we have changes we want to record, we commit them • If we have many changes, we can commit them all at once, or separately according to some criteria • A checksum is computed for every commit, and then the commit is identified, both internally and sometimes also by the programmer, with this checksum • Example: 24b9da6552252987aa493b52f8696cd6d3b00373 • Usually a few digits from the beginning suffices to find a commit CSCE 606 Configuration Management

  24. Commit Internally CSCE 606 Configuration Management

  25. Multiple Commits CSCE 606 Configuration Management

  26. Multiple Commits and Branch Pointer CSCE 606 Configuration Management

  27. Branch • Repos will be comprised of branches • A branch is typically created to hold all of the development work for a single issue, like a new feature or the next release • A branch “branches” off another line of development, hence the name • All of its history is copied over to the new branch, but none of the work on the new branch affects the old one • A history is a single time-line of changes CSCE 606 Configuration Management

  28. Outline • Software Configuration Management • Git Basics • Branching • Working with Remotes • Branch Models CSCE 606 Configuration Management

  29. Sharing • When we have some changes committed, we may choose to share them • Remember that agile methods share everything • There are two main ways to share: giving and taking CSCE 606 Configuration Management

  30. Fetch • Every repo keeps a copy of its remote repos • Allows us to interact with remotes without continuous network traffic • Before we can share with one of our remotes, we need to make sure that our copy of it is up-to-date by fetching the latest version CSCE 606 Configuration Management

  31. Merge • To take changes from a remote, we can merge one of its branches into ours • Merging will try to incorporate all of the changes together • Sometimes conflicts will appear • They must be resolved manually before committing CSCE 606 Configuration Management

  32. Pull • Git provides a short-hand for fetching and merging called pulling • This is the name for taking changes that is common among version control systems CSCE 606 Configuration Management

  33. Giving • If we want to give our changes to others, one option is to just make them available for pulling • The alternative is to forcefully merge our changes into their repo CSCE 606 Configuration Management

  34. Push • When we commit our changes into a remote repo, it is called pushing • Commonly limited to a few authenticated contributors to avoid undesirable commits • Requires a pull of the remote to resolve conflicts beforehand CSCE 606 Configuration Management

  35. Merge (continued) • We can merge changes between any two (or more) branches • Not limited to one remote and one local branch • Merging does not change the fact that a branch has a single line of history • The merged branch’s history is either copied (e.g. it becomes part of the code’s family tree) or forgotten CSCE 606 Configuration Management

  36. Outline • Software Configuration Management • Git Basics • Branching • Working with Remotes • Branch Models CSCE 606 Configuration Management

  37. Why Separate Branches? • Separation of concerns • Less contention over the repository • Groups commit according to common theme, allowing easier porting or roll-back CSCE 606 Configuration Management

  38. Possible Branches • Examples • Released versions • Soon-to-be-released versions • Ongoing development • Ideas may never show up in a release, but you never know, so don’t flush the code • Features or topics • Hotfixes • Branch models are generally portable among version control systems CSCE 606 Configuration Management

  39. Branch Model CSCE 606 Configuration Management

  40. Main Branches • “master” • Each commit is tagged with a version number • Released versions of the product are built from this branch • “develop” • Latest set of features that will go into the next release • Always left in a functioning state (no work in progress) • These branches live forever • Other supporting branches have limited lifetimes CSCE 606 Configuration Management

  41. Release Branches • “release-*” • Whenever the “develop“ branch is feature-complete for the next release, create a release branch off of “develop“ • Only bugfixes or new metadata (like version numbers) may be committed • This branch may periodically be merged into “develop“ to pass on the bugfixes • When the release is complete: • Merge it into “master“ and tag • Merge it into “develop“ one last time • Delete it CSCE 606 Configuration Management

  42. Feature Branches • “*” (any unique name) • Whenever a developer wants to begin work on a new feature, bugfix, refactoring,… create a feature branch off of “develop“ • Try to break commits into their smallest, independent units • When the feature is complete and will be included in the next release: • Merge it into “develop“ • Delete it CSCE 606 Configuration Management

  43. Hotfix Branches • “hotfix-*” • Sometimes we make mistakes • Whenever we need an urgent fix for a released version, create a hotfix branch off of “master“ • Treat it exactly like an unplanned release branch • When a hotfix is complete: • Merge it into “master“ and tag • Merge it into “develop“ • Delete it • This model only supports hotfixes for the latest release • If you want to support old versions after new ones have been released, then do not delete release branches CSCE 606 Configuration Management

  44. Branch Model CSCE 606 Configuration Management

  45. Developer Model • Different teams require different contributor / maintainer structures • Factors: • Number of contributors • Affiliations • Centralized workflow sufficient for small teams • Distributed version control can still be used to provide centralized workflow • The shared repo has special status, but no special technical features CSCE 606 Configuration Management

  46. Large Team Distributed workflow is better for large teams • Single blessed repo for main branches • Developers • Pull from blessed repo • Push supporting branches to their own repos • Integration manager • Pulls supporting branches from developers • Merges into main branches • Pushes to blessed repo • Public and private repos for developers can be the same CSCE 606 Configuration Management

  47. Huge Team • Single integration manager can become overloaded as the team grows • Solution: introduce hierarchy • Feature managers (lieutenants) • Product manager (dictator) CSCE 606 Configuration Management

  48. Developer Model • These models demonstrate the benefits of a distributed version control system • Easy transition between the workflows as the team grows • Subgroups can be formed by simply dedicating a single developer’s repo as a blessed subgroup repo, and others adding that as a remote • Central server grows more slowly than the amount of work CSCE 606 Configuration Management

  49. Configuration Management Summary • Typical code development has graph-like dependencies • Use version control systems to manage code • Permits synchronization and consistency across developers • Permits roll back to previous point in code history CSCE 606 Configuration Management