VTRICKS TECHNOLOGIES

GIT and Continuous Integration/Deployment

CI/CD stands for Continuous Integration and Continuous Delivery/Deployment — modern
software engineering practices that automate the process of building, testing, and deploying
code.

These practices help developers deliver applications faster and more reliably.

CI/CD is a DevOps methodology that bridges the gap between development and operations
teams by automating repetitive tasks, ensuring consistency, and enabling continuous feedback.

2. Components of CI/CD

A. Continuous Integration (CI)

Continuous Integration is the practice of frequently merging code changes from multiple developers
into a shared repository (e.g., GitHub, GitLab).
Each integration triggers an automated build and testing process to detect issues early.

Key steps in CI:

Developers push code to a shared version control repository.
Automated build tools compile the code.
Automated tests (unit/integration tests) run to validate functionality.
CI server reports success/failure to the developers.
Goal: Detect bugs early, maintain code quality, and avoid “integration hell”.

B. Continuous Delivery (CD)

Continuous Delivery extends CI by automating the release process up to the staging or pre-production
environment.
Once code passes all tests, it can be deployed with one click.
Goal: Ensure that software is always in a deployable state.

C. Continuous Deployment (CD)

Continuous Deployment goes one step further — automatically deploying every successful build to
production without manual approval.
Goal: Deliver features and fixes to users as soon as they are ready.

3. CI/CD Pipeline
A CI/CD pipeline is a set of automated stages that code goes through — from commit to deployment.
Typical pipeline stages:
Source Stage: Code is committed to a version control system.
Build Stage: Code is compiled and packaged.
Test Stage: Automated tests verify functionality.
Deploy Stage: Code is deployed to staging or production environments.
Monitor Stage: Logs and performance metrics are collected to monitor application health.
VTRICKS TECHNOLOGIES
 VTRICKS TECHNOLOGIES
A. Conceptual Introduction and Definition of Components

1. Introduction to GitHub Actions (GHA): GitHub Actions as a CI/CD tool or platform created by
GitHub and launched in August 2018. Its purpose is to automate tasks, deployment, and manual
workflows.

2. Identifying Key Components: GitHub Actions system is related to five core components:
◦ Workflow
◦ Jobs
◦ Events
◦ Actions
◦ Runners

3. Defining Components: Each component is defined to build foundational understanding:

◦ Workflow: A configurable, automated process that runs one or more jobs, similar to a simple
pipeline in Jenkins. Workflows are defined in YAML files located in the .github/workflows directory.

◦ Event: A specific activity (like a push, creating an issue, or raising a PR) in a repository that
triggers a workflow run.

◦ Job: A step that executes within a workflow, often using shell scripts or commands, running on
the same Runner. Jobs can be correlated to "stages" in a Jenkins pipeline.

◦ Runner: The environment where the workflow runs. Runners can be GitHub hosted (default) or
self-hosted.

◦ Action: A set of custom applications provided by GitHub that can be reused without writing code
repeatedly (e.g., the checkout action).

4. Reviewing a Simple Workflow Structure: A simple YAML file structure is presented to visually
correlate the five components (Name, on event, jobs, runs-on runner, and uses action).

B. Practical Demonstration: Creating the First Workflow

1. Repository Creation: create a new, fresh, private repository named GitHub action demo,
initializing it with a README file.

2. Workflow Setup:
◦ navigate to the Actions tab.
◦ A pre-built simple workflow template is used by clicking "configure".
◦ This action automatically creates the necessary directory structure: .github/workflows and a file
named [Link].

3. Customizing the Workflow (First Demo): The pre-built code is customized and reviewed:
◦ The workflow name is set to first workflow.
◦ The event triggers are configured for push or pull request on the Master Branch, and include
workflow_dispatch to allow manual execution.
◦ The Job is configured to run on the ubuntu-latest Runner.
◦ The steps include using the actions/checkout@v3 action and executing a basic command.
 VTRICKS TECHNOLOGIES
4. Initial Execution and Verification:
◦ The changes are committed.
◦ The workflow status is immediately checked in the Actions tab, showing success.
◦ The logs are opened to verify that the simple command successfully executed and printed the
expected output.

5. Testing Event Triggers (Push and Manual):

◦ Testing Push: The workflow file is edited, changing the output message to create a dummy
commit. This verifies that the workflow triggers immediately upon the push event, runs, and
completes successfully.
◦ Testing Manual Trigger: The workflow_dispatch event is tested by manually triggering the
workflow via the "Run workflow" option in the Actions tab.

6. Testing Workflow Disabling: To show control over workflow execution, the instructor manually
disables the workflow. A dummy change is then made in the README file to confirm that the disabled
workflow does not trigger.

