What is the difference between Code Coverage and Code Analysis

Both code coverage and code analysis are methods used to improve software quality, but they differ in their approach, goals, and implementation. Here's a detailed comparison:

Code Coverage:

• Definition: Code coverage is a metric that measures the amount of code that is executed during automated tests.
• Purpose: The main goal is to ensure that the test suite exercises as much of the codebase as possible, helping to identify untested areas.
• How it Works:
  • Tools run the tests and track which parts of the code (lines, branches, functions) are executed.
  • Coverage is expressed as a percentage indicating how much of the code has been executed during tests.
• Metrics Tracked:
  • Line Coverage: How many lines of code are executed.
  • Branch Coverage: How many decision points (e.g., if statements) are tested.
  • Function Coverage: How many functions or methods are invoked during tests.
• Example Tools: JaCoCo, Coverage.py, Istanbul.
• Output: Reports showing which portions of the code are covered by tests and which are not.
• Use Case: Primarily used during the testing phase to gauge the extent to which the code is exercised by tests.

Code Analysis:

• Definition: Code analysis is a technique used to evaluate the quality, structure, and potential errors in the codebase. It can be performed either statically (without executing the code) or dynamically (during runtime).
• Types of Code Analysis:
  • Static Code Analysis: Inspects the source code for issues such as coding standards violations, potential bugs, or security vulnerabilities without running the code.
  • Dynamic Code Analysis: Involves analyzing the behavior of the code during execution, often looking for performance issues, memory leaks, or runtime errors.
• Purpose: The goal is to find potential problems or improve code quality by identifying security risks, performance bottlenecks, or areas that violate best practices.
• How it Works:
  • Static analysis tools scan the code for patterns that match predefined rules (e.g., code smells, unused variables).
  • Dynamic analysis tools monitor the code while it's running to observe its actual behavior.
• Example Tools:
  • Static Analysis: SonarQube, Pylint, ESLint.
  • Dynamic Analysis: Valgrind, Dynatrace.
• Output: Reports showing potential bugs, security vulnerabilities, code smells, or violations of coding standards.
• Use Case: Can be performed during development to ensure code quality and prevent issues from entering production.

List of Topics Covered with DevOps and Cloud computing Class With Coach AK

 

DevOps Interview Preparation Useful real time tips | Crack DevOps Interviews | How to clear DevOps Interviews

 Are you failing in DevOps Interviews? Are you not be able to go to next round in the Interview process? 

First of all you need to have clear story about following five key items:

#1.     Come up with a story to talk about your back ground and over all experience 

            What are the Devops tools you have worked in, what cloud platform you are familiar ?

#2.     Have clear idea to talk about your role in your current project

           Your role instead of what whole team did

#3.     Your day to day responsibilities as a DevOps engineer

           How you spend your day 9-5. Starting with stand up, cicd, infra automation, collaborate with teams, meetings and documentation.

#4.     Be ready to talk about the challenges, how you overcome them in your current project

           What challenges you had, how did you over-come and what was the outcome?

#5.     Be clear about what you know and what you don’t know.            

• It is OK to say you don’t know or have not worked that specific tool when asked about it. Show some willingness to learn
• For e.g you may be good in CICD but not good in,  let’s say in container orchestration tools such as Kubernetes, which is OK.

Fix for Jenkins slowness when Running in AWS EC2 instance | Jenkins Very Slow Upon Starting EC2 Instance after Stopping

Let's say that you have configured Jenkins in AWS EC2 instance and you are using AWS free tier and you are NOT using Elastic IP, so when ever you start EC2 instance after stopping, you would have noticed Jenkins UI is taking a lot of time to come up. You try to access any page in Jenkins, it will be really slow.

What is the root cause of the issue?

Because EC2 configured in AWS free tier account would have new IP after every restart, Jenkins was trying to use old IP address when you are trying to start Jenkins. Due to this issue, Jenkins will be very slow.

Pre-requisites:

• Jenkins is setup in AWS cloud using free-tier account.

There are two ways you can fix this issue:

First option using command line

Make changes in the xml file by logging into EC2 instance through command line using Git bash or any SSH tool.

Connect to Jenkins EC2 instance using Git bash or iTerm:

Navigate to Jenkins installation directory:

cd /var/lib/jenkins/

Modify jenkins.model.JenkinsLocationConfiguration.xml file by executing below command:

sudo nano jenkins.model.JenkinsLocationConfiguration.xml

Make sure you provide Jenkins current URL in below location and restart Jenkins.

sudo service jenkins restart

Now try accessing Jenkins through UI, it will be really performing well.

Second option us using Jenkins UI

Change public URL under Manage Jenkins->System

Change Jenkins URL to current Jenkins URL:

Click on Apply-> Save.

that's it. You will notice Jenkins is performing well now.

