CI/CD tools automate the process of building, testing, and deploying software.

Popular tools include Jenkins, GitHub Actions, GitLab CI, and Tekton.

Jenkins
● What is it?
Open-source tool for automating software development tasks.
● Strengths:
○ Supports many plugins for customization.
○ Works with various version control systems (e.g., Git).
○ Great for complex workflows.
● Use Cases:
Building apps, running tests, deploying code, and managing large-scale
pipelines.

GitHub Actions

● What is it?
Built into GitHub to automate tasks like testing and deploying code.
● Strengths:
○ Easy to set up with GitHub repositories.
○ Supports cross-platform testing.
● Use Cases:
Automating workflows for projects hosted on GitHub.

GitLab CI

● What is it?
A CI/CD tool within GitLab for automating builds, tests, and deployments.
● Strengths:
○ Works seamlessly with GitLab repositories.
 ○ Built-in Docker support and debugging tools.
● Use Cases:
Managing pipelines, testing code, and deploying apps from GitLab.

Tekton

● What is it?
A Kubernetes-native CI/CD tool for cloud-native workflows.
● Strengths:
○ Designed for containerized builds.
○ Works well with Kubernetes and cloud tools.
● Use Cases:
Automating Kubernetes pipelines and scaling builds in the cloud.

Choosing the Right Tool

● Jenkins: Best for highly customizable and complex pipelines.

● GitHub Actions: Ideal for GitHub-hosted projects.
● GitLab CI: Perfect for teams using GitLab repositories.
● Tekton: Suited for Kubernetes and cloud-native environments.

Each tool caters to specific needs. Pick the one that matches your workflow and
infrastructure.

Comparison

Comparison of CI/CD Tools: Jenkins, GitHub Actions, GitLab CI, and Tekton
Jenkins

● Overview: Open-source and widely used; highly flexible with thousands of

plugins.
● Features:
○ Supports complex pipelines with code (Jenkinsfile).
○ Integrates with many tools and environments.
○ Handles distributed builds and complex workflows.
● Strengths:
○ Highly customizable.
○ Supports various languages and tools.
○ Works in diverse environments (cloud, on-prem).
● Best For: Complex setups, legacy tool integration, and diverse build needs.

GitHub Actions

● Overview: GitHub’s built-in CI/CD tool; tightly integrated with GitHub

repositories.
● Features:
○ Easy to configure with workflow files.
○ Runs jobs on multiple platforms (Linux, Windows, macOS).
○ Supports event-driven workflows like pushes or pull requests.
● Strengths:
○ Simplifies CI/CD for GitHub-hosted projects.
○ No need for external servers.
● Best For: Small to medium projects hosted on GitHub.

GitLab CI

● Overview: Fully integrated CI/CD tool within GitLab for complete DevOps
lifecycle management.
 ● Features:
○ Configured using .gitlab-ci.yml.
○ Supports Docker and Kubernetes natively.
○ Provides built-in security and Auto DevOps pipelines.
● Strengths:
○ Complete DevOps platform in one tool.
○ Strong container and cloud support.
● Best For: Teams using GitLab for version control and end-to-end DevOps.

Tekton

● Overview: Open-source framework for Kubernetes-based CI/CD

workflows.
● Features:
○ Designed for Kubernetes with reusable tasks and pipelines.
○ Executes tasks in parallel and supports cloud-native applications.
● Strengths:
○ Perfect for modern, containerized applications.
○ Highly customizable for Kubernetes environments.
● Best For: Cloud-native teams using Kubernetes.

Comparative Summary
Feature Jenkins GitHub GitLab CI Tekton
Actions

Configuration Groovy-based (workflow (Pipeline &

(Jenkinsfile) files) (.gitlab-ci.y Task files)
ml)
Integration Plugins (wide Native to Fully Kubernetes-nati
integration) GitHub integrated ve
with GitLab

Use Case Complex GitHub-cent End-to-end Kubernetes &

multi-step ric DevOps Cloud-native
workflows workflows lifecycle CI/CD

CI/CD Flexible but Simple and Automated Cloud-native,

Workflow can be event-driven with Auto task-based
Setup complex DevOps

Runner/Execut Master/Slave GitHub-host GitLab-host Kubernetes

or architecture ed or ed or Pods
self-hosted self-hosted

Supported Linux, Linux, Linux, Kubernetes

Platforms Windows, Windows, Windows, (Cloud-native)
macOS macOS macOS

Docker Good (via Good Native Native Docker

Support plugins) (Docker Docker and Kubernetes
containers) support support

Parallel/Matrix Yes (via Yes (matrix Yes (via Yes (via parallel
Builds pipeline steps) strategy) parallel tasks)
jobs)

Scalability Horizontal GitHub-host GitLab-runn Kubernetes-nati

scaling via ed scaling er scaling ve scaling
agents

Best For Complex GitHub DevOps Kubernetes-first

projects with users and with environments
legacy tools small teams integrated
tools

Conclusion:
 ● Jenkins is best suited for highly customizable pipelines, particularly for
organizations that need a wide range of integrations or have legacy systems.
● GitHub Actions is ideal for teams already using GitHub, as it offers an
easy-to-use, event-driven CI/CD solution integrated directly into the GitHub
ecosystem.
● GitLab CI provides a complete DevOps platform and is perfect for teams
that are heavily integrated with GitLab and want a full end-to-end solution.
● Tekton is designed for cloud-native, Kubernetes-based environments,
offering flexibility and scalability for teams using modern containerized
applications.

Configuration Files Examples

A Jenkinsfile (Declarative Pipeline) is a way to define a continuous integration and delivery

pipeline in Jenkins using a structured, easy-to-read syntax. It provides clear separation of
stages and supports defining variables, environment settings, and post-build actions.

Jenkinsfile (Declarative Pipeline)

Example 1:

groovy

pipeline {
agent any
environment {
MY_ENV_VAR = 'SomeValue'
}
stages {
stage('Checkout') {
 steps {
checkout scm
}
}
stage('Build') {
steps {
script {
echo "Building the project..."
sh './mvn clean install'
}
}
}
stage('Test') {
steps {
script {
echo "Running tests..."
sh './mvn test'
}
}
}
stage('Deploy') {
steps {
script {
echo "Deploying to production..."
sh 'scp target/*.jar user@prod-server:/opt/myapp/'
}
}
}
}
post {
always {
echo 'Cleaning up resources'
}
success {
echo 'Build and Deployment Succeeded!'
 }
failure {
echo 'Build or Deployment Failed'
}
}
}

Explanation:

● Agent: Specifies the execution environment for the pipeline.

● Environment Variables: Defines the environment variable MY_ENV_VAR
to be used throughout the pipeline.
● Stages:
○ Checkout: Pulls the latest code from the version control system.
○ Build: Runs a Maven build command to compile the project.
○ Test: Executes tests to ensure the build is successful.
○ Deploy: Deploys the built application to a production server.
● Post-actions:
○ Always: Always run cleanup actions.
○ Success: Displays a message when the build and deployment are
successful.
○ Failure: Displays a message if the build or deployment fails.

Example 2

Jenkins Declarative Pipeline with Docker Build and Push:

This Jenkins Declarative Pipeline is designed to automate the process of building

and deploying a Docker container for a Node.js application using Docker and
Jenkins. The pipeline structure includes an agent, environment variables, stages,
and a post-build section.
groovy

