UNIT-III

Introduction to project management: The need for source code control, the history of source
code management, Roles and code, source code management system and migrations, shared
authentication, Hosted Git servers, Different Git server implementations, Docker
intermission, Gerrit, The pull request model, GitLab

3.1 Need for Source Control

• Everything is code, and you need somewhere to store it.
• The organization's source code management system is that place.
• Developers and operations personnel share the same central storage for their different types
of code.
• There are many ways of hosting the central code repository:
– You can use a software-as-a-service solution, such as GitHub, Bitbucket, or
GitLab. This can be cost-effective and provide good availability.
– You can use a cloud provider, such as AWS or Rackspace, to host your
repositories.
 Some types of organizations simply can't let their code leave the building. For
them, a private in-house setup is the best choice.
• We will explore different options, such as Git, and web-based frontends to Git, such as
Gerrit and GitLab.
• This exploration will serve to help you find a Git hosting solution that covers your
organization's needs.

3.2 The history of source code management

• Terence McKenna, an American author, once said that everything is code.
• While one might not agree with McKenna about whether everything in the universe can be
represented as code, for DevOps purposes, indeed nearly everything can be expressed in
codified form, including the following:
– The applications that we build
– The infrastructure that hosts our applications
– The documentation that documents our products

Repository
• The repository is a Data storage solution where the history is maintained.
• Generally for this versioning is used and along with every version meta data like a reason
for the change is also maintained.
• Generally Repositories also have the option to view differences between versions.
• W.R.T CI/CD Pipelines we have two major repositories
– Source Code Repository
– Package Repository

Version Control System (VCS)

– • VCS is used to store generally code (any files)
• We would require
– Repository features
– Multi-user
• Synchronization
– Multiple releases parallel
•Evolution of VCS
•Single User VCS => VSS
•Multi User VCS => Subversion (SVN)
•Distributed VCS => Bitkeeper, Git

Architectures of Version Control System

•Centralized Version Control Systems

 Distributed Version Control Systems

Git
First Steps into Git
• Installing Git: https://git-scm.com/downloads
• Verifying if the git is installed or not git–version
The first step in Gitis to create a local repository.Createemptyfolder
– Cd into it
– execute init comm and git init

Git Commands
Getting & Creating Projects

Command Description
git init Initialize a local Git repository
git clone ssh://[email protected]/[username]/[repository- Create a local copy of a remote
name].git repository
Basic Snapshotting

Command Description
git status Check status
git add [file-name.txt] Add a file to the staging area
git add -A Add all new and changed files to the staging area
git commit -m "[commit
message]"
Commit changes

git rm -r [file-name.txt] Remove a file (or folder)

View the remote repository of the currently working file or
git remote -v
directory

Branching & Merging

Command Description
List branches (the asterisk denotes the current
git branch
branch)
git branch -a List all branches (local and remote)
git branch [branch name] Create a new branch
git branch -d [branch name] Delete a branch
git push origin --delete [branch name] Delete a remote branch
git checkout -b [branch name] Create a new branch and switch to it
git checkout -b [branch name] origin/[branch
name]
Clone a remote branch and switch to it

git branch -m [old branch name] [new branch

name]
Rename a local branch

git checkout [branch name] Switch to a branch

git checkout - Switch to the branch last checked out
git checkout -- [file-name.txt] Discard changes to a file
git merge [branch name] Merge a branch into the active branch
git merge [source branch] [target branch] Merge a branch into a target branch
git stash Stash changes in a dirty working directory
git stash clear Remove all stashed entries
git stash pop Apply latest stash to working directory
Sharing & Updating Projects

Command Description
Push a branch to your remote
git push origin [branch name]
repository
Push changes to remote repository
git push -u origin [branch name]
(and remember the branch)
Push changes to remote repository
git push
(remembered branch)
git push origin --delete [branch name] Delete a remote branch
Update local repository to the
git pull
newest commit
Pull changes from remote
git pull origin [branch name]
repository
git remote add origin
ssh://[email protected]/[username]/[repository-name].git Add a remote repository

git remote set-url origin Set a repository's origin branch to

ssh://[email protected]/[username]/[repository-name].git SSH

Inspection & Comparison