Watch steps in YouTube channel: 

GitHub Actions CICD Pipeline to Deploy Java WebApp into Azure App Service | Integration GitHub Actions with Azure App Service

 

Pre-requisites:

• Make sure Java web app is setup in GitHub
• Azure subscription to create web app

What are we going to do in this lab?

1. Create a Web App in Azure Cloud

2. Configure WebApp to Deploy using gitHub Actions

3. Create workflow yaml

4. Add steps/tasks in the yaml file

5. Run the workflow yaml

6. Check if Java Web App is deployed in Azure App Service

How to Create WebApp in Azure Portal?

1. Login portal.azure.com
2. Click on App services

3.Click on + Add or click on Create app service


Click on Web App. Choose your Azure subscription, usually Pay as you Go or Free trial subscription
Create a new resource group or you can use existing resource group)

Enter App service name(it should be unique)
Publish as Code
Run time stack as Java 17

Java Web Server stack --> Tomcat 10.0
Operating System as Linux
Region as Central US or where ever you are based at

Enter LinuxPlan name
Choose pricing plan

Now go to Deployment tab:

Enable basic authentication

and enable Continuous Deployment 

Click on GitHub account, Authorize.

Authorize AzureappService

now select organization, repo, branch

You can also click on preview file to get pipeline YAML code 

Click on Review and Create

Create Web App

Now make sure AzureAppService_PublishProfile secret is automatically created in GitHub repo you selected.

Create GitHub Actions CICD workflow yaml:

name: Build and deploy WAR app to Azure Web App
on:
  push:
    branches:
      - main
  workflow_dispatch:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Java version
        uses: actions/setup-java@v2
        with:
          java-version: '11'
          distribution: 'adopt'
      - name: Build with Maven
        run: mvn clean install -f MyWebApp/pom.xml
      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v3
        with:
          name: MyWebApp
          path: '${{ github.workspace }}'
  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'Production'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v3
        with:
          name: MyWebApp
      - name: Deploy to Azure Web App
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'spingbootwebapp'
          slot-name: 'Production'
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_76B948D486E54ED7B06775D572207D40 }}
          package: '*.war'

Check the output after running the pipeline:

Verify if WebApp has been deployed into Azure App Service by browsing Web App url.

https://mysuperjavaapp.azurewebsites.net/MyWebApp/

Watch here all the steps in YouTube channel:

GitHub Actions Pipeline to Create Docker Image and Push Docker Image into DockerHub | GitHub Actions Integration with DockerHub

 Please find steps for integrating DockerHub with GitHub Actions:

Implementation steps:

• Create access token in DockerHub
• Add access token, docker hub user name as secrets in GitHub Actions
• Create GitHub Actions workflow yaml in your repo
• Add tasks for Maven build, docker image creation, tagging and docker push 
• Run the workflow/build in GitHub hosted runner(e.g. Ubuntu)
• Verify docker image have been uploaded into DockerHub

Pre-requisites:

• DockerHub Account
• Make sure a Project is setup in GitHub with Dockerfile
• Create access token in Docker Hub for authenticating with DockerHub

Steps below to create access token in DockerHub:

Login to --> https://hub.docker.com/settings/security

Click on new access token:

    Copy on Generate

 

Add Docker Hub user name and token as Secrets in GitHub Actions

Go to your GitHub Repo --> Settings --> 

Click on Secrets and Variables under Security in left nav 

Click new Repository Secret

Enter DOCKERHUB_USERNAME as secret name and 

Enter your docker hub user name

Enter DOCKERHUB_TOKEN as secret name and 

Enter your token as secret

Create GitHub Actions CICD workflow yaml:

Go to GitHub repo where your Java project is, create a new file:

.github/workflows/cicd.yml

The below file have four steps(tasks) 

    - Checkout

    - Install Java on runner

    - Build using Maven

    - Build docker image and tag it

    - Upload docker image into DockerHub

Copy below YAML code:

name: cicd-workflow to create docker image and upload into Dockerhub

on:

  push:

    branches: [ "master" ]

jobs:

  job1:

    runs-on: ubuntu-latest

    steps:

    - uses: actions/checkout@v3

    - name: Set up JDK 17

      uses: actions/setup-java@v2

      with:

        distribution: 'adopt'

        java-version: '17'

    - name: Build with Maven

      run: mvn clean install

    - name: Login to Docker Hub

      uses: docker/login-action@v3

      with:

        username: ${{ secrets.DOCKERHUB_USERNAME }}

        password: ${{ secrets.DOCKERHUB_TOKEN }}

    - name: Build and push Docker image

      env:

        IMAGE_TAG: ${{ github.sha }}

      run: |

        docker build -t ${{ secrets.DOCKERHUB_USERNAME }}/myspringbootapp:${IMAGE_TAG} .

        docker push ${{ secrets.DOCKERHUB_USERNAME }}/myspringbootapp:${IMAGE_TAG}