pipeline {
agent {
docker { image 'node:14' }
}
environment {
DOCKER_REGISTRY = "docker.io"
IMAGE_NAME = "my-node-app"
}
stages {
stage('Checkout Code') {
steps {
checkout scm
}
}
stage('Install Dependencies') {
steps {
sh 'npm install'
}
}
stage('Build Docker Image') {
steps {
script {
def image =
docker.build("${DOCKER_REGISTRY}/${IMAGE_NAME}:${env.BUILD_ID}
")
image.push()
}
}
}
stage('Deploy') {
steps {
 script {
// Sample deploy command
sh 'docker run -d -p 3000:3000
${DOCKER_REGISTRY}/${IMAGE_NAME}:${env.BUILD_ID}'
}
}
}
}
post {
always {
cleanWs()
}
success {
echo 'Deployment Successful'
}
failure {
echo 'Deployment Failed'
}
}
}

● Explanation:
○ Docker Agent: Jenkins is using the node:14 Docker image.
○ Stages: Checkout code, install dependencies, build Docker image, and
deploy.
○ Push to Docker Registry: The image is tagged with the build ID and
pushed to Docker Hub.

Example 3

Jenkins Pipeline with Slack Notifications:

This Jenkins pipeline example demonstrates a CI/CD workflow that integrates
Slack notifications to inform a team about the status of deployments.

groovy

pipeline {
agent any
environment {
SLACK_CHANNEL = '#ci-cd-notifications'
SLACK_TOKEN = credentials('slack-webhook-token')
}
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Build') {
steps {
script {
echo "Building the project..."
sh 'mvn clean install'
}
}
}
stage('Test') {
steps {
script {
echo "Running tests..."
sh 'mvn test'
}
}
}
 stage('Deploy') {
steps {
script {
echo "Deploying to production..."
sh 'scp target/*.jar user@prod-server:/opt/myapp/'
}
}
}
}
post {
success {
script {
slackSend(channel: SLACK_CHANNEL, message: "Deployment
Successful! :white_check_mark:")
}
}
failure {
script {
slackSend(channel: SLACK_CHANNEL, message: "Deployment Failed!
:x:")
}
}
}
}

● Explanation:
○ Slack Notifications: Sends a success or failure notification to a Slack
channel using a webhook.
○ Stages: Checkout, build, test, and deploy.

Example 4
Jenkins Pipeline with Slack Notifications and Docker Build:

This Jenkins pipeline example integrates Docker and Slack notifications to

automate the process of building, testing, and pushing a Docker image.

groovy

pipeline {
agent any
environment {
DOCKER_IMAGE = "myapp"
SLACK_CHANNEL = "#build-notifications"
SLACK_CREDENTIALS = credentials('slack-webhook')
}
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Build Docker Image') {
steps {
script {
echo "Building Docker Image..."
sh "docker build -t ${DOCKER_IMAGE}:${BUILD_ID} ."
}
}
}
stage('Test') {
steps {
script {
echo "Running Tests..."
sh "docker run ${DOCKER_IMAGE}:${BUILD_ID} test"
}
 }
}
stage('Push Docker Image') {
steps {
script {
echo "Pushing Docker Image..."
withCredentials([usernamePassword(credentialsId: 'docker-hub',
usernameVariable: 'DOCKER_USER', passwordVariable: 'DOCKER_PASS')]) {
sh "echo $DOCKER_PASS | docker login -u $DOCKER_USER
--password-stdin"
sh "docker push ${DOCKER_IMAGE}:${BUILD_ID}"
}
}
}
}
}
post {
success {
slackSend(channel: SLACK_CHANNEL, message: "Build ${BUILD_ID}
succeeded!")
}
failure {
slackSend(channel: SLACK_CHANNEL, message: "Build ${BUILD_ID}
failed!")
}
always {
cleanWs()
}
}
}

● Explanation:
○ Slack Notifications: Sends a Slack message on success or failure of
the build process.
 ○ Docker Build: Builds a Docker image and pushes it to Docker Hub
after testing.

Example 5

Jenkins Pipeline with GitHub Integration:

In this Jenkins Pipeline example, the user has created a pipeline that integrates with
GitHub to automate the build and deployment process of a project.

groovy

pipeline {
agent any
environment {
GIT_REPO_URL = "https://github.com/my-org/my-repo.git"
}
stages {
stage('Checkout') {
steps {
git url: "${GIT_REPO_URL}", branch: 'main'
}
}
stage('Build') {
steps {
script {
echo "Building project..."
sh 'mvn clean install'
}
}
}
stage('Test') {
 steps {
script {
echo "Running unit tests..."
sh 'mvn test'
}
}
}
stage('Deploy') {
steps {
script {
echo "Deploying to server..."
sh 'scp target/*.jar user@prod-server:/opt/myapp/'
}
}
}
}
post {
success {
echo "Build successful!"
}
failure {
echo "Build failed!"
}
}
}

1. GitHub Integration: The pipeline pulls the project code from a GitHub
repository (specified by the GIT_REPO_URL environment variable). The
repository is checked out in the Checkout stage using the git command.
2. Build: In the Build stage, Maven is used to clean and build the project
with the mvn clean install command, compiling the necessary files.
3. Test: The pipeline runs unit tests in the Test stage using the mvn test
command to ensure that the code functions as expected.
 4. Deploy: Once the build and tests pass, the Deploy stage transfers the build
artifact (a .jar file) to a production server via scp.
5. Post Actions: After the pipeline finishes, the post block notifies the user
about the build status, either success or failure, to provide feedback on the
pipeline's outcome.

This example demonstrates how Jenkins can automate the process of pulling code
from GitHub, building, testing, and deploying applications, along with notifying
the user of the build's success or failure.

Example 6

Jenkins Pipeline with SonarQube Integration:

This Jenkins pipeline integrates SonarQube for static code analysis in a Java
project. It includes stages for checking out the code, building the project, running
SonarQube analysis, and deploying the application. The pipeline ensures that code
quality is assessed through SonarQube before deployment.

groovy

pipeline {
agent any

environment {
SONARQUBE = 'SonarQube' // Name of the SonarQube server configured in
Jenkins
SONAR_PROJECT_KEY = 'my-project-key'
SONAR_PROJECT_NAME = 'My Project'
 SONAR_PROJECT_VERSION = '1.0'
}

stages {
stage('Checkout') {
steps {
checkout scm
}
}

stage('Build') {
steps {
script {
echo "Building project..."
sh 'mvn clean install'
}
}
}

stage('SonarQube Analysis') {
steps {
script {
echo "Running SonarQube Analysis..."
sh """
mvn sonar:sonar \
-Dsonar.projectKey=${SONAR_PROJECT_KEY} \
-Dsonar.projectName=${SONAR_PROJECT_NAME} \
-Dsonar.projectVersion=${SONAR_PROJECT_VERSION} \
-Dsonar.host.url=http://localhost:9000
"""
}
}
}

stage('Deploy') {
 steps {
script {
echo "Deploying to server..."
// Add your deployment steps here
}
}
}
}

post {
success {
echo "Build and SonarQube analysis succeeded!"
}
failure {
echo "Build or SonarQube analysis failed!"
}
}
}

● Explanation:
○ The SonarQube Analysis stage runs the SonarQube analysis using
Maven’s sonar:sonar goal.
○ You need to configure SonarQube in Jenkins and provide the correct
SonarQube URL and Project Key.
○ The analysis will be triggered after the build process and will give
feedback on the quality of the code.

Example 7

Jenkinsfile (Declarative Pipeline with Parallel Stages)

This Jenkinsfile defines a declarative pipeline that includes parallel execution within the Build
& Test stage. It demonstrates how to execute multiple tasks (build and unit tests) concurrently
to optimize the CI/CD process. The pipeline consists of stages for checking out the code,
building and testing the project in parallel, and deploying the application, with post-build actions
to indicate success or failure.

groovy

pipeline {
agent any
stages {
stage('Checkout') {
steps {
git 'https://github.com/my-repo.git'
}
}
stage('Build & Test') {
parallel {
stage('Build') {
steps {
script {
echo 'Building the project...'
sh './build.sh'
}
}
}
stage('Unit Tests') {
steps {
script {
echo 'Running unit tests...'
sh './run_tests.sh'
}
}
}
}
}
 stage('Deploy') {
steps {
script {
echo 'Deploying to the server...'
sh './deploy.sh'
}
}
}
}
post {
success {
echo 'Pipeline completed successfully!'
}
failure {
echo 'Pipeline failed!'
}
}
}

● Explanation: This Jenkins pipeline uses parallel execution in the Build &
Test stage to run the build and unit test jobs simultaneously. After these jobs
are complete, the deployment will proceed.

Example 8

Advanced Jenkins Example: Declarative Pipeline with Matrix and

Notifications

Jenkinsfile (Matrix Build with Slack Notifications)

This Jenkinsfile demonstrates an advanced Jenkins pipeline using a Declarative Pipeline
syntax, integrating a Matrix build and Slack notifications. The pipeline is structured into
multiple stages:

● Checkout: The code is retrieved from a Git repository.

● Build & Test: This stage uses a matrix configuration to run tests with different versions
of Node.js. It installs dependencies and runs tests for each version (12, 14, 16) in
parallel.
● Deploy: This stage deploys the project using a shell script.

groovy

pipeline {
agent any

environment {
SLACK_CHANNEL = '#ci-channel'
SLACK_TOKEN = credentials('slack-token')
}

stages {
stage('Checkout') {
steps {
git 'https://github.com/my-repo.git'
}
}

stage('Build & Test') {

matrix {
axes {
axis {
name 'NODE_VERSION'
values '12', '14', '16'
}
}
stages {
 stage('Install Dependencies') {
steps {
script {
echo "Installing dependencies for Node.js
${NODE_VERSION}..."
sh "nvm install ${NODE_VERSION} && npm install"
}
}
}
stage('Run Tests') {
steps {
script {
echo "Running tests on Node.js ${NODE_VERSION}..."
sh "npm test"
}
}
}
}
}
}

stage('Deploy') {
steps {
script {
echo 'Deploying the project...'
sh './deploy.sh'
}
}
}
}

post {
success {
slackSend (channel: SLACK_CHANNEL, message: 'Pipeline succeeded!',
token: SLACK_TOKEN)
 }
failure {
slackSend (channel: SLACK_CHANNEL, message: 'Pipeline failed.',
token: SLACK_TOKEN)
}
}
}

● Explanation: This Jenkinsfile runs the Build & Test stage with different
versions of Node.js using a matrix configuration. After the pipeline
completes, it sends Slack notifications about the success or failure of the
build.

Example 9

Jenkins Pipeline with Parallel Test Execution:

This example demonstrates a Jenkins pipeline that performs parallel test execution
for unit tests and integration tests, optimizing the testing phase and reducing
overall pipeline runtime.

groovy

pipeline {
agent any
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Build') {
steps {
 script {
echo "Building the project..."
sh 'mvn clean install'
}
}
}
stage('Test') {
parallel {
stage('Unit Tests') {
steps {
script {
echo "Running unit tests..."
sh 'mvn test -Dtest=UnitTests'
}
}
}
stage('Integration Tests') {
steps {
script {
echo "Running integration tests..."
sh 'mvn test -Dtest=IntegrationTests'
}
}
}
}
}
stage('Deploy') {
steps {
script {
echo "Deploying to production..."
sh 'scp target/*.jar user@prod-server:/opt/myapp/'
}
}
}
}
}