Command Description
git log View changes
git log --summary View changes (detailed)
git log --oneline View changes (briefly)
git diff [source branch] [target branch] Preview changes before merging
Three Areas of Git
• In the local repo or local system which represents a developer’ssystem, We have three areas
– Working Tree: This is where we make changes
– Staging area: This is intermediate are before sending changes to changes local
repo
– Local Repo: Once the change is in local repo it will have a history
Lets create a new folder and initialize it to be git repository
• Lets create a change
• Add the change to staging area and commit the change
• To commit a Change i.e. to maintain history, git requires
– Cchhaannggeess
– time when commit is done
– author username and email id
• To configure username and email id
– git config --global user.name “M Swetha"
– git config --global user.email “[email protected]"
Roles and code
• From a DevOps point of view,
– It is important to leverage the natural meeting point that the source code
management tool is.
– Many different roles have a use for source code management inits
wider meaning.
– It is easier to do so for technically-minded roles but harder for other roles, such as
project management.
• Developers live and breathe source code management.
• It's their bread and butter.
• Operations personnel also favor managing the descriptions of infrastructure in the form of
code, scripts, and other artifacts.
• Such infrastructural descriptors include network topology, versions of software that should
be installed on particular servers, and soon.
• Quality assurance personnel can store their automated tests in codified form in the source
code repository.
• There is a problem with the documentation of the manual steps needed to perform various
tasks.
• While many organizations employ a wiki solution such as the wiki engine powering
Wikipedia, there is still a lot of documentation floating around in the Word format on shared
drives and in e-mails.
• This makes documentation hard to find and use for some roles and easy for others.
• From a DevOps viewpoint, this is regrettable, and an effort should be made so that all roles
can have good and useful access to the documentation in the organization.
• It is possible to store all documentation in the wiki format in the central source code
repository, depending on the wiki engine used.

Source code management system migrations

• For many organizations, keeping the history is not worth the significant expenditure in time
and effort.
• If an older version is needed at some point, the old source code management system can be
kept online and referenced.
• This includes mirations from Visual SourceSafe and ClearCase.
• Some migrations are trivial though, such as moving from Subversion to Git.
• In these cases, historical accuracy need not be sacrificed.
• The master branch only contains finished work.
• All commits are tagged since they represent releases.
• All releases happen from the master.
• The develop branch is where work on the next release happens.
 When work is finished here, develop is merged to the master.
• We use separate feature branches for all new features.
• Feature branches are merged to develop.
• When a devastating bug is revealed in production, a hotfix branch is made where a bug fix
is created.
• The hotfix branch is then merged to master, and a new release for production is made.

Setting up a basic Git server

 A client machine with two user accounts. The git and ssh packages should be
installed.
– The SSH protocol features prominently as a base transport , for other protocols,
which is also is the case for Git.
– You need your SSH public keys handy. If you don't have the keys for some
reason, use ssh-keygen to create them.
• A server where the SSH daemon is running.
– This can be the same machine as the one where you simulate the two different
client users, or it can be another.
• A Git server user.
– We need a separate Git user who will handle the Git server functionality.
– Now, you need to append the public keys for your two users to the
authorized_keys file, which is located in their respective user's .ssh
directories. Copy the keys to this account.
• A bare Git repository.
– Bare Git repositories are a Git peculiarity. They are just Git repositories, except
there is no working copy, so they save a bit of space. Here's how to create one:
• cd/opt/git
• mkdir project.git
• cd project.git
o git init –bare
 Now, try cloning, making changes, and pushing to the server.
• Let's review the solution:
– This solution doesn't really scale very well.
– Solving security issues involves even more hassle.

Shared authentication
 In most organizations, there is some form of a central server for handling
authentication.
 An LDAP(Lightweight Directory Access Protocol) server is a fairly common choice.
 While it is assumed that your organization has already dealt with this core issue one
way or the other and is already running an LDAP server of some sort, it is
comparatively easy to set up an LDAP server for testing purposes.
 One possibility is using 389 Server, named after the port commonly used for the
LDAP server, together with the php LDAP admin web application for
administration of the LDAP server.
 We can then use the same LDAP server for all the different servers we are going to
investigate.
Hosted Git servers
 Many organizations can't use services hosted within another organization's walls at
all.
 These might be government organizations or organizations dealing with money, such
as banks, insurance, and gaming organizations.
 The causes might be legal or, simply nervousness about letting critical code leave the
organization's doors, so to speak.
 If you have no such qualms, it is quite reasonable to use a hosted service, such as
GitHub or GitLab, that offers private accounts.
 Using GitHub or GitLab is, at any rate, a convenient way to get to learn to use Git and
explore its possibilities.
 Both vendors are easy to evaluate, given that they offer free accounts where you can