7. Conclusion: The video concludes by reiterating the successful creation of the first basic workflow
and previews plans for future videos covering more complex topics like different Runners, custom
actions, and limitations.

2. Scripts and Commands Used to Explain

A. Conceptual Workflow Structure (Displayed in Text)

The following structure was used to illustrate the five components before the live demo:
Workflow
Example Script Snippet Explanation
Component
Name name: Name of workflow Gives the name of the workflow.
Triggers the workflow on a push event (can include
Event on: push
branch filters).
Defines the start of jobs, with build being the job
Job (Name) jobs: followed by build:
name.
Specifies the Runner environment (a GitHub hosted
Runner runs-on: ubuntu-latest
Ubuntu machine).
uses: A custom action used to check out the repository
Action
actions/checkout@v3 code.
run: whatever you want
Step/Command The command or shell script executed within the job.
here
 VTRICKS TECHNOLOGIES
B. First Live Demo Workflow ([Link])

Workflow
Snippet / Command Used Notes
Component
Name name: first workflow The chosen name for the workflow.
on: [push, pull_request] and Triggers on push or pull request on the Master
Events
workflow_dispatch: Branch, and allows manual running.
The job runs on the default GitHub hosted
Job / Runner runs-on: ubuntu-latest
Runner.
Checkout Standard custom action used to check out the
uses: actions/checkout@v3
Action code.
Initial The very first basic command executed in the
run: echo hello world
Command job.
Push Test This command replaced the initial one to test
run: echo learning get actions
Command the push trigger.

The output shown in the logs after the initial run confirms the execution of the command:
• hello world

The output shown in the logs after the push test confirms the execution of the updated command:

Create a new Repository

 VTRICKS TECHNOLOGIES
Go to actions and click on simple worflow

It will generate a yml file and then click on the commit message button.

Now if you check the workflow ran successfully

 VTRICKS TECHNOLOGIES
As mentioned in the workflow we are getting “Hello, world!” output

Second workflow

create a new github repository and clone it

Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions
$ git clone [Link]
Cloning into 'github-actions-demo2'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (3/3), done.
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions
$ cd github-actions-demo2/

Add file [Link] and test_app.py and push to remote repository

Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ vi [Link]
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ vi test_app.py
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ cat [Link]
def add(a, b):
return a + b
def subtract(a, b):
return a - b
if __name__ == "__main__":
print("Add:", add(2, 3))
print("Subtract:", subtract(5, 2))
 VTRICKS TECHNOLOGIES
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ cat test_app.py
import unittest
import app
class TestApp([Link]):
def test_add(self):
[Link]([Link](2, 3), 5)
def test_subtract(self):
[Link]([Link](5, 2), 3)
if __name__ == '__main__':
[Link]()

Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)

$ git add .
warning: in the working copy of '[Link]', LF will be replaced by CRLF the next time Git touches
it
warning: in the working copy of 'test_app.py', LF will be replaced by CRLF the next time Git
touches it
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ git commit -m "added two files"
[main bdf2d28] added two files
2 files changed, 23 insertions(+)
create mode 100644 [Link]
create mode 100644 test_app.py
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ git push origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 581 bytes | 581.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To [Link]
f3100e1..bdf2d28 main -> main

Go to github repo and create a new work file and add the new [Link] file with
content as
name: CI Pipeline (unittest)

on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

jobs:
test:
runs-on: ubuntu-latest

steps:
- name: Checkout code
uses: actions/checkout@v4

- name: Set up Python

uses: actions/setup-python@v5
with:
python-version: '3.x'

- name: Run unit tests

run: |
python -m unittest discover -s . -p "test_*.py"
 VTRICKS TECHNOLOGIES

Immediately once you commit the file, in actions you can see that the workflow will run immidiately.

Back on the repository’s Code tab, next to your last commit, you’ll see:

✅ if the CI run passed successfully

❌ if the CI run failed

Click the icon to jump directly to the pipeline logs.

 VTRICKS TECHNOLOGIES
Once again just change the code in the [Link] to get an error intentionally
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ git pull origin main
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 5 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (5/5), 1.27 KiB | 56.00 KiB/s, done.
From [Link]
* branch main -> FETCH_HEAD
bdf2d28..46b06d1 main -> origin/main
Updating bdf2d28..46b06d1
Fast-forward
.github/workflows/[Link] | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 .github/workflows/[Link]
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ vi [Link]
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ cat [Link]
def add(a, b):
return a + b + 1
def subtract(a, b):
return a - b
if __name__ == "__main__":
print("Add:", add(2, 3))
print("Subtract:", subtract(5, 2))

Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)