● Explanation:
○ Parallel Execution: The test stage runs both unit tests and integration
tests in parallel, reducing overall pipeline runtime.
○ Maven Build: A Maven build and deployment process is included.

Example 10

Jenkins Pipeline with Trivy for Container Scanning:

The provided Jenkins Pipeline integrates Trivy for container scanning. Trivy is a
vulnerability scanner for Docker images, and this pipeline performs a scan on a
Docker image after building it. The pipeline includes stages for checking out code,
building the Docker image, running the Trivy scan, and deploying the application.
The scan checks the Docker image for vulnerabilities, and the results are reported
in the post-build steps, with success or failure messages depending on the outcome.
The Docker socket is mounted to allow Trivy to interact with Docker for scanning.

groovy

pipeline {
agent any

environment {
TRIVY_IMAGE = 'aquasec/trivy:latest' // Docker image for Trivy
DOCKER_IMAGE = 'my-docker-image:latest' // Your Docker image to scan
}

stages {
stage('Checkout') {
steps {
checkout scm
}
 }

stage('Build Docker Image') {

steps {
script {
echo "Building Docker image..."
sh 'docker build -t ${DOCKER_IMAGE} .'
}
}
}

stage('Trivy Scan') {
steps {
script {
echo "Running Trivy scan on Docker image..."
sh """
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
${TRIVY_IMAGE} ${DOCKER_IMAGE}
"""
}
}
}

stage('Deploy') {
steps {
script {
echo "Deploying application..."
// Add your deployment steps here
}
}
}
}

post {
success {
 echo "Build and Trivy scan succeeded!"
}
failure {
echo "Build or Trivy scan failed!"
}
}
}

● Explanation:
○ Trivy Scan: The docker run command pulls the Trivy Docker image
and scans the built Docker image for vulnerabilities.
○ Docker Socket: The -v /var/run/docker.sock:/var/run/docker.sock
allows Trivy to interact with Docker to scan the image.

Example 11

Jenkins Pipeline for Selenium Tests:

Jenkins Pipeline for Selenium Tests: This Jenkins pipeline is designed to

automate the process of running Selenium tests within a Docker container. It
defines several stages such as checkout, build, test execution, and deployment. The
pipeline uses the official Selenium Docker image with a Chrome browser and
ChromeDriver, runs the Selenium test script inside the container, and then handles
deployment. This setup helps ensure consistent testing and smooth application
deployment.

groovy

pipeline {
agent any

environment {
 SELENIUM_IMAGE = 'selenium/standalone-chrome:latest' // Selenium
Docker image with Chrome
CHROME_DRIVER = '/usr/local/bin/chromedriver' // Path for ChromeDriver
}

stages {
stage('Checkout') {
steps {
checkout scm
}
}

stage('Build') {
steps {
script {
echo "Building the application..."
// Add your build steps here, e.g., `mvn clean install`
}
}
}

stage('Run Selenium Tests') {

steps {
script {
echo "Running Selenium tests..."
// Run Selenium tests inside a Docker container
sh """
docker run --rm -v \$(pwd)/tests:/tests -v \$(pwd)/build:/build \
-e CHROME_DRIVER=${CHROME_DRIVER}
${SELENIUM_IMAGE} \
python3 /tests/run_selenium_tests.py
"""
}
}
}
 stage('Deploy') {
steps {
script {
echo "Deploying the application..."
// Add your deployment steps here
}
}
}
}

post {
success {
echo "Build and tests succeeded!"
}
failure {
echo "Build or tests failed!"
}
}
}

● Explanation:
○ Selenium Docker Image: Uses the official
selenium/standalone-chrome image for running Selenium tests in a
Chrome browser.
○ Test Execution: The Selenium test script run_selenium_tests.py is run
inside the Docker container, and it mounts the tests and build
directories.

