The paper is all about the workflow using GIT and Gerrit to streamline the development and deployment process of software development lifecycle

1. w
w
w
.ijarcsa.org
GIT WORKFLOW, FROM DEVELOPMENT TO DEPLOYMENT
REDEFINED!
PRAVAT KUMAR SUTAR
Senior Solution Integrator, Ericsson India Global Services Pvt. Ltd.
ABSTRACT
Distributed version control or Decentralized version control, allows many software developers to
work on a given project without requiring them to share a common network. The software revisions
are stored in a distributed revision control system (DRCS), also known as a distributed version control
system (DVCS).
One such open source DVCS, Git, provides a lightweight yet robust framework for tracking and
controlling changes to a project's files, in particular to source code, documentation, and web pages.
For individual researchers, Git provides a powerful way to track and compare versions, retrace errors,
explore new approaches in a structured manner, while maintaining a full audit trail. For larger
collaborative efforts, Git and Git hosting services make it possible for everyone to work
asynchronously and merge their contributions at any time, all the while maintaining a complete
authorship trail.
In this paper, I provide an overview of Git work flow that can be followed across organizations and I
have highlighted both development and deployment including the code review through GERRIT and
the deployment through Jenkins/Hudson and how it can leverage development/deployment process of
Agile Methodology more reproducible and transparent, foster new collaborations, and support novel
uses.
Keywords: Distributed Version Control Systems (DVCs), Agile Methodology, GIT, GERRIT,
Hudson/Jenkins, repository, SPRINT, Clone, Checkout, Switch, Rebase, Branch, Tag, Development
Server, Acceptance Server, User Acceptance Server and Production Server, Apache Tomcat.
PURPOSE
CollabNetTeamforge’sGit integration is powered by Gerrit, an open source Git server which enforces
access control on Git repositories and supports powerful review features and integration points for
continuous integration tools like Jenkins. Few points are necessary to make out here
a. Source code is maintained in Teamforge’s remote repository
b. The code changes are not pushed directly to remote repository instead it is pushed to Gerrit
for review.
c. Jenkins is used for continuous integration, gerrit-trigger for reviewing the code in Gerritforge,
for building the maven projects and deploying the projects web archive in the application
servers.
d. The User Stories, Epics, Defects and Tasks are maintained in Teamforge’s Tracker artifacts.
The basic purposesare
a. How efficiently we can manage the development and deployment cycle with this GIT version
control system.
www.ijarcsa.org 27 admin@ijarcsa.org
INTERNATIONAL JOURNAL OF ADVANCED RESEARCH IN COMPUTER SCIENCE AND APPLICATIONS
ISSN 2321-872X ONLINE ISSN 2321-8932 PRINT IMPACT FACTOR : 0.782
VOLUME 3, ISSUE 3, MARCH 2015.

2. w
w
w
.ijarcsa.org
b. How efficiently we can revert the defect code from the codebase
c. How efficiently we can maintain the release tags before the release to different instances.
High Level Work flow architecture Diagram
www.ijarcsa.org 28 admin@ijarcsa.org
INTERNATIONAL JOURNAL OF ADVANCED RESEARCH IN COMPUTER SCIENCE AND APPLICATIONS
ISSN 2321-872X ONLINE ISSN 2321-8932 PRINT IMPACT FACTOR : 0.782
VOLUME 3, ISSUE 3, MARCH 2015.