$ git add .
warning: in the working copy of '[Link]', LF will be replaced by CRLF the next time Git touches
it
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ git commit -m "added newline for intentional error"
[main 62db25a] added newline for intentional error
1 file changed, 1 insertion(+), 1 deletion(-)
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ git push origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 317 bytes | 317.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To [Link]
46b06d1..62db25a main -> main
 VTRICKS TECHNOLOGIES
Then again try to run with the correct code, so you will get the corrected workflow

Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)

$ git pull origin main
From [Link]
* branch main -> FETCH_HEAD
Already up to date.
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ vi [Link] \
> ^C
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ vi [Link]
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ git add .
warning: in the working copy of '[Link]', LF will be replaced by CRLF the next time Git touches
it
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ git commit -m "again added corrected file"
[main afa5ee4] again added corrected file
1 file changed, 1 insertion(+), 1 deletion(-)
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions/github-actions-demo2 (main)
$ git push origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To [Link]
62db25a..afa5ee4 main -> main
 VTRICKS TECHNOLOGIES
Advanced CI/CD Pipelines: Handling variables, deployment strategies, Case
Studies and Best Practices: Examples, maintenance tips.
 Variables: Non-sensitive values reused in multiple pipeline steps (e.g., app names, ports, region).

 Secrets: Sensitive credentials (e.g., API keys, tokens, passwords) securely stored and masked.

Create a new github repository

Launch an aws ec2 instnace

Follow the steps below

1. Click on launch instance

2. Provide name & choose instance AMI (i.e OS type)
3. Choose the instance type as [Link]
4. Create a Key pair to login to the server
5. Create security group allowing inbound rules with ports 22,80,443
6. Take storage as 8 gib
7. Click on launch instance
VTRICKS TECHNOLOGIES
VTRICKS TECHNOLOGIES
 VTRICKS TECHNOLOGIES

You will be getting a ec2 instance created with running state copy the public ip
 VTRICKS TECHNOLOGIES
To connect with the server, open gitbash and follow the below steps

Dell@DESKTOP-15GFHCD MINGW64 ~
$ cd Downloads/
Dell@DESKTOP-15GFHCD MINGW64 ~/Downloads
$ chmod 400 "nv_shiv.pem"
Dell@DESKTOP-15GFHCD MINGW64 ~/Downloads
$ ssh -i "nv_shiv.pem" ubuntu@[Link]
The authenticity of host '[Link] ([Link])' can't be
established.
ED25519 key fingerprint is SHA256:F3mEgl/boUm69z4uPEmeqCWTgB1JjzfxHnyu9+1Y2bQ.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[Link]' (ED25519) to the list of
known hosts.
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.14.0-1015-aws x86_64)
* Documentation: [Link]
* Management: [Link]
* Support: [Link]
System information as of Mon Nov 10 12:05:53 UTC 2025
System load: 0.08 Processes: 110
Usage of /: 25.8% of 6.71GB Users logged in: 0
Memory usage: 21% IPv4 address for enX0: [Link]
Swap usage: 0%
Expanded Security Maintenance for Applications is not enabled.
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
ubuntu@ip-172-31-21-97:~$
 VTRICKS TECHNOLOGIES
After loggin in to server update it first and then install apache-2 I.e web-server with commands
sudo apt update
sudo apt install apache2 -y
after that if you check the in any browser with your instance ip you will get it as

Then go to your repos setting and on left bar there will be section secrets and variables click on
that
 VTRICKS TECHNOLOGIES
Add the secrets
 VTRICKS TECHNOLOGIES
Add Varibles

sudo chown -R ubuntu:ubuntu /var/www/html

sudo chmod -R 755 /var/www/html
 VTRICKS TECHNOLOGIES
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions-demo3 (main)
$ git pull clone [Link]
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions-demo3 (main)
$ ls
[Link] [Link] [Link] [Link]

Change the content of [Link] & push it to the remote repository.

Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions-demo3 (main)
$ vi [Link]
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions-demo3 (main)
$ cat [Link]
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title> VTRICKS TECHNOLOGIES</title>
<link rel="stylesheet" href="[Link]">
</head>
<body>
<div class="overlay">
<div class="container">
<h1>Welcome to VTRICKS TECHNOLOGIES</h1>
<p id="envText"></p>
</div>
</div>
<script src="[Link]"></script>
</body>
</html>
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions-demo3 (main)
$ git add .
warning: in the working copy of '[Link]', LF will be replaced by CRLF the next time Git
touches it
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions-demo3 (main)
$ git commit -m "updated [Link]"
[main f77248d] updated [Link]
1 file changed, 1 insertion(+), 1 deletion(-)
Dell@DESKTOP-15GFHCD MINGW64 ~/Desktop/workshp_images/github-actions-demo3 (main)
$ git push origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 316 bytes | 158.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To [Link]
e957d3e..f77248d main -> main

Immidiately the code is pushed to main branch the updates will be deployed to
the server automatically.

You can check there will be a new workflow running , once the workflow
completes, then it deploy the changes to the server
VTRICKS TECHNOLOGIES
 VTRICKS TECHNOLOGIES
1. Deployment Strategies Overview
Blue-Green Deployment
Core Concept
Blue-Green deployment maintains two identical production environments called Blue (current
version) and Green (new version). Only one environment serves live traffic at any time.

Detailed Workflow
Current State: Blue environment handles 100% of production traffic
Deployment: New version is deployed to Green environment
Testing: Green environment undergoes thorough testing with synthetic traffic
Switch: Router/load balancer switches all traffic from Blue to Green
Rollback: If issues occur, instantly switch back to Blue

Load Balancer Configuration:

- Initially: 100% traffic → Blue environment
- After switch: 100% traffic → Green environment
- Blue environment remains running but idle

Database Considerations:
- Both environments typically share the same database
- Backward-compatible database changes required
- Schema migrations must work with both versions

Canary Deployment
Core Concept
Canary deployment gradually exposes the new version to a small subset of users, then slowly
increases traffic while monitoring key metrics.

Detailed Workflow
Initial Deployment: Deploy new version to a small percentage of infrastructure (1-10%)
Traffic Routing: Route small percentage of users (1-5%) to new version
Monitoring: Closely monitor metrics (error rates, performance, business KPIs)
Gradual Increase: If metrics are positive, gradually increase traffic (10% → 25% → 50% → 100%)
Rollback: If issues detected, route all traffic back to old version

Weighted Routing:
- Version A: 95% of traffic
- Version B: 5% of traffic

User-Based Routing:
- Internal users: 100% to new version
- Specific user segment: Partial traffic to new version
- Geographic routing: Specific regions get new version first
 VTRICKS TECHNOLOGIES
Rolling Deployment
Core Concept
Rolling deployment incrementally replaces instances of the old version with new version, one batch at
a time, while ensuring service availability.

Detailed Workflow
Health Checks: Verify current environment health
Batch Update: Take small batch of instances out of service
Deploy: Update instances to new version
Validate: Health checks and smoke tests on updated instances
Return to Service: Add updated instances back to load balancer
Repeat: Continue process until all instances are updated

Conservative Approach:
- Batch size: 10-20% of total instances
- Wait time: 5-10 minutes between batches
- Thorough validation between batches

Aggressive Approach:
- Batch size: 33-50% of total instances
- Wait time: 2-5 minutes between batches
- Faster deployment but higher risk

Real-world Case Studies

Case Study 1: E-commerce Platform
Challenge: High traffic during Black Friday, zero downtime required

Solution: Blue-Green with Feature Flags

Deployed new version alongside existing
Used feature flags for risky features
Database migrations performed beforehand
Switched DNS with 5-minute TTL

Result: Zero downtime, 30% faster checkout process

Case Study 2: FinTech Application

Challenge: Regulatory compliance, audit trails needed

Solution: Canary Deployment with Monitoring

1% traffic initially for 2 hours
Comprehensive monitoring (error rates, response times)
Gradual increase to 100% over 24 hours
Automatic rollback on anomaly detection

Result: 99.99% uptime, quick rollback capability

 VTRICKS TECHNOLOGIES
Best Practices: Examples, maintenance tips.
Best Practices for GitHub Actions CI/CD
1. Keep Workflows Modular
Instead of one big YAML, break it into multiple workflows:
Example:
[Link] → runs tests and builds
[Link] → handles deployment
Why: easier debugging and faster execution.

2. Use Secrets for Credentials

Never hard-code passwords, API keys, or IPs in the code.
Use GitHub Secrets instead.
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

3. Use Environment Variables

Helps differentiate between Development, Staging, and Production.
env:
ENVIRONMENT: "Development"

echo "Deploying to $ENVIRONMENT"

4. Add Notifications
Add Slack or Email notifications on pipeline success or failure.
- name: Notify on failure
if: failure()
run: echo "Deployment failed! Notifying team..."

5. Use actions/cache for Speed

Caches dependencies like node_modules or pip to save time.
- name: Cache Node modules
uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ [Link] }}-node-${{ hashFiles('**/[Link]') }}

6. Use Proper Branch Protection

Only deploy from stable branches like main or release.
on:
push:
branches:
- main
 VTRICKS TECHNOLOGIES
7. Add Linting and Testing Before Deploy
Always verify code before deploying it.
- name: Run Tests
run: pytest tests/

8. Use Manual Approvals for Production

Add a manual step before production deployment.
environment:
name: production
url: [Link]
protection_rules:
- reviewers: ['admin']