GitHub Actions Examples

Example 1

GitHub Actions Workflow Example (.github/workflows/ci.yml)

This is a GitHub Actions workflow configuration that automates the process of

continuous integration (CI) for a Node.js project. It is triggered when code is
pushed to the main branch or when a pull request is made to it. The workflow runs
tests and deploys the application across different versions of Node.js (12.x, 14.x,
and 16.x). The steps include checking out the repository, setting up Node.js,
installing dependencies, running tests, and deploying the application.

name: Node.js CI
on:
push:
branches:
- main
pull_request:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [12.x, 14.x, 16.x]

steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
 with:
node-version: ${{ matrix.node-version }}
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
- name: Deploy
run: |
echo "Deploying to production..."
# Add your deployment command here

● Explanation:
○ Trigger: Runs on push to main and pull requests.
○ Matrix Strategy: Runs jobs across multiple Node.js versions.
○ Steps: Checkout, setup Node.js, install dependencies, run tests, and
deploy.

Example 2

GitHub Actions Workflow with Cache for Dependencies:

A GitHub Actions Workflow with Cache for Dependencies automates the

process of building, testing, and deploying a Python application. It speeds up
builds by caching pip dependencies and runs tasks like checking out code, setting
up Python, installing dependencies, running tests, and deploying the application.
Caching ensures that dependencies are reused, improving build efficiency.

name: Python CI/CD

on:
push:
 branches:
- main
pull_request:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3

- name: Set up Python

uses: actions/setup-python@v3
with:
python-version: 3.9

- name: Cache dependencies

uses: actions/cache@v3
with:
path: ~/.cache/pip
key: ${{ runner.os }}-python-${{ hashFiles('**/requirements.txt') }}
restore-keys: |
${{ runner.os }}-python-

- name: Install dependencies

run: |
python -m pip install --upgrade pip
pip install -r requirements.txt

- name: Run tests

run: |
pytest tests/
 - name: Deploy to production
run: |
echo "Deploying application..."
# Add deployment commands here

● Explanation:
○ Cache: Uses caching to store pip dependencies, speeding up builds.
○ Jobs: The pipeline includes checking out code, setting up Python,
caching dependencies, running tests, and deploying.

Example 3

GitHub Actions with Conditional Deployment Based on Branch:

This demonstrates the integration of GitHub Actions for automating the CI/CD
pipeline of a Node.js application. The workflow is structured to automatically
build, test, and deploy the application based on branch-specific conditions. It runs
on pushes to the main and develop branches, ensuring that every code change is
tested and built. The deployment step is conditionally triggered only for changes
pushed to the main branch, ensuring that only production-ready code is deployed.
This setup streamlines the process of managing code quality and deployment,
making it more efficient and reliable for continuous integration and delivery.

name: Node.js CI/CD

on:
push:
branches:
- main
- develop
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3

- name: Set up Node.js

uses: actions/setup-node@v3
with:
node-version: '16'

- name: Install dependencies

run: npm install

- name: Run tests

run: npm test

deploy:
runs-on: ubuntu-latest
needs: build
if: github.ref == 'refs/heads/main'
steps:
- name: Checkout code
uses: actions/checkout@v3

- name: Deploy to Production

run: |
echo "Deploying to production server..."
# Add deployment script/commands here

● Explanation:
 ○ Conditional Deployment: The deployment job only runs if the push
is to the main branch, enabling conditional deployments based on
branches.
○ Node.js Setup and Testing: Sets up Node.js, installs dependencies,
and runs tests before deployment.

Example 4

GitHub Actions Workflow for Docker Build and Push:

This automates the process of building and pushing Docker images using GitHub
Actions. It defines a CI/CD workflow that triggers on pushes to the main branch.
The workflow checks out the code, sets up Docker Buildx for multi-platform
builds, creates a Docker image tagged with the commit SHA, and pushes it to
Docker Hub. Finally, it logs out from Docker Hub after the process is complete.
This setup streamlines the Docker build and deployment process, ensuring
consistency and efficiency.

name: Docker CI/CD

on:
push:
branches:
- main

jobs:
docker:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
 - name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2

- name: Build Docker image

run: |
docker buildx build --tag mydockerhubuser/myapp:${{ github.sha }} --push
.

- name: Logout from Docker Hub

run: docker logout

● Explanation:
○ Docker Build and Push: The workflow builds a Docker image and
pushes it to Docker Hub with a tag based on the commit SHA.
○ Docker Buildx: Uses Docker Buildx to enable building images for
different platforms.

Example 5

GitHub Actions Workflow for Deploying to AWS ECS:

This GitHub Actions workflow automates the process of deploying a Docker

application to AWS ECS. It is triggered on every push to the main branch. The
workflow builds a Docker image, pushes it to AWS ECR, and then deploys it to an
ECS cluster using the ECS deploy command. AWS credentials are securely
configured through GitHub secrets, ensuring seamless integration with AWS
services for continuous deployment.
name: Deploy to AWS ECS

on:
push:
branches:
- main

jobs:
build-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3

- name: Set up AWS CLI

uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-1

- name: Build Docker image

run: |
docker build -t myapp:${{ github.sha }} .

- name: Log in to Amazon ECR

run: |
aws ecr get-login-password --region us-east-1 | docker login --username
AWS --password-stdin <aws_account_id>.dkr.ecr.us-east-1.amazonaws.com

- name: Push Docker image to ECR

run: |
docker tag myapp:${{ github.sha }}
<aws_account_id>.dkr.ecr.us-east-1.amazonaws.com/myapp:${{ github.sha }}
 docker push
<aws_account_id>.dkr.ecr.us-east-1.amazonaws.com/myapp:${{ github.sha }}

- name: Deploy to AWS ECS

run: |
ecs-deploy --cluster my-cluster --service-name my-service --image
<aws_account_id>.dkr.ecr.us-east-1.amazonaws.com/myapp:${{ github.sha }}

● Explanation:
○ AWS ECS Deployment: This example deploys a Docker image to
AWS ECS after building it.
○ AWS CLI Setup: Configures AWS CLI to authenticate and deploy to
AWS.
○ Docker to ECR: Pushes the Docker image to Amazon Elastic
Container Registry (ECR).

Example 6

GitHub Actions with Dependency Caching for Faster Builds:

This demonstrates integrating GitHub Actions with SonarQube to automate code

quality analysis. It triggers a build and SonarQube analysis on pushes to the main
branch. The workflow sets up JDK 11, checks out the code, caches Maven
dependencies, and runs a Maven build followed by a SonarQube analysis using a
pre-configured token. The goal is to streamline the build and analysis process,
ensuring consistent code quality checks for every commit.

name: CI with Cache

on:
 push:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest

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

- name: Cache Node.js modules

uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-node-modules-${{ hashFiles('**/package-lock.json')
}}
restore-keys: |
${{ runner.os }}-node-modules-

- name: Set up Node.js

uses: actions/setup-node@v3
with:
node-version: '16'

- name: Install dependencies

run: npm install

- name: Run tests

run: npm test

● Explanation:
 ○ Caching: Uses GitHub Actions cache to store Node.js dependencies
and speeds up builds.
○ Optimized Build Process: Caches node_modules to avoid reinstalling
dependencies on each run.

Example 7

GitHub Actions with SonarQube:

This example demonstrates using GitHub Actions to automate the build and code
quality analysis process with SonarQube. The workflow triggers on push events to
the main branch, sets up JDK 11, caches Maven dependencies, and performs a
Maven build followed by a SonarQube analysis. The integration ensures that each
commit is analyzed for code quality using SonarQube, with a token stored as a
GitHub secret for authentication.