Commit the file.

As soon as you commit, build will run immediately in GitHub Actions. 

Now you can see the output of build in Actions tab.

Login to DockerHub to verify if docker image have been uploaded successfully.

Watch steps in YouTube channel:

How to Setup Self-Hosted Linux Docker Build Agent in Azure DevOps | How to configure Self-Hosted Linux Docker Agents in Azure Pipelines | Create Custom Build Agents in Azure DevOps

 Let us learn how to configure a self-hosted agent using Docker in Azure DevOps pipelines.

What is an Agent?

An agent is computing infrastructure with installed agent software that runs one job at a time.To build your code or deploy your software using Azure Pipelines, you need at least one agent. As you add more code and people, you'll eventually need more.

When your pipeline runs, the system begins one or more jobs. 

In Azure pipelines, there are two types of build agents:

1. Microsoft-hosted agents - This is a service totally managed by Microsoft and it's cleared on every execution of the pipeline (on each pipeline execution, you have a fresh new environment).
2. Self-hosted agents - This is a service that you can to set up and manage by yourself. This can be a custom virtual machine on Azure or a custom on-premise machine inside your infrastructure. In a self-hosted agent, you can install all the software you need for your builds, and this is persisted on every pipeline execution. A self-hosted agent can be on Windows, Linux, macOS, or in a Docker container.

You can set up a self-hosted agent in Azure Pipelines to run inside a Windows Server Core (for Windows hosts), or Ubuntu container (for Linux hosts) with Docker. We will learn in this article on how to host Ubuntu Docker container on Linux machines.

Pre-requisites:

• Microsoft account setup
• Azure account and subscription setup
• Create a VM(Ubuntu 20.0.4) in Azure Cloud
• Create Personal Access Token in Azure DevOps
• Dockerfile created for docker build agent, please refer this repo

How to configure Self-hosted docker build agent?

1. Go to Azure DevOps dashboard - https://dev.azure.com/

2. Select your project dashboard

3. Go to your project settings

4. Click on Agent pools

Create a new Agent pool name

Enter name as myAgentPool or any name

Make sure you select Grant access permission to all pipelines

Login to Azure VM where the docker build agents will be running.

Step #1 - Install Docker CLI so we can build docker image

sudo apt update && sudo apt install docker.io -y

Step #2 - Add logged in user to docker group

sudo usermod -a -G docker $USER

Step #3 - Clone repo which has Dockerfile

git clone https://github.com/akannan1087/ado-docker-agent-repo.git

Sample dockerfile is here.. please feel free to add any software in the docker agent.

FROM ubuntu:22.04

RUN apt update -y && apt upgrade -y && apt install curl git jq libicu70 maven -y

# Also can be "linux-arm", "linux-arm64".

ENV TARGETARCH="linux-x64"

WORKDIR /azp/

COPY ./start.sh ./

RUN chmod +x ./start.sh

# Create agent user and set up home directory

RUN useradd -m -d /home/agent agent

RUN chown -R agent:agent /azp /home/agent

USER agent

# Another option is to run the agent as root.

# ENV AGENT_ALLOW_RUNASROOT="true"

ENTRYPOINT ./start.sh

Step #4 - change directory

cd ado-docker-agent-repo/azp-agent-in-docker/

Step #5 - Build the Docker image

sudo docker build --tag "azp-agent:linux" --file Dockerfile .

Step #6: Run the agent as a container

Run the below command:

sudo docker run -e AZP_URL="https://dev.azure.com/your_org_name" -e AZP_TOKEN="XXXX" -e AZP_POOL=myAgentPool -e AZP_AGENT_NAME="myLinuxDockerBuildAgent" --name "azp-agent" azp-agent:linux

that's it, docker agent is successfully started.

Step #7: Verify if docker agent is running or not

Run the below command:

sudo docker ps

Check the status of build Agent

Click on agentPool name, click on Agents

This confirms that Build agent is successfully configured in Azure DevOps and is available to run builds.

How to use the Docker build agent in your pipelines?

Please use the docker agent in the classic pipeline like below: select the agentPool

run the job. now you can see the jobs under myAgentPool--> Jobs

 

Here is the sample pipeline YAML code for automating Maven build for a Java project:

trigger:

- main

pool:

name: myAgentPool

stages:

- stage: Build

displayName: Build stage

jobs:

- job: MavenPackageAndPublishArtifacts

displayName: Maven Package and Publish Artifacts

steps:

- task: Maven@3

displayName: 'Maven Package'

inputs:

mavenPomFile: 'MyWebApp/pom.xml'

References:

https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops

Watch steps in YouTube channel: