UNIT – II: VERSION CONTROL AND CI/CD

Version Control System:

A Version Control System (VCS) is a tool that helps track and manage changes to a
project’s codebase over time. It allows multiple developers to work on the same project
simultaneously without conflicts, maintains a history of all changes, and enables easy
rollback to previous versions if needed. VCS ensures collaboration, code integrity, and
efficient management of software development.

IMPORTANCE OF VERSION CONTROL SYSTEM:

1. Tracking Code Changes
2. Enabling Team Collaboration
3. Maintaining Code History
4. Ensuring Backup and Recovery
5. Supporting Branching and Merging

TYPES OF VERSION CONTROL SYSTEMS:

Local Version Control System
Centralized Version Control System
Distributed Version Control System

1. LOCAL VERSION CONTROL SYSTEM:

Local version control systems are the most basic type of VCS, where all versioning is
done locally on a user's machine. Developers manually save different versions of files
using tools or even by creating separate folders.
Advantages of LVCS
• Simple and easy to set up
• Requires no internet or network connection

Disadvantages of LVCS
• Limited collaboration—only one user can work on the project at a time
• Higher risk of data loss if the local system crashes
• No built-in support for sharing code or resolving conflicts
2. CENTRALIZED VERSION CONTROL SYSTEMS:
Centralized version control systems contain just one repository globally, and every user
needs to commit for reflecting one’s changes in the repository. It is possible for others
to see your changes by updating.
Two things are required to make your changes visible to others
• You commit
• They update

Advantages of CVCS
• Simplicity in setup and management.
• Easy to maintain a single central repository.
• Suitable for small teams or projects with limited collaboration needs.
Disadvantages of CVCS
• If the central server goes down, no one can commit or retrieve updates.
• Limited support for branching and merging compared to DVCS.
• It can become a bottleneck if many developers are committing at once.
3. DISTRIBUTED VERSION CONTROL SYSTEMS:
Distributed version control systems contain multiple repositories. Each user has their
own repository and working copy. Just committing your changes will not give others
access to your changes. This is because commit will reflect those changes in your local
repository and you need to push them in order to make them visible on the central
repository. Similarly, when you update, you do not get others’ changes unless you have
first pulled those changes into your repository.
To make your changes visible to others, 4 things are required:
• You commit
• You push
• They pull
• They update
Eg: Git, and Mercurial

Advantages of DVCS
• Allows developers to work offline and commit changes locally before syncing
with others.
• Better handling of branches and merges.
• Faster access to version history, as developers don’t have to rely on a central
server.
• More resilient; if one copy of the repository is lost, it can be recovered from
others.
Disadvantages of DVCS
• More complex setup and configuration.
• Can require more storage space as each developer has a full repository.
• Potentially higher bandwidth usage when pushing and pulling from central
servers
GIT CONCEPTS:
1. Repository (Repo)
A repository is a storage space where your project’s files and their revision history are kept.
It can be local (on your computer) or remote (on a server).
2. Commit
A commit represents a snapshot of your repository at a specific point in time. Each
commit has a unique SHA-1 hash identifier and includes a message describing the
changes.
3. Branch
A branch is a parallel version of your repository. It allows you to work on different
features or fixes without affecting the main codebase. The default branch in a new
repository is usually called master or main.
4. Merge
Merging is the process of combining changes from one branch into another. It helps
integrate the work done in different branches.
5. Clone
Cloning is the process of creating a copy of a remote repository on your local machine.
6. Remote
A remote is a common repository that all team members use to exchange their
changes.
7. Staging Area / Index
The staging area (or index) is where you prepare changes to be committed. It allows
you to review and organize changes before making a commit.
8. Working Directory
The working directory is where you modify your files. Changes in the working directory
are not tracked by Git until you stage them.

GIT COMMANDS:
1. git init
Initializes a new Git repository in the current directory.
Command: git init
2. git clone
Creates a copy of an existing remote repository.
Command: Git clone <repository-url>
3. git status
Displays the state of the working directory and the staging area. It shows which
changes have been staged, which haven’t, and which files are not being tracked by Git.
Command: Git status
4. git add
Adds changes from the working directory to the staging area.
Command: git add <file>
To add all changes:
Command: git add .
5. git commit
Records the changes in the staging area in the repository with a descriptive message.
Command: git commit -m "Your commit message"
6. git log
Shows the commit history for the current branch.
Command: git log
7. git branch
Lists all branches in the repository. The * indicates the current branch.
Command: git branch
Creates a new branch:
Command: git branch <branch-name>
8. git checkout
Switches to a different branch or restores files in the working directory.
Command: git checkout <branch-name>
9. git merge
Merges changes from one branch into the current branch.
Command: git merge <branch-name>
10. git pull
Fetches changes from a remote repository and merges them into the current branch.
Command: git pull origin <branch-name>
11. git push
Uploads local commits to a remote repository.
Command: git push origin <branch-name>
12. git remote
Manages the set of tracked repositories.
To add a new remote:
Command: git remote add <name> <url>
13. git fetch
Downloads objects and refs from another repository.
Command: git fetch
14. git reset
Resets the current HEAD to a specified state. It can be used to unstage changes or
move the branch pointer.
To unstage changes:
Command: git reset <file>
15. git diff
Shows changes between commits, commit and working tree, etc.
To see changes in the working directory:
Command: git diff
To see changes between the working directory and the index:
Command: git diff --cached
16. git stash
Temporarily shelves changes in the working directory that are not ready to be
committed.
Command: git stash
To apply stashed changes:
Command: git stash apply
17. git tag
Creates a tag to mark a specific point in the repository’s history, typically used for
releases.
Command: git tag <tag-name>
18. git blame
Shows who made changes to each line in a file.
Command: git blame <file>
19. git reflog
Records updates to the tip of branches. It’s useful for recovering lost commits.
Command: git reflog
20. git rm
Removes files from the working directory and the index.
Command: git rm <file>

