Agile Software Development Practices SOF2412 / COMP9412 Tools and Technologies for Controlling Artifacts
The University of Sydney Page 1
Agile Software
Development Practices
SOF2412 / COMP9412
Tools and Technologies for
Controlling Artifacts
School of Computer Science
Dr. Basem Suleiman
The University of Sydney Page 2
Agenda
– Software development process models
– Activities and artifacts
– Agile Development Tools
– Software Development – Artifacts
– Version Control Systems
– Version Control with Git
– Using Git Commands
The University of Sydney Page 3
Waterfall Model Phases – Revisit
– Requirement’s analysis and definition
– Requirements document
– System and software design
– Design document based on requirements document
– Implementation and unit testing
– Code and test documents (using design documents)
– Integration and system testing
– Software components are integrated (whole system code document) and the
resulting system is tested (system tests)
– Operation and maintenance
The University of Sydney Page 6
Requirements Engineering Process – revisit
Requirements engineering
main activities and deliverables
Ian Sommerville. 2016. Software Engineering (10th ed. Global Edition). Pearson
The University of Sydney Page 7
Software Artifact – Software Requirements Speficiations
– Eliciting these from users was a lot of effort
– Different formats in various process methodologies
– In agile, often as “User stories” (plain text, stylized format, can be manipulated
by tools)
– In traditional methodologies, often huge Word documents in a standard template
• Software Requirements Specification (SRS)
• Signed off as obligation on the developers
– Track changes and versions of requirements is very important
The University of Sydney Page 8
Software Artifacts – Code
– Spread over different files, and in a directory structure
– Language conventions or requirements
– Eg Java has a file for each class
• Package hierarchy
– Documentation may be derived from the source code
– Maintainability and extensibility non-functional properties for a software
– Design and architecture play important role
– E.g., Model-View-Controller
– Layered architecture
The University of Sydney Page 9
Code Artifacts – Example
– Example of source directory structure
– Web application code structure
(Node/Express.js)
– Model-View- Controller (MVC) architecture
As source code artifacts evolve rapidly, it
becomes crucial to manage different versions of
these artifacts
The University of Sydney Page 10
Artifacts
– Items that represent work done, in ways that others can use
– Code, requirements specifications
– Artifacts go through evolution
– How much impact if these are lost or changes are lost or not tracked?
– How much effort was it to create them?
– The Artifacts have value and need to be preserved, communicated,
maintained, protected from unauthorized access, etc.
The University of Sydney Page 12
Code Artifacts – Version
Control
The University of Sydney Page 14
What is Version Control?
– A method for recording changes to a file or set of files over
time so that you can recall specific versions later
– aka revision control and source control
– Create, maintain and track history of changes during the SDLC for all
Artifacts
The University of Sydney Page 15
What is Version Control System (VCS)?
– Software tools to software teams to manage changes to source
code over time
– Keep track of every modification to code in a repository
– Revert selected files back to a previous state
– Compare changes over time
– See who last modified something that might be causing a problem
– Who introduced an issue and when
– compare earlier versions of the code to help fix bugs while minimizing disruption
to all team members
– And more
The University of Sydney Page 16
Local Version Control
– Programmers long ago developed local VCSs;
– E.g., Revision Control System (RCS) early VCS
– RCS works by keeping patch sets (i.e., the
differences between files)
The University of Sydney Page 17
Centralized Version Control (CVC)
– CVCSs support collaborative development
– A single server contains all versioned files and
a number of clients check-out files from it
– Better than local VCS
– Everyone is updated
– Easier admin – fine-grained control
– Single point of failure
– Developer’s work interrupted!
– Hard disk becomes corrupted, and no
proper/up-to-date backups? entire history lost!
The University of Sydney Page 18
Distributed Version Control (DVC)
– Developers fully mirror the repository including
the full history
– Several remote repositories
– Developers can collaborate with different groups
of people in different ways simultaneously with
the same project
– Can setup several types of workflows (not
possible in CVC)
The University of Sydney Page 19
Git Fundamentals
The University of Sydney Page 20
Version Control – SW Development Scenarios
– Multiple versions of the same software deployed in different sites and SW
developers working simultaneously on updates
– Developers fixing some bugs/issues may introduce some others as the
program develops
– Two versions of the software may be developed concurrently
– And many more
The University of Sydney Page 21
Git
– A version control system that helps development teams to manage
changes to source code overtime
– Web-based (online) central repository of code and track of changes
– Tracing history of changes, commits, branches, merges, conflict resolution
– Collaborate and update repository through command-line and GUI
– Public and private repositories
The University of Sydney Page 22
Delta-based VCSs (Differences)
– VCSs that store as a set of files and the changes made to each file over
time
– Example: CVS and subversion
The University of Sydney Page 23
Git – Snapshots Not Differences
– Git thinks about its data as a streams of snapshots of a small file system
– Git doesn’t store unchanged files, it just link to previous identical file already stored
The University of Sydney Page 24
Git – Basics
– Nearly Every operation is local
– E.g., to browse the project history, Git reads it directly from your local database
– Work and commit changes to local copies offline
– Git has built-in Integrity
– Using check-sum (SHA-1 hash) before it is stored and is reference it
– Git stores everything in its database by the hash value of its contents
• E.g., 77a8da644e2252987aa493b52f8696cd6d3f328765
The University of Sydney Page 25
Git – Basics (2)
– Git generally only adds data
– After committing a snapshot, it is very difficult to lose (you can undo things)
– Git has three states
– Committed: file is safely stored in your local database
– Modified: file has been changed but not committed it to the local database
– Staged: a modified file has been marked in its current version to go into next
commit snapshot
The University of Sydney Page 26
Git – Structure
Committed filesStaged filesModified files
The University of Sydney Page 27
Git – Structure
– Git directory (repository)
– Metadata and object database
– What is copied when you clone a repository from another computer
– Working directory (tree)
– A single checkout of one version of the project
– These files are pulled out of the compressed database and placed on disk for
you to use or modify
– Staging area (index)
– a file stores information about what will go into next commit
The University of Sydney Page 28
Git – Basic Workflow
1
2
3
The University of Sydney Page 29
Git Concepts and
Scenarios
Git Commands and Operations
The University of Sydney Page 30
Git Repository (Repo)
– A special directory contains project files
– Where git stores and tracks files (source code)
– Can be created or cloned
– Git adds special sub-directory to store history of changes about the project’s files
and directories
MyHR Source Code
Models Views
Controllers
Config.jsConfig.js
https://www.iconspng.com/
https://www.iconspng.com/
The University of Sydney Page 31
Git Repository (Repo)
– Creating a git repo on your local machine
– git init → will create .git
– Clone an existing git repository from elsewhere
• git clone
• a full copy of all data that the server has
MyHR Source Code
Models Views
.git
Controllers
Config.jsConfig.js
https://www.iconspng.com/
https://www.iconspng.com/
The University of Sydney Page 32
Metadata
– Each version should have:
– Unique name to refer to it
• Latest version: Head
– Date
– Author
– How might you use metadata?
The University of Sydney Page 33
Git – Recording Changes to a Repo
The University of Sydney Page 34
Git – Recording changes to a Repo
– States of project files:
– Tracked: Git knows about it (unmodified, modified, or staged)
– Untracked: Git doesn’t know about it
– When a repo is cloned then all files are tracked and unmodified
– When you edit files, Git denotes them as modified
– When you stage these modified files and commit all those staged changes, you
have a clean directory
– Git has operations to check the status of files, track new files, adding and removing
files to/from staging area, commit changes, view commit history, undoing things
The University of Sydney Page 35
Git – Branching
– Diverging from the main line of development and continue to do work without
messing with that main line
– Expensive process; often requires you to create a new copy of your source
code directory
– Git branching is lightweight (nearly instantaneous)
– With every commit, Git stores a commit object that contains
• A pointer to the staged snapshot, author’s name and email, commit message, and
commit/commits before this commit parent/parents commits
The University of Sydney Page 36
Git Branching – Example
– Assume your project directory contains 3 files.
Stage all files:
– $ git add README test.rb LICENSE
– Staging files: git computes a checksum of each
and stores the files in the git repo (as blobs)
The University of Sydney Page 37
Git Branching – Example
– Create a commit:
$ git commit -m ‘The initial commit of my project’
– git checksums each sub-directory and stores those tree objects in the git repo
– git then creates a commit object that has the metadata and a pointer to the
root project tree so it can re-create that snapshot when needed
– Our project directory now contains five objects;
– Three blobs (contents of one of the 3 files)
– One tree lists the directory contents and file names as blobs
– One commit with the pointer to the root and the commit metadata
The University of Sydney Page 38
Git Branching – Example
The University of Sydney Page 39
Git Branching – Example
– If you make some changes and commit again, the next commit stores a pointer
to the commit that came immediately before it.
The University of Sydney Page 40
Git Branching – Pointer’s Perspective
– lightweight movable pointer to one of the commits
– Default branch called “master”
– As you start making commits, you’re given a master branch that points to the
last commit you made
– Every time you commit, the master branch pointer moves forward automatically
The University of Sydney Page 41
Git – Creating a New Branch
– Example: create a new branch called testing in our project
– When you create a new branch, a new pointer will be created – pointing to the same
commit we are currently at
– How does git know what
branch you’re currently on?
$ git branch testing
The University of Sydney Page 42
Git – Creating a New Branch
– Git knows which branch is the current by maintaining a special pointer called
“HEAD”
– Creating a branch in Git does not
switch the HEAD to the new branch
– How to switch to another branch ?
The University of Sydney Page 43
Git – Switching to another Branch (1)
– You can switch to an existing branch using Git checkout command
$ git checkout testing
The University of Sydney Page 44
Git – Switching to another Branch (2)
Assume you edited test.rb file. let’s do another commit
$ git commit -a -m ‘made a change’
– How would this impact our repo?
– The testing branch has moved forward, but the master branch still points to the
commit you were on when you ran git checkout
The University of Sydney Page 45
Git – Switching to another Branch (3)
– What happens if we switch back to the master branch?
– Any changes we make from this point forward will diverge from an older
version of the project
– You can branch into another direction (not from testing branch)
$ git checkout master
The University of Sydney Page 46
Git – Switching to another Branch (4)
– Assume test.rb is edited and we want to commit – What happens?
$ git commit -a -m ‘made other changes’
– Both of those changes are
isolated in separate branches
– Switch back and forth
between the branches
and merge them together
when you’re ready
• To show the commits log use:
$ git log
The University of Sydney Page 47
Git – Merging Scenario (1)
– Consider the following real-world scenario
– Do some development on a website
– Create a branch for a new user story you’re working on
– Do some development in that branch
– At this stage, assume you receive a call that another issue is critical and you need
a hotfix. You’ll do the following:
– Switch to your production branch
– Create a branch to add the hotfix
– After it’s tested, merge the hotfix branch, and push to production
– Switch back to your original story and continue working
The University of Sydney Page 48
Git – Merging Scenario (2)
– Assume your project has a couple of commits already on the master branch
– To work on the issue (say iss53) you need to create a new branch and switch to it at
the same time (using git branch and checkout)
$ git checkout -b iss53
OR
$ git branch iss53
$ git checkout iss53
The University of Sydney Page 49
Git – Merging Scenario (3)
– You work on your website and do some commits (checked it out)
– E.g., change index.html to add a new footer
$ git commit -a -m ‘added a new footer [issue 53]’
c
The University of Sydney Page 50
Git – Merging Scenario (4)
– Imagine you receive a call for urgent issue in the website needs immediate fix
– How would you deal with this scenario?
– You can switch back to the master branch
– But you need to have clean working state before switch branches; i.e., working directory
doesn’t have uncommitted changes
$ git checkout master
The University of Sydney Page 51
Git – Merging Scenario (5)
– Create a new branch for fixing the urgent
issue, e.g., ‘hotfix’
$ git checkout -b hotfix
– Edit the index.html to fix broken email
address
$ git commit -a -m ‘fixed the broken email
address’
The University of Sydney Page 52
Git – Merging Scenario (6)
– merge the hotfix branch back into your master
branch to deploy to production
$ git checkout master
$ git merge hotfix
Fast-forward: the commit C4 pointed to by the
branch hotfix we merged in was directly ahead
of the commit C2, git moves the pointer forward
The University of Sydney Page 53
Git – Merging Scenario (7)
– Delete the hotfix branch (no longer needed):
$ git branch -d hotfix
– Switch back to the iss53 branch and continue working on it, edit index.html and
commit changes you make on iss53
$ git checkout iss53
$ git commit -a -m ‘finished the
new footer [issue 53]’
The University of Sydney Page 54
Git – Merging Scenario (8)
– Issue #53 work is complete and ready to be merged into the master branch
$ git checkout master
$ git merge iss53
– The development history has diverged
from some older point
– Git makes “three-way merge” using
two snapshots (see the figure)
The University of Sydney Page 55
Git – Merging Scenario – Three-way Merge (9)
– In the three-way merger, Git creates a new snapshot and automatically creates a new commit
that points to it
– This ‘special’ merge has more than one parent and it’s referred to as “merge commit”
– As the work has been merged in there’s no need for iss53 branch and the issue can be
recorded as fixed, so the branch iss53 can be deleted
The University of Sydney Page 56
Git – Conflict Resolution (1)
– Commits, branching and merging workflows can get complicated
– E.g., a developer may make changes to some part of a file in the iss53 branch and
another developer make changes to the same part of the same file on the hotfix branch.
– What will happen? How will Git manage this?
The University of Sydney Page 58
Git – Conflict Resolution (2)
– Conflict-resolution markers: special markers added automatically by Git to the
files that have conflicts to guide you where the conflicts
• The version in in the master branch HEAD (everything above the ===), while the
version in iss53 branch everything in the bottom part
• To resolve the conflict, you have to either choose one side or the other or merge
and remove those special markers
• After resolving conflicts, add each file to staging area – Git marks it as resolved
The University of Sydney Page 59
Git – Conflict Resolution (3)
• Graphical format: visual representation of merges and conflicts (
Git opendiff is the default)
• Other available tools opendiff, diffuse, diffmerge, codecompare
• When you exit the merge tool, Git asks if the merge was successful
– if you confirm that, it stages the file to mark it as resolved and
then you can commit the merge
The University of Sydney Page 60
Using Git
The University of Sydney Page 61
Git – The Command Line vs GUI
– Command-line tools
– The only place you can run all Git commands
– If you know how to run the command-line version, you can probably also figure
out how to run the GUI version
– Graphical User Interface (GUI)
– Most of the GUIs implement only a partial subset of Git functionality for
simplicity
The University of Sydney Page 62
Git Basics
See full list of commands at Git Cheatsheet from Atlassian
https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet
The University of Sydney Page 63
Git Log
See full list of commands at Git Cheatsheet from Atlassian
https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet
The University of Sydney Page 64
Git Commands
See full list of commands at Git Cheatsheet from Atlassian
Undoing Branches
https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet
The University of Sydney Page 65
References
– Ian Sommerville. 2016. Software Engineering (10th ed.) Global Edition.
Pearson, Essex England
– Scott Chacon. 2014. Pro Git (2nd ed.) Apress
– Free online book – download from https://git-scm.com/book/en/v2
– Additional Resources – Paper
– H-Christian Estler, Martin Nordio, Carlo A. Furia and Bertrand Meyer: Awareness and
Merge Conflicts in Distributed Software Development, in proceedings of ICGSE 2014, 9th
International Conference on Global Software Engineering, Shanghai, 18-21 August 2014,
IEEE Computer Society Press (best paper award),
– http://se.ethz.ch/~meyer/publications/empirical/awareness_icgse14.pdf
https://git-scm.com/book/en/v2
http://se.ethz.ch/~meyer/publications/empirical/awareness_icgse14.pdf
The University of Sydney Page 66
Tools and Technologies
for Controlling Artifacts
Advanced Git