3. w
w
w
.ijarcsa.org
DESCRIPTION
Step 1: ASPRINT-<N>Branch (Ex. SPRINT-1) will be created at the starting of each sprint in remote
eforge GIT repository.
Step 2: The developer will clone the remote repository to the local system for first time. From the 2nd
time onwards, the developer has to fetch from remote and checkout or switch to SPRINT-<N>
branch.
Step 3: The developer will create a separate feature branch in the local based on the ticket, s/he has
accepted or assigned to him/her. The name of the branch will be sprint-ticket-<ticket-no>. Here
sprint number is not mentioned in the feature branch because a ticket may not be completed in a
single sprint.
Below are the steps
Fetch SPRINT-<N> from remote Rebase remote SPRINT-<N> branch with local SPRINT-
<N>Create new feature branch from SPRINT-<N>
Example:
If a developer works in defects/task i.e. “artf1234” of SPRINT-1, then below steps need to be
followed:
1. git fetch origin
2. git checkout SPRINT-1
3. git rebase origin/SPRINT-1 SPRINT-1
4. git checkout -b sprint-ticket-artf1234
Step 4: Once the code changes are done, the developer will do unit testing to validate everything
looks fine based on the requirement in the ticket. At this stage, the developer will test the code in local
system. The developer will commit the changes to the feature branch and push it for review to
GERRIT SPRINT-<N> branch.
Note: Kindly note that the modified code won’t go to the GIT remote repository directly rather it will
go to GERRIT for code review.
Step 5: The reviewer(s) will review the code changes in GERRIT and can provide the
suggestions/recommendations, abandon or merge the changes. In case it is abandoned, the watch list
will get notification on this and the developer who worked on the ticket need to rework based on the
suggestions and recommendations and this process will be continued. In case the reviewer is
approving the changes, the code will be merged to SPRINT-<N> branch ofthe remote repository.
Step 6: If the merge is successful, no action is required. The latest code will move to the remote
repository but if a conflict occurs even after the review is success, GERRIT will not be able to merge
and abandon the commit. A notification will be sent to the watch list. The developer need to fetch,
rebase (rebase feature branch with remote SPRINT-<N>) to resolve the conflicts and push the updated
code to GERRIT again. Again the reviewer, review the changes and merge the code to GIT remote
repository.
Step 7: The deployment process starts from here. Once the code changes are merged with the remote
repository, a tag for DEV release will be created with name DEV-SPRINT-<N>-<DATE>-<TIME>.
www.ijarcsa.org 29 admin@ijarcsa.org
INTERNATIONAL JOURNAL OF ADVANCED RESEARCH IN COMPUTER SCIENCE AND APPLICATIONS
ISSN 2321-872X ONLINE ISSN 2321-8932 PRINT IMPACT FACTOR : 0.782
VOLUME 3, ISSUE 3, MARCH 2015.

4. w
w
w
.ijarcsa.org
Step 8: The DEV-SPRINT-<N>-<DATE>-<TIME> tag will be deployed to DEV application server
by Jenkins.
Step 9: Testing will be performed in DEV.This deployment to DEV and ACC is a continuous process
that can be done partially or completely. If testing fails in DEV, the team will be notified and
corrective action will be taken in SPRINT-<N> branch.
Step 10: If testing is successful in DEV, the deployment can be done in ACC.
Step 11: Testing will be performed in ACC. If testing fails in ACC, the team will be notified and
corrective action will be taken in SPRINT-<N> branch.
Step 12: If testing is success in ACC, a tag for PROD deployment will be created from the SPRINT-
<N> branch as it will be the stable one. The syntax of the tag name for PROD will bePRD-SPRINT-
<N>-<DATE>-<TIME>.
Step 13: The deployment will be done in User Acceptance Testing (UAT) Server with PRD-
SPRINT-<N>-<DATE>-<TIME>tag.
Step 14: Testing will be performed in UAT. If testing is successful, deployment plan will be made for
Production release. If testing fails, the corrective action will be taken in SPRINT-<N> branch and
again the whole deployment process will be continued as is.
Step 15: Deployment will be done in Production once testing in UAT is successful.
Step 16: Testing will be performed in production. If testing fails at some point, the code will be
reverted back to the previous one and the SPRINT-<N> will be marked as fail.
Step 17: If testing is successful, the code will be merged in a master branch.
Note: Here master is the stable branch which will always be updated after a successful production
release.
CONCLUSION
Since GIT is a standard tool that is widely used and backed by a large developer community, there are
numerous resources for learning and seeking helpofficial tutorial athttp://git-scm.com. GIT can be
readily used without any knowledge of command-line tools due to the available of many fully
featured GIT graphic user interfaces http://git-scm.com/downloads/guiswebsite. However, leveraging
its full potential, especially when working on complex projects where one might encounter unwieldy
merge conflicts, comes at a significant learning cost. There are also comparable alternatives to GIT
(e.g. Mercurial) which offer fewer granularities but are more user-friendly but as a matter of fact, the
workflow is important on how you are defining the development, code review and deployment
process.More the workflow streamlined; more will be the productivity gain.
REFERENCES
1. Pragmatic Guide to Git by Travis Swicegood
2. Version Control with Git, 2nd Editionby Jon Loeliger, Matthew McCullough
3. Introduction to Git-flow: A Git Workflow and Development Model by Chris Weed
www.ijarcsa.org 30 admin@ijarcsa.org
INTERNATIONAL JOURNAL OF ADVANCED RESEARCH IN COMPUTER SCIENCE AND APPLICATIONS
ISSN 2321-872X ONLINE ISSN 2321-8932 PRINT IMPACT FACTOR : 0.782
VOLUME 3, ISSUE 3, MARCH 2015.