get to know the services and what they offer.
 Some of the features offered by both GitLab and GitHub over plain Git are as follows:
–Web interfaces
– A documentation facility with an inbuilt wiki
– Issue trackers
- Commit visualization
– Branch visualization
– The pull request workflow

Different Git server implementations

 The distributed nature of Git makes it possible to try out different Git implementations
for various purposes.
• The client-side setup will be similar regardless of how the server is set up.
• You can also have several solutions running in parallel.
• The client side is not unduly complicated by this, since Git is designed to handle several
remotes if need be.

Docker Intermission
• We need to be able to try out a couple of different Git server implementations to see which
one suits our organization best.
• We can use Docker for this, so we will take this opportunity to peek at the possibilities of
simplified deployments that Docker offers us.
• Docker is used to download and run software.
• To get started with Docker, follow these steps:
– To begin with, install Docker according to the particular instructions for your
operating system. For Red Hat derivatives, it's a simple dnf install docker-io
command.
- Then, the dockerservice needs to be running:

o Systemctl enable docker

o Systemctl start docker

–We need another tool, Docker Compose, which, at the time of writing, isn't packaged
for Fedora. If you don't have it available in your package repositories, follow the
instructions on this page https://docs.docker.com/compose/install/

Gerrit
• A basic Git server is good enough for many purposes.
• Sometimes, you need precise control over the workflow, though.
• One concrete example is merging changes into configuration code for critical parts of
the infrastructure.
• While my opinion is that it's core to DevOps to not place unnecessary red tape around
infrastructure code, there is no denying that it's sometimes necessary.
• If nothing else, developers might feel nervous about committing changes to the
infrastructure and would like for someone more experienced to review the code changes.
• Gerrit is a Git-based code review tool that can offer a solution in these situations.
• In brief, Gerrit allows you to set up rules to allow developers to review and approve
changes made to a codebase by other developers.
• These might be senior developers reviewing changes made by inexperienced developers
or the more common case, which is simply that more eyeballs on the code is good for
quality in general.
• Gerritis Java-based and uses a Java-based Git implementation under the hood.
• Gerrit can be downloaded as a Java WAR file and has an integrated setup method.
• It needs a relational database as a dependency, but you can opt to use an integrated Java-
based H2 database that is good enough for evaluating Gerrit.
• An even simpler method is using Docker to try out Gerrit.
• There are several Gerrit images on the Docker registry hub to choose from.
• The following one was selected for this evaluation exercise:
https://hub.docker.com/r/openfrontier/gerrit/
• To run a Gerrit instance with Docker, follow these steps:
– Initialize and start Gerrit:
docker run -d -p 8080:8080 -p 29418:29418 openfrontier/gerrit
• Open your browser to http://<docker host url>:8080

The pull request model

• There is another solution to the problem of creating workflows around code reviews:
the pull request model, which has been made popular by GitHub.
• In this model, pushing to repositories can be disallowed except for the repository owner.
• Other developers are allowed to fork the repository, though, and make changes in their
fork.
• When they are done making changes, they can submit a pull request.
• The repository owners can then review the request and opt to pull the changes into the
master repository.

• This model has the advantage of being easy to understand, and many developers have
experience in it from the many open-source projects on GitHub.
• Setting up a system capable of handling a pull request model locally will require
something like GitHub or GitLab.

GitLab
• GitLab supports many convenient features on top of Git.
• It's a large and complex software system based on Ruby.
• As such, it can be difficult to install, what with getting all the dependencies right and so
on.
• There is a nice Docker Compose file for GitLab available at
https://registry.hub.docker.com/u/sameersbn/gitlab/.
• If you followed the instructions for Docker, including the installation of docker-compose,
it's now pretty simple to start a local GitLab instance:
– mkdir gitlab
– cd gitlab
– wgethttps://raw.githubusercontent.com/sameersbn/docker-
gitlab/master/docker-compose.yml
– docker-compose up
• The docker-compose command will read the .yml file and start all the required
services in a default demonstration configuration.
• The GitLab container includes the Ruby base web application and Git backend
functionality.
• Redis is a distributed key-value store, and PostgreSQL is a relational database.
• If you are used to setting up complicated serve functionality, you will appreciate that we
have saved a great deal of time with docker-compose.
• The docker-compose.yml file sets up data volumes at /srv/docker/gitlab
• To log in to the web user interface, use the administrator password given with the
installation instructions for the GitLab Docker image.
• They have been replicated here, but beware that they might
• Username: root
• Password: 5iveL!fe