1 / 17

Ivan Marsic Rutgers University

LECTURE 3: Software Configuration Management. Ivan Marsic Rutgers University. Topics. Definitions Working Scenarios Revision Control Functions Git and GitHub. Why Software Config Mgmt?.

dprzybylski
Download Presentation

Ivan Marsic Rutgers University

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LECTURE 3:Software Configuration Management Ivan Marsic Rutgers University

  2. Topics • Definitions • Working Scenarios • Revision Control Functions • Git and GitHub

  3. Why Software Config Mgmt? Software configuration management (SCM) is the process of controlling the evolution of a software system • Simplifies sharing code and other documents • The ability to revert to an older version (“undo”) • Coherently integrate contributions from team members (“merge”) • Notify interested parties about new modifications (“reporting”) • Track software issues (e.g., bugs) • Create an auditing trail (“archiving”) • SCM system allows us to answer questions: • When was this software module last changed? • Who made changes in this line of code? • What is the difference between the current version and last week’s? • How many lines of code did we change in this release? • Which files are changed most frequently?

  4. Why Software Config Mgmt? • SCM simplifies collaboration and increases productivity • But it all can be done withold-fashioned email, file system, etc. • Naming convention? • How to reconcile your version #1 with my version#1?

  5. Definitions • A software configuration is a collection of work products (“artifacts”) created during a project lifetime • Software configuration item (SCI) is any piece of knowledge (a.k.a. “work product” or “artifact”) created by a person (developer or customer) • A snapshot of a software configuration or a configuration item represents the version of that item at a specific time • A commit (or “check-in”) refers to submitting a software configuration to the project database (“repository”) • A build is a version of a program code (part of a software configuration), and a process by which program code is converted into a stand-alone form that can be run on a computer (“executable code”)

  6. Repository vs. Workspace • Project database is usually on a remote server,or “mirrored” on several servers • This is the “team memory,” unlike individual workspaces that are private • SCM provides a set of tools to interact with project database Project database (“repository”) Committed configurations (at discrete times during project life) team with the Shared retrieve (or, pull or, check-out) commit (or, push or check-in) Private to individual developer Working copies (piecewise continuous development) Developer’s workspace (“working directory”)

  7. Version Graph and Branching • Each graph node (a “commit”) represents a “version” of the software configuration shared with the team • The private workspace of one team member was publicized in the shared repository and becomes a part of “team memory” • Think of branches as separate folders, each with its own content and history • The project snapshot at the tip of a branch represents the latest version Hotfix branch — to fix bugs in the master Master branch (“trunk” or “mainline”) — in production (“fork”) (“merge”) (“fork”) root Time Topic branch — new features development

  8. Example Working Scenarios • Undoing mistakes in new work • Supporting multi-pronged product evolution • Parallel versions coexist at times, but will eventually merge (single trunk—“Master”) • Developing product lines • Coexisting parallel versions (same product for different markets) that will never merge (multiple trunks) • but they still need synchronization so that versions for different markets are at the same “level” • Working with a small team of peers • All developers can write to the project database • Working with a managed team • Only configuration manager can write to the project database

  9. Undoing Mistakes master “Pointer” or identifier for a commit Time • We can undo a commit; undo a merge; or undo a checkout • (See later how undo can be done without deleting the history) C0 C1 C2 C3 root master Undo a commit: C0 C1 C2 C3 root

  10. C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 Multi-pronged Product Evolution • Parallel versions coexist at times, but will eventually merge (to a single trunk—Master branch) Hotfix branch Master branch Develop branch Topic branch

  11. () () Allow write access to whole team Reject & request merge Accept Accept Central repository Check-out Make change Check-in Developer A Check-out Merge Check-in Check-out Make change Check-in Developer B Time Working with Peers:Centralized Workflow • Example scenario: Two developers clone from the hub and both make changes • The first developer to push his changes back up can do so with no problems • The second developer must merge in the first one’s work before pushing changes up, so as not to overwrite the first developer’s changes () Assuming no other commits in the meantime; otherwise need to merge

  12. Merge with Developer’s repository Push to Project repository [change accepted] [accepted] Push to Project repository Configuration Manager Notify or request revise & resubmit [rejected] [change rejected] Project repository Developer Push to Developer’s repository Push to Developer’s repository Pull request Pull request Pull Make change Revise Developer’s public repository Time Working with a Managed Team • Example scenario: • 1. The configuration manager pushes the current version to the main project repository • 2. A contributor clones that repository and makes changes • 3. The contributor pushes the changed version to his own public repository • 4. The contributor notifies the configuration manager requesting to pull changes • 5. The configuration manager adds the contributor’s repository as a remote and merges locally • 6. The configuration manager pushes merged changes to the main project repository

  13. Git: States ofSoftware Configuration Items • git add is a multipurpose command (to begin tracking new files, to stage files, etc.,e.g., marking merge-conflicted files as resolved • Using git addwe signal to Git that we wish to “add this content to the next commit”(place it to the “staging area”) • Next time we execute git commit,Git will “add this file to the project” Tracked add the file (git add) Untracked Unmodified Modified Staged edit the file stage the file remove the file commit

  14. C2 Undo: Reverting vs. Resetting • git revert undoes a committed snapshot C2 by undoing the changes and appending a new commit C1′ (instead of removing the commit C2 from the project history)  “safe” • Historic record of abandoned versions exists • git reset works backwards from the current commit by removing all of the commits after the target commit  “unsafe” • No historic record of abandoned versions Reverting: Resetting: HEAD HEAD C0 C1 C2 C0 C1 C2 C2 undonebut not removedfrom project history Undo C2 commit: Undo C2 commit: HEAD HEAD C2 removedfromproject history C0 C1 C2 C1′ C0 C1 C2

  15. C5 C1 C1 C1 C5 Merge on Large/Important Projects (a) (b) master develop master develop • (a) Before a topic branch merge • (b) After a topic branch merge • (c) After a project release C0 C2 C0 C2 C3 C4 C3 C4 topic topic (c) master develop C0 C2 This is as opposed to what? C3 C4 topic

More Related