name: Build and Analyze with SonarQube

on:
push:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest

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

- name: Set up JDK 11

 uses: actions/setup-java@v3
with:
java-version: '11'

- name: Cache SonarQube dependencies

uses: actions/cache@v3
with:
path: ~/.m2/repository
key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
restore-keys: |
${{ runner.os }}-maven-

- name: Build and Analyze with Maven

run: |
mvn clean install
mvn sonar:sonar \
-Dsonar.projectKey=my-project-key \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=${{ secrets.SONARQUBE_TOKEN }}

● Explanation:
○ SonarQube Token: You will need to create a SonarQube Token and
store it as a GitHub secret (SONARQUBE_TOKEN) to authenticate
the analysis.
○ The Build and Analyze with Maven step runs the SonarQube
analysis after the Maven build.
○ It caches the Maven dependencies to speed up the process in future
runs.

Example 8
GitHub Actions with Trivy for Docker Scanning:

This example demonstrates how to integrate GitHub Actions with Trivy for Docker
image scanning. It triggers the workflow on pushes to the main branch, builds a
Docker image, and then uses the Trivy action to scan the image for vulnerabilities.
The integration simplifies security checks in your CI pipeline by automatically
scanning Docker images for issues using Trivy.

name: Build and Scan Docker Image with Trivy

on:
push:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest

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

- name: Set up Docker Buildx

uses: docker/setup-buildx-action@v2

- name: Build Docker Image

run: |
docker build -t my-docker-image:latest .

- name: Scan Docker Image with Trivy

uses: aquasecurity/trivy-action@v0.4.0
with:
image: my-docker-image:latest
 ● Explanation:
○ Trivy Action: GitHub Actions provides a prebuilt action
aquasecurity/trivy-action, which makes it easy to run Trivy in your CI
pipeline.
○ The image parameter specifies the Docker image to scan.

Example 9

GitHub Actions for Selenium Test Automation:

This example demonstrates how to set up GitHub Actions for Selenium test
automation. It triggers the workflow on a push to the main branch, running tests
on an ubuntu-latest runner. The workflow includes setting up a Selenium
service using the selenium/standalone-chrome Docker container,
configuring Python 3.8, installing dependencies, and running the Selenium tests
using a Python script.

name: Selenium Tests

on:
push:
branches:
- main

jobs:
selenium-tests:
runs-on: ubuntu-latest

services:
selenium:
 image: selenium/standalone-chrome
options: --shm-size 2g

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

- name: Set up Python

uses: actions/setup-python@v4
with:
python-version: '3.8'

- name: Install dependencies

run: |
pip install -r requirements.txt

- name: Run Selenium tests

run: |
python3 tests/run_selenium_tests.py

● Explanation:
○ Selenium Service: The selenium/standalone-chrome Docker container
is used as a service in the GitHub Actions workflow.
○ Python Setup: The workflow sets up Python and installs the
necessary dependencies from requirements.txt before running the
Selenium tests.

Example 10

name: CI Workflow
on:
push:
branches:
- main
pull_request:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest

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

- name: Set up Node.js

uses: actions/setup-node@v3
with:
node-version: '16'

- name: Install dependencies

run: npm install

- name: Run tests

run: npm test

- name: Build project

run: npm run build

- name: Deploy
run: ./deploy.sh
 ● Explanation: This GitHub Actions workflow triggers on pushes and pull
requests to the main branch. It sets up a Node.js environment, installs
dependencies, runs tests, and deploys the application using a custom shell
script.

Example 11

GitHub Actions Workflow with Multiple Jobs and Docker:

This GitHub Actions workflow defines a CI/CD pipeline with multiple jobs,
specifically for building and deploying a Dockerized application.

Workflow Overview:

● Trigger: The pipeline runs when changes are pushed to the main branch or
a pull request is made to it.
● Jobs:
○ Build Job:
■ Sets up a Node.js environment and installs dependencies.
■ Runs tests and builds a Docker image.
■ Tags the image with the GitHub SHA and pushes it to Docker
Hub.
○ Deploy Job:
■ After the build job completes, it pulls the Docker image from
Docker Hub and deploys it to a production server using SSH.

This setup automates the process of building, testing, and deploying a Dockerized
application, ensuring that each deployment uses the latest successful build.

name: CI/CD Pipeline

on:
push:
branches:
- main
pull_request:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '16'
- name: Install Dependencies
run: npm install
- name: Run Tests
run: npm test
- name: Build Docker Image
run: |
docker build -t myapp:${{ github.sha }} .
docker tag myapp:${{ github.sha }} mydockerhub/myapp:${{ github.sha }}
docker push mydockerhub/myapp:${{ github.sha }}

deploy:
runs-on: ubuntu-latest
needs: build
steps:
- name: Checkout Code
uses: actions/checkout@v3
 - name: Deploy to Production
run: |
ssh user@prod-server 'docker pull mydockerhub/myapp:${{ github.sha }}
&& docker run -d mydockerhub/myapp:${{ github.sha }}'

● Explanation:
○ Jobs: build and deploy jobs.
○ Build Job: This job installs Node.js, runs tests, builds a Docker
image, and pushes it to Docker Hub.
○ Deploy Job: After the build job completes, the deploy job pulls the
Docker image from Docker Hub and deploys it to a production server.

Example 12

GitHub Actions Workflow (With Matrix Builds)

This GitHub Actions workflow demonstrates how to run Continuous Integration (CI) jobs on
multiple Node.js versions using a matrix strategy. Here's a brief overview:

● Event Triggers: The workflow is triggered by pushes or pull requests to the main
branch.
● Jobs:
1. The build job runs on the ubuntu-latest environment.
2. Matrix Strategy: It tests three Node.js versions (12, 14, and 16) in parallel,
reducing the time taken to test across different versions.
● Steps:
1. Checkout Code: Fetches the code from the repository.
2. Set up Node.js: Configures Node.js for each version in the matrix.
3. Install Dependencies: Runs npm install to set up project dependencies.
4. Run Tests: Executes npm test to ensure code correctness.
5. Build Project: Compiles the project using npm run build.
6. Deploy: Runs a deployment script (deploy.sh).
In summary, this workflow helps ensure that the project works across different versions of
Node.js by running tests in parallel, making it more efficient.

name: Node.js CI

on:
push:
branches:
- main
pull_request:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [12, 14, 16] # Runs tests on multiple Node.js versions

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

- name: Set up Node.js

uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}

- name: Install dependencies

run: npm install

- name: Run tests

run: npm test
 - name: Build the project
run: npm run build

- name: Deploy
run: ./deploy.sh

● Explanation: This GitHub Actions workflow runs the same jobs across
multiple Node.js versions using a matrix strategy. It will test Node.js
versions 12, 14, and 16 in parallel.

Example 13

GitHub Actions Example: Workflow with Deployment to AWS

In this example, we'll explore a GitHub Actions workflow designed for Continuous Integration
(CI) and deployment of a Node.js project to AWS. The workflow is triggered on a push to the
main branch. It consists of two main jobs: build and deploy. The build job installs
dependencies, runs tests, and builds the project, while the deploy job handles deployment by
uploading the build artifacts to an AWS S3 bucket using AWS CLI. The AWS credentials are
securely managed through GitHub secrets.

name: Node.js CI with AWS Deployment

on:
push:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest
steps:
 - name: Checkout code
uses: actions/checkout@v3

- name: Set up Node.js