CI/CD PIPELINE:
A CI/CD pipeline is a set of automated processes that enable development teams to
integrate code changes (Continuous Integration, CI) and deliver them to production
(Continuous Delivery/Deployment, CD) quickly and safely.
1. Continuous Integration (CI)
• Integration of Code: Developers frequently merge their code changes into a
shared repository, usually several times a day. This practice helps in detecting
integration issues early.
• Automated Testing: Each integration triggers an automated build and testing
sequence to ensure that the new code changes do not break the existing
functionality.
• Feedback: Quick feedback is provided to developers on the quality and
correctness of their code, allowing for rapid identification and correction of
issues.
[Link] Deployment (CD)
• Continuous Delivery: This ensures that the codebase is always in a
deployable state. While not every change is automatically deployed to
production, the system is designed to support such deployments at any time.
 • Continuous Deployment: Extends continuous delivery by automatically
deploying every change that passes automated tests to production without
human intervention

CI/CD PIPELINE DIAGRAM:

CI (CONTINUOUS INTEGRATION) PHASES:

1. Plan
Definition:
This is the initial phase where teams gather requirements, define features, create user
stories, and plan upcoming work. The focus is on aligning the business needs with
development goals. It ensures everyone understands what’s being built and why.
Common Tools:
• Jira – Agile project management and sprint planning.
• Trello – Lightweight Kanban-style task board for planning and organizing.

2. Code
Definition:
In this phase, developers write the application source code and manage it using
version control systems. It often involves code reviews, branching strategies, and
collaboration to maintain code quality.
Common Tools:
• GitHub – Cloud-based version control with collaborative features.
• Bitbucket – Git repository management with built-in CI support.
3. Build
Definition:
The source code is compiled into executable artifacts or containers in this phase. The
process checks whether the code integrates properly and can run without errors,
usually through automated build scripts.
Common Tools:
• Maven – Popular Java-based build automation tool.
• Docker – Container platform for packaging applications with dependencies.

4. Test
Definition:
Automated tests are run to validate the application’s functionality, performance, and
security. It includes unit, integration, and UI tests to catch bugs early in the
development lifecycle.
Common Tools:
• JUnit – Widely-used testing framework for Java applications.
• Selenium – Framework for automated browser testing and UI validation.

CD (CONTINUOUS DELIVERY/DEPLOYMENT) PHASES:

5. Release
Definition:
This phase packages and prepares the build artifacts for deployment. It may include
tagging versions, generating changelogs, and pushing artifacts to repositories, often
requiring approval workflows.
Common Tools:
• Jenkins – Automates release pipelines and workflows.
• Artifactory – Repository manager for storing and distributing artifacts.

6. Deploy
Definition:
The application is deployed to various environments such as staging or production. In
Continuous Delivery, this is manual with approvals; in Continuous Deployment, it is
fully automated with zero manual intervention.
Common Tools:
• ArgoCD – GitOps-based continuous deployment for Kubernetes.
• Spinnaker – Tool for managing complex multi-cloud deployments.

7. Operate
Definition:
This phase focuses on maintaining the application in its runtime environment. It
includes provisioning infrastructure, scaling resources, and ensuring high availability
and performance of the system.
Common Tools:
• Kubernetes – Container orchestration platform for managing app
deployment and scaling.
• AWS – Popular cloud platform offering on-demand infrastructure and
services.

8. Monitor
Definition:
Monitoring provides real-time insights into the system’s performance, availability, and
errors. It helps identify issues before they impact users and enables proactive incident
management.
Common Tools:
• Prometheus – Metrics collection and alerting toolkit.
• Grafana – Visualization platform for creating monitoring dashboards.

RELEASE STRATEGIES IN CI/CD:

1. Blue-Green Deployment
Definition:
In this strategy, two identical environments—Blue and Green—are maintained. The
current version runs on one (say, Blue), while the new version is deployed to the other
(Green). Once verified, traffic is routed to Green, and Blue becomes the standby for
rollback.
Benefits:
 • Minimal downtime
• Easy rollback if issues occur

