CSCE 606: Configuration Management

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

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

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

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

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

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

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

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

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

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

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

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

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

Git Cheat Sheet CSCE 606 Configuration Management

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

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

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

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

Traditional Storage Model CSCE 606 Configuration Management

Git’s Storage Model CSCE 606 Configuration Management

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

Commit Internally CSCE 606 Configuration Management

Multiple Commits CSCE 606 Configuration Management

Multiple Commits and Branch Pointer CSCE 606 Configuration Management

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

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

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

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

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

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

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

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

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

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

Branch Model CSCE 606 Configuration Management

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

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

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

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

Branch Model CSCE 606 Configuration Management

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

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

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

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

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

CSCE 606: Configuration Management