uses: actions/setup-node@v3
with:
node-version: '16'

- name: Install dependencies

run: npm install

- name: Run tests

run: npm test

- name: Build the project

run: npm run build

deploy:
runs-on: ubuntu-latest
needs: build
steps:
- name: Checkout code
uses: actions/checkout@v3

- name: Set up AWS CLI

uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: 'us-east-1'

- name: Deploy to AWS

run: |
aws s3 cp ./build s3://my-bucket-name/ --recursive
 ● Explanation: This workflow first runs the build and tests for the Node.js
project, then deploys the build artifacts to AWS S3 using the AWS CLI. It
uses AWS credentials stored as secrets in GitHub to authenticate.

Example 1: GitLab CI Pipeline with Build and Deploy

This example demonstrates a simple GitLab CI pipeline that automates the process
of building, testing, and deploying a Flask application using Docker. The pipeline
consists of three stages: build, test, and deploy. In the build stage, a Docker image
is built and pushed to a Docker registry. The test stage runs tests using pytest inside
the Docker container. Finally, the deploy stage deploys the Docker image to a
production server via SSH.

yaml

stages:

- build

- test

- deploy

variables:

DOCKER_REGISTRY: "docker.io"

IMAGE_NAME: "my-flask-app"
before_script:

- docker login -u "$CI_REGISTRY_USER" -p

"$CI_REGISTRY_PASSWORD" $DOCKER_REGISTRY

build:

stage: build

script:

- docker build -t
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME .

- docker push
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME

test:

stage: test

script:

- docker run --rm

$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME pytest tests/
deploy:

stage: deploy

script:

- ssh user@prod-server 'docker pull

$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME && docker run -d
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME'

Explanation:

● Stages: build, test, and deploy.

● Build Stage: Builds and pushes a Docker image.
● Test Stage: Runs tests inside the built Docker container using pytest.
● Deploy Stage: Deploys the Docker image to a production server.

Example 2: GitLab CI with Multiple Environments (Staging and Production)

This example demonstrates how to configure GitLab CI for managing multiple

environments, such as staging and production, for a Docker-based application. The
pipeline builds the Docker image, runs tests, and deploys the image to respective
environments based on the branch being pushed. Specifically, the staging
environment is used for the develop branch, and the production environment is
used for the main branch.

yaml
stages:

- build

- test

- deploy-staging

- deploy-production

variables:

IMAGE_NAME: "myapp"

DOCKER_REGISTRY: "docker.io"

before_script:

- docker login -u "$CI_REGISTRY_USER" -p

"$CI_REGISTRY_PASSWORD" $DOCKER_REGISTRY

build:

stage: build

script:
 - docker build -t
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME .

- docker push
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME

test:

stage: test

script:

- docker run --rm

$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME pytest tests/

deploy-staging:

stage: deploy-staging

script:

- ssh user@staging-server 'docker pull

$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME && docker run -d
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME'
 only:

- develop

deploy-production:

stage: deploy-production

script:

- ssh user@prod-server 'docker pull

$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME && docker run -d
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME'

only:

- main

Explanation:

● Multiple Environments: Deploys the Docker image to different

environments (staging for develop branch, production for main branch).
● Docker Build and Test: Builds the Docker image and runs tests before
deploying.

Example 3: GitLab CI Pipeline with Parallel Jobs

This GitLab CI pipeline includes parallel jobs to speed up the testing process. The
pipeline consists of three stages: build, test, and deploy. The test stage runs in
parallel with three jobs, reducing the total testing time. The build and deploy stages
handle image creation and deployment to a production server.

yaml

stages:

- build

- test

- deploy

variables:

IMAGE_NAME: "myapp"

DOCKER_REGISTRY: "docker.io"

before_script:

- docker login -u "$CI_REGISTRY_USER" -p

"$CI_REGISTRY_PASSWORD" $DOCKER_REGISTRY

build:
 stage: build

script:

- docker build -t
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME .

- docker push
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME

test:

stage: test

parallel: 3

script:

- docker run --rm

$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME pytest tests/

deploy:

stage: deploy

script:
 - ssh user@prod-server 'docker pull
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME && docker run -d
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME'

Explanation:

● Parallel Jobs: The test stage is set to run in parallel with 3 jobs, reducing
testing time.
● Stages: Build, test, and deploy stages for Docker images.

Example 4: GitLab CI with Multi-Stage Pipeline and Artifact Upload

This GitLab CI pipeline defines a multi-stage pipeline that builds, tests, and
deploys a Docker-based application. It also demonstrates how to store build
artifacts during the build stage, which can be used in subsequent stages.

yaml

stages:

- build

- test

- deploy

variables:
 IMAGE_NAME: "myapp"

DOCKER_REGISTRY: "docker.io"

before_script:

- docker login -u "$CI_REGISTRY_USER" -p

"$CI_REGISTRY_PASSWORD" $DOCKER_REGISTRY

build:

stage: build

script:

- docker build -t
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME .

- docker push
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME

artifacts:

paths:

- build/
test:

stage: test

script:

- docker run --rm

$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME pytest tests/

deploy:

stage: deploy

script:

- ssh user@prod-server 'docker pull

$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME && docker run -d
$DOCKER_REGISTRY/$CI_PROJECT_NAMESPACE/$IMAGE_NAME:$CI_
COMMIT_REF_NAME'

Explanation:

● Artifacts: The build job stores build artifacts, which can be used in
subsequent stages (e.g., testing).
● Multi-Stage Pipeline: Divides the pipeline into build, test, and deploy stages,
each performing its task in sequence.

Example 5: GitLab CI with SonarQube

This GitLab CI pipeline integrates SonarQube for static code analysis. The
SonarQube analysis runs after the build process, analyzing the project for code
quality issues.

yaml

stages:

- build

- test

- sonarqube

variables:

SONAR_PROJECT_KEY: "my-project-key"

SONAR_PROJECT_NAME: "My Project"

SONAR_PROJECT_VERSION: "1.0"

SONAR_HOST_URL: "http://localhost:9000"

SONAR_LOGIN: $SONARQUBE_TOKEN

before_script:

- apt-get update -y

- apt-get install -y maven

build:

stage: build

script:

- mvn clean install

sonarqube_analysis:

stage: sonarqube

script:

- mvn sonar:sonar
-Dsonar.projectKey=$SONAR_PROJECT_KEY
-Dsonar.projectName=$SONAR_PROJECT_NAME
-Dsonar.projectVersion=$SONAR_PROJECT_VERSION
-Dsonar.host.url=$SONAR_HOST_URL
-Dsonar.login=$SONAR_LOGIN

only:

- main

Explanation:

● SonarQube Analysis: Runs the SonarQube analysis using Maven.

● SonarQube Token: The token is passed using the $SONARQUBE_TOKEN
environment variable.
Example 6: GitLab CI with Trivy for Docker Scanning

This pipeline includes a security scan of the Docker image using Trivy, a
vulnerability scanner. The scan stage runs Trivy against the built Docker image to
identify potential security issues.

yaml

stages:

- build

- scan

- deploy

variables:

DOCKER_IMAGE: "my-docker-image:latest"

TRIVY_IMAGE: "aquasec/trivy:latest"

build:

stage: build

script:

- docker build -t $DOCKER_IMAGE .

scan:

stage: scan

script:

- docker run --rm -v

/var/run/docker.sock:/var/run/docker.sock $TRIVY_IMAGE
$DOCKER_IMAGE

deploy:

stage: deploy

script:

- echo "Deploying application..."