2. Canary Release
Definition:
The new version is released to a small subset of users initially. If it performs well, it is
gradually rolled out to the rest of the users.
Benefits:
• Risk mitigation through gradual exposure
• Real-world feedback before full rollout

3. Rolling Deployment
Definition:
Instead of updating all servers at once, the new version is deployed incrementally
across the infrastructure. One or a few instances are updated at a time until all are
running the new version.
Benefits:
• Balanced load during deployment
• No need for duplicate environments

4. A/B Testing
Definition:
Different users are served different versions (A and B) of the software. The goal is to
compare user behaviour and determine which version performs better.
Benefits:
• Helps optimize user experience
• Useful for testing new features or UI

5. Feature Toggles (Feature Flags)

Definition:
Features are integrated into the codebase but are hidden or disabled using flags.
They can be turned on/off without deploying new code.
Benefits:
• Safer testing in production
• Quick rollback of features

6. Shadow Deployment
Definition:
The new version receives real traffic in parallel with the live version but does not
affect the end users. It’s used for performance and error monitoring.
Benefits:
• Full visibility into behaviour under real-world conditions
• No risk to users during testing

7. Dark Launching
Definition:
A feature is launched silently to production and may be accessed only by internal
users or specific triggers. Public users are unaware of it.
Benefits:
• Internal validation before public exposure
• Useful for collecting real usage metrics

8. Recreate Deployment
Definition:
All existing instances are stopped and replaced with the new version at once. This is
simple but may cause downtime.
Benefits:
• Easy to implement
• Suitable for small applications or internal tools
CI/CD TOOLS – JENKINS:
Definition:
Jenkins is an open-source automation server used to automate parts of the software
development process, such as building, testing, and deploying code. It supports
Continuous Integration (CI) and Continuous Delivery (CD), helping developers quickly
find and solve bugs and automate the deployment process.

Jenkins Architecture:
Jenkins follows a Master-Agent Architecture to manage distributed builds. In this
architecture, the Master and Agents communicate through the TCP/IP protocol.
Jenkins architecture has two components:
o Jenkins Master/Server
o Jenkins Slave/Node/Build Server

Jenkins Master:
[Link] main control unit of Jenkins.
[Link] a web-based Dashboard (default port: 8080).
[Link] for:
• Scheduling build jobs.
• Dispatching builds to the agents.
• Monitoring agent status (online/offline).
• Recording and displaying build results.
[Link] also execute build jobs directly if needed.
[Link] by a .war file and platform-independent (Java-based).

Jenkins Slave:
[Link] the build jobs assigned by the Master.
[Link] jobs can be configured to run:
• On a specific agent,
• On a specific type of agent (e.g., OS-based),
• Or on the next available agent.
[Link] run on different operating systems like Windows, macOS, and Linux.
[Link] to the Master using SSH, JNLP, or Web Start.

The above diagram consists of a Jenkins Master which is managing three Jenkins
Slaves.

CI/CD TOOLS – GITHUB ACTIONS:

GitHub Actions is a CI/CD (Continuous Integration and Continuous
Delivery/Deployment) platform that helps automate software development workflows.
It allows developers to build, test, and deploy code directly from their GitHub
repositories using custom workflows.
How does GitHub Actions work?

GitHub Actions uses YAML configuration files to define workflows that are triggered by
events like code pushes, pull requests, or scheduled times. These workflows include
jobs and steps, which are executed on runners (virtual machines) to automate tasks
such as testing, building, and deploying code.

GitHub Actions key concepts and features

1. GitHub Actions workflows
A workflow is an automated process defined in a YAML file located in the
.github/workflows directory. It contains jobs that define what should be done (e.g.,
build, test, deploy) and when it should be triggered (e.g., on push, pull request, or
manually).

2. GitHub Actions events

An event is a specific activity in a GitHub repository (like a push, pull request, or issue
creation) that triggers a workflow to run. Events can be customized to trigger only
under certain conditions, such as specific branches or tags.

3. GitHub Actions runners

A runner is a virtual machine that executes the jobs in a GitHub Actions workflow.
GitHub offers hosted runners for Linux, Windows, and macOS, and also supports self-
hosted runners for custom environments.
4. GitHub Actions jobs
A job is a set of steps that are run on the same runner. Jobs can run in
parallel or sequentially, depending on whether they depend on the output
of other jobs.
5. GitHub Actions steps
A step is a single task or command within a job. Steps are run in order, and
they can either execute shell commands or call pre-defined actions.
6. Actions
An action is a reusable piece of code that performs a specific task, such as
setting up a programming environment or deploying code. Actions can be
shared by the GitHub community or created as custom actions.
Types of actions:
• JavaScript actions: Run directly on the runner.
• Docker container actions: Run in a Docker container.
• Composite actions: Combine multiple steps into one.
7. GitHub Actions artifacts
An artifact is a file or folder that is saved after a job completes. It can include
logs, test results, or build files, and is used for future processing or analysis.
8. GitHub Actions secrets
A secret is an encrypted environment variable used to store sensitive
information like API keys or passwords. These are securely accessed by the
workflow during execution without exposing them in the code.