Explanation:

● Docker Scanning: Uses Trivy to scan the Docker image for vulnerabilities.
● Security Integration: Adds security checks as part of the CI pipeline.

Introduction:

Tekton is an open-source framework that provides CI/CD systems on Kubernetes.

It helps automate building, testing, and deploying applications through reusable
building blocks such as Tasks, Pipelines, and PipelineRuns. Below are various
examples demonstrating the use of Tekton for different scenarios, including
SonarQube analysis, Selenium testing, Trivy scanning, and resource management.

Example 1: Basic Pipeline

yaml

apiVersion: tekton.dev/v1beta1

kind: Pipeline

metadata:

name: example-pipeline

spec:

tasks:

- name: build

taskRef:

name: build-task

- name: test

taskRef:

name: test-task

- name: deploy

taskRef:
 name: deploy-task

---

apiVersion: tekton.dev/v1beta1

kind: PipelineRun

metadata:

name: example-pipelinerun

spec:

pipelineRef:

name: example-pipeline

resources:

- name: git-repo

resourceRef:

name: example-repo

Explanation:
This pipeline defines three sequential tasks: build, test, and deploy. Each
task references a predefined Tekton Task. The PipelineRun triggers the execution.

Example 2: Task for Building

yaml
 apiVersion: tekton.dev/v1beta1

kind: Task

metadata:

name: build-task

spec:

steps:

- name: build

image: node:16

script: |

#!/bin/bash

npm install

npm run build

Explanation:
This task uses a Node.js image to install dependencies and build a project.

Example 3: Pipeline with Git Resources

yaml

apiVersion: tekton.dev/v1beta1
kind: Pipeline

metadata:

name: example-pipeline

spec:

resources:

- name: git-repo

type: git

tasks:

- name: clone-repository

taskRef:

name: git-clone

resources:

inputs:

- name: repository

resourceRef:

name: git-repo

- name: build

taskRef:

name: build-task
 - name: test

taskRef:

name: test-task

- name: deploy

taskRef:

name: deploy-task

Explanation:
This pipeline includes a Git resource for cloning a repository, followed by build,
test, and deploy tasks.

Example 4: Git Cloning Task

yaml

apiVersion: tekton.dev/v1beta1

kind: Task

metadata:

name: git-clone

spec:

resources:

inputs:
 - name: repository

type: git

steps:

- name: clone

image: alpine:latest

script: |

#!/bin/bash

git clone https://github.com/my-repo.git

/workspace/repository

Explanation:
This task clones a GitHub repository into a workspace using a Git resource.

Example 5: SonarQube Integration

yaml

apiVersion: tekton.dev/v1beta1

kind: Pipeline

metadata:

name: sonar-pipeline

spec:
tasks:

- name: build

taskRef:

name: maven-build

resources:

inputs:

- name: source

resource: git-repo

- name: sonar-analysis

taskRef:

name: sonar-scanner

params:

- name: SONAR_PROJECT_KEY

value: my-project-key

- name: SONAR_PROJECT_NAME

value: My Project

- name: SONAR_HOST_URL

value: http://localhost:9000

- name: SONAR_LOGIN
 value: $(params.sonar-token)

---

apiVersion: tekton.dev/v1beta1

kind: PipelineRun

metadata:

name: sonar-pipelinerun

spec:

pipelineRef:

name: sonar-pipeline

params:

- name: sonar-token

value: $(secrets.SONARQUBE_TOKEN)

Explanation:
This pipeline integrates SonarQube for static code analysis. A token is passed
securely for authentication.

Example 6: Selenium Testing

yaml

apiVersion: tekton.dev/v1beta1
 kind: Task

metadata:

name: selenium-tests

spec:

steps:

- name: run-selenium-tests

image: selenium/standalone-chrome

script: |

#!/bin/bash

python3 /tests/run_selenium_tests.py

Explanation:
A Selenium test task uses a Chrome container to execute Python-based Selenium
tests.

Example 7: Trivy for Vulnerability Scanning

yaml

apiVersion: tekton.dev/v1beta1

kind: Task

metadata:
 name: trivy-scan

spec:

params:

- name: IMAGE

type: string

steps:

- name: trivy-scan

image: aquasec/trivy:latest

script: |

#!/bin/bash

trivy image $IMAGE

Explanation:
The task scans a Docker image for vulnerabilities using Trivy.

Key Points of the Examples:

● Jenkins: Jenkinsfile defines the pipeline using stages like Checkout, Build,
Test, and Deploy. You can use shell scripts to execute build, test, and
deployment tasks.
 ● GitHub Actions: file defines jobs and steps that execute on events like push
or pull_request. You can set up environments (e.g., Node.js) and use actions
for common tasks (like checking out code).

● GitLab CI: .gitlab-ci.yml file defines stages and jobs with commands that
execute on pushes to a repository. Jobs can be configured to run on specific
branches.

● Tekton: Pipeline and Task resources are defined in . Tekton Pipelines are
Kubernetes-native, and tasks are reusable units of work that are executed as
part of a pipeline.

Interview Questions and Answers

Jenkins Interview Questions and Answers

1. What is Jenkins, and how does it work?

○ Answer: Jenkins is an open-source automation server used to
automate the parts of software development related to building,
testing, and deploying. It works by defining "jobs" that automate these
processes, which can be triggered either manually or automatically
based on events like code commits, scheduled times, or other triggers.

2. What is a Jenkins pipeline?

○ Answer: A Jenkins pipeline is a suite of plugins that supports the
integration and implementation of continuous delivery pipelines.
Pipelines define the stages and steps of a job's execution, allowing for
 complex automation workflows. There are two types: Declarative
Pipelines (which use a simplified syntax) and Scripted Pipelines
(which offer full flexibility).

3. What is a Jenkinsfile?
○ Answer: A Jenkinsfile is a text file that contains the definition of a
Jenkins pipeline. It is usually stored within the project repository and
contains the code that defines the pipeline structure, stages, steps, and
the logic that controls the execution of the pipeline.

4. How do you integrate Jenkins with version control systems like Git?
○ Answer: Jenkins can be integrated with Git by using the Git plugin.
This allows Jenkins to pull code from a Git repository to trigger jobs.
Typically, Git webhooks are configured to notify Jenkins whenever
changes are pushed to the repository, automatically triggering the
corresponding pipeline or job.

5. What are the different types of Jenkins builds?

○ Answer: Jenkins supports different types of builds:
■ Freestyle Projects: A simple, configurable job where you can
specify build steps.
■ Pipeline Jobs: Jobs that use a Jenkinsfile to define complex
workflows and stages for continuous integration and delivery.
■ Multi-configuration Projects: Used for testing multiple
configurations of the same project.
■ GitHub Organization: For GitHub organization-level
integration.

6. What is the purpose of Jenkins plugins?

 ○ Answer: Jenkins plugins extend the functionality of Jenkins. There
are thousands of plugins available, which add support for different
version control systems, build tools, deployment platforms,
notification services, and more.

7. How does Jenkins handle version control integration?

○ Answer: Jenkins integrates with version control systems (like Git,
SVN, etc.) through plugins. The Git plugin, for example, allows
Jenkins to poll the repository for changes, or use webhooks to trigger
builds automatically when new code is pushed to the repository.

8. What is the difference between declarative and scripted pipelines in

Jenkins?
○ Answer:
■ Declarative Pipeline: A simplified and more structured
approach to defining Jenkins pipelines. It uses a more readable
syntax and includes predefined blocks like stages and steps.
■ Scripted Pipeline: A more flexible and powerful approach,
allowing you to write custom scripts in Groovy. It is more
suitable for complex pipelines with advanced control flow.

GitHub Actions Interview Questions and Answers

1. What are GitHub Actions?

○ Answer: GitHub Actions is a CI/CD and automation service provided
by GitHub that enables you to automate workflows directly in your
 GitHub repository. These workflows can handle tasks like building,
testing, and deploying code. Workflows are defined using files stored
within the repository.

2. How do you define a workflow in GitHub Actions?

○ Answer: A workflow in GitHub Actions is defined by creating a
.github/workflows/{workflow-name}.yml file. This file contains the
jobs, steps, and triggers that automate tasks like build, test, and
deployment.

3. What is the difference between a job and a step in GitHub Actions?

○ Answer: A job is a set of steps that are executed on the same runner,
while a step is an individual task that can either be a script or an
action. Jobs can run sequentially or in parallel, while steps are
executed in the order they are defined within a job.

4. What is a matrix build in GitHub Actions?

○ Answer: A matrix build allows you to run a job in multiple
configurations at the same time. For example, you can test your
application on different operating systems or with different versions of
programming languages in parallel.

5. What are GitHub Actions triggers?

○ Answer: Triggers in GitHub Actions determine when a workflow
should run. Common triggers include:
■ push: Triggered when code is pushed to a repository.
■ pull_request: Triggered when a pull request is created or
updated.
■ schedule: Triggered at a scheduled time (using cron syntax).
 ■ workflow_dispatch: Triggered manually by the user.

6. What is a GitHub Actions Artifact?

○ Answer: Artifacts are files that are created during the execution of a
workflow. They can be used to pass data between jobs, store logs, or
persist build outputs for later use. Artifacts are stored temporarily and
can be downloaded after the workflow completes.

7. How do you run a job in parallel in GitHub Actions?

○ Answer: Jobs in GitHub Actions can be run in parallel by default.
You can explicitly define this by not specifying dependencies between
jobs using the needs keyword. Jobs without dependencies will run
simultaneously.

8. How do you cache dependencies in GitHub Actions?

○ Answer: GitHub Actions provides a cache action (actions/cache) to
cache dependencies between workflow runs. This helps reduce build
times by storing dependencies like node_modules, maven
dependencies, etc., and reusing them in subsequent runs.

Gitlab Actions Interview Questions and Answers

1. What is a GitLab CI/CD pipeline?

Answer: A GitLab CI/CD pipeline is a series of jobs defined in a

.gitlab-ci.yml file, where each job corresponds to a step in the CI/CD
process. The pipeline typically includes stages like build, test, deploy,
 etc., and is triggered based on events such as code commits or merge
requests.

2. What is the difference between stages and jobs in GitLab CI?

Answer:

■ Stages: Define the execution order of the pipeline. Jobs within

a stage run concurrently unless explicitly ordered.
■ Jobs: Define the individual tasks to be executed, such as
compiling code or running tests. Each job is associated with a
stage and runs in a runner.

3. What are GitLab CI/CD Runners?

Answer: GitLab runners are agents that execute the jobs defined in a
pipeline. They can be shared runners provided by GitLab or specific
runners installed on your infrastructure. Runners can execute jobs in
different environments like Docker containers or virtual machines.

4. How can you handle secrets in GitLab CI/CD?

Answer: GitLab provides a secure way to store secrets via CI/CD

variables.These variables can be defined at the project or group level
and are automatically injected into the environment during job
execution, ensuring sensitive data is not exposed.

5. What is GitLab CI/CD, and how does it differ from Jenkins?

Answer: GitLab CI/CD is an integrated part of the GitLab platform

that enables the automation of the software delivery process. Unlike
 Jenkins, which is standalone and requires manual integration with
various services, GitLab CI/CD is built directly into the GitLab
platform, offering tighter integration with repositories, issue tracking,
and other GitLab services.

6. How do you define pipelines in GitLab CI/CD?

Answer: Pipelines in GitLab are defined using a .gitlab-ci.yml file in

the root of the project repository. This file contains the stages, jobs,
and scripts that define the pipeline's execution flow, including build,
test, and deploy stages.

7. What are runners in GitLab CI/CD?

Answer: GitLab runners are agents that execute jobs defined in the
.gitlab-ci.yml file. Runners can be either shared (provided by GitLab)
or specific to a project or instance. They can run on different
environments like Docker, Kubernetes, or virtual machines.

8. What are the stages in GitLab CI/CD?

Answer: Stages define the order in which jobs are executed in a

pipeline. Common stages include build, test, deploy, etc. Jobs within
the same stage run in parallel, while stages run sequentially by default.
Tekton Interview Questions and Answers

1. What is Tekton, and how does it fit into the CI/CD process?
○ Answer: Tekton is an open-source Kubernetes-native CI/CD
framework that allows you to create and manage continuous
integration and delivery pipelines. Tekton provides Kubernetes
custom resources like Pipeline, PipelineRun, and Task to define, run,
and manage CI/CD pipelines on Kubernetes clusters.

2. What is the concept of a "Pipeline" in Tekton?

○ Answer: A Pipeline in Tekton is a collection of tasks that define a
series of steps to be executed sequentially or in parallel. Each task is
defined as a set of steps to perform a specific action (e.g., build, test,
deploy).

3. How do you create a Tekton pipeline?

○ Answer: To create a Tekton pipeline, you define a Pipeline resource in
format. This file specifies the tasks, inputs, outputs, and the order in
which they should be executed. You can then trigger the pipeline
using a PipelineRun resource.

4. How do Tekton tasks differ from Jenkins jobs?

○ Answer: Tekton tasks are individual units of work within a pipeline.
Each task defines a series of steps (such as building an image or
running tests) in a Kubernetes-native way. In contrast, Jenkins jobs are
more general and can be configured to run on various types of agents
(such as virtual machines, Docker containers, or cloud services).

5. What is a Tekton Task?

 ○ Answer: A Tekton Task is a reusable unit of work in a pipeline. Each
task is made up of a series of steps that perform a specific action, such
as building a Docker image, running tests, or deploying code. Tasks
can be shared and reused across different pipelines.

6. What is a Tekton PipelineRun?

○ Answer: A PipelineRun is an instance of a Tekton Pipeline. It triggers
the execution of the tasks defined in the pipeline. You can specify
parameters, resources, and other configurations for a PipelineRun to
customize its execution.

7. What are Tekton Triggers?

○ Answer: Tekton Triggers enable the automation of pipeline execution
based on external events, such as code pushes or pull requests.
Triggers are often used in combination with GitHub, GitLab, or other
event sources to kick off Tekton Pipelines automatically.

8. How does Tekton integrate with Kubernetes?

○ Answer: Tekton is built natively for Kubernetes and utilizes
Kubernetes resources to define CI/CD workflows. Tasks, Pipelines,
and PipelineRuns are all defined as Kubernetes Custom Resource
Definitions (CRDs), making it easy to deploy, manage, and scale
pipelines on Kubernetes clusters.

9. What are the advantages of using Tekton over Jenkins?

○ Answer:
■ Kubernetes-Native: Tekton is designed to work with
Kubernetes, making it ideal for cloud-native and containerized
applications.
■ Scalability: Being built for Kubernetes, Tekton can scale
effortlessly with the underlying infrastructure.
■ Flexibility: Tekton allows for highly customizable and reusable
pipeline components, which is great for complex CI/CD
workflows.
■ Declarative Pipelines: Like Jenkins' declarative pipelines,
Tekton offers a more structured way to define tasks and
pipelines.