CI/CD using GitHub Actions

Before going in depth we need to access the problems that we can possibly face:

1. Extra Work:while it may not seem a lot,But a large amount of R&D and configuration is required each time we build and deploy the code.This would actually waste a lot of time for a developer who could have focused on actual problems.
   For Example :Gradle Commands,Docker configs and GCP Configs.
2. Security: Security is one of the major concerns ,since Every DevOps/Developer needs to have access to the Cloud Services ,a separate pair of security keys is generated.Hence if anyone's system gets compromised then it would become a problem for the organization.
3. Extra Container:This requires extra bits of tools to configure like Docker,which is again a problem if we don't have enough storage and resources.In our case ,A separate docker image has to be created every time before making the changes live.
4. Deployment:After creating Docker image ,Again we have to deploy these images to the Container Registry before final deployment.

All these problems are correlated to one another and together they actually become so big that it becomes hard for organizations to manage.This could cause a large deal of expense in workforce and resource which may not be good for organization.

So what is the Solution?

Enters CICD.

CI/CD stands for Continuous Integration and Continuous Deployment.

CICD involves automating the process of deploying code changes to production environments, which includes running automated tests, deploying to staging environments, and then promoting the changes to production. This automation reduces the time and effort required to deploy code changes, and helps ensure that deployments are consistent and error-free.

It is a set of practices and tools that enable software development teams to deliver code changes more frequently and reliably.

How are we Solving this Problems in our Situation?

• Extra Work is still required by the developer ,but this is one time only.Every Subsequent deployment will be handled by the automation process.This one Time work may save up a lot of the time later down the line and would get more work done.
• Security concerts are practically nulled out, because the security keys are handled by the Github tools.In no way anyone can access those keys.Also we dont have to keep providing the security credentials to every developer working .This will improve our security and less chance of breach.
• Installation of Docker is no longer required because JIB tool will handle everything from image creation to actually pushing to the Hub.

Prerequisites 

You would need following knowledge to achieve this automation

1. Knowledge of GIt and GITHUB
2. Docker and Dockerhub
3. CMD tools is ABSOLUTE MUST.(linux)
4. Knowledge of GCP and its credentials.
5. Make sure container registry is available if you are using GCP.(You can enable it via this link :http://containerregistry.googleapis.com/)

Tools required for storing Springboot Docker Image on GCP:

1. JIB: Jib builds optimized Docker and OCI images for your Java applications without a Docker daemon - and without deep mastery of Docker best-practices. It is available as plugins for Maven and Gradle and as a Java library.
   We only have to add JIB as a plugin to our build. gradle file and gradle will automatically intialie three tasks 
   a). Jib:Task for building and deploying to any docker container.(needs gradle configuration and auth to the container)
   b). Jibbuildtar : builds a tar file 
   c). Jibdockerbuild: generates a dockerimage to local Dockerhub.
2. GCP Account billing enabled: A GCP account(or anyother devops service) is required to host the images that will be created from jib.You would need a servicekey json file with proper roles and permissions to authorize the Jib for pushing the docker image.
3. Github Actions: Github is a popular service among the developers.It not only can store and host code but can also automate the CICD deployment using a service called github actions.Github actions a very easy to configure be a use it uses a simple yml file and assumes that you have knowledge of command line options mainly linux.
   It also has great support throughout the community so you are never stuck all alone.

Configuring CI/CD for Springboot application using Github actions and Google cloud/Dockerhub

Configuration of build.gradle for jib

1. Add the following plugin to gradle

plugins {

  id 'com.google.cloud.tools.jib' version '3.3.1'

}

1. Add the following jib config to the end of gradle file

jib {

   from {

       image = 'adoptopenjdk/openjdk11'

   }

   to {

image = "gcr.io/${System.getenv("PROJECT_ID") ?: "starter-361011"}/starter-server:${scmVersion.version}"

.toString()

   }

   container {

       creationTime = 'USE_CURRENT_TIMESTAMP'

       ports = ['50071', '50072']

       jvmFlags = [

               '-Djava.security.egd=file:/dev/urandom',

               '-Dcom.google.cdbg.module=starter-server',

               "-Dcom.google.cdbg.version=${scmVersion.version}".toString()

       ]

       mainClass = 'com.example.starterserver.StarterServerApplication'

   }

}

NOTE: The image name in “to” section has to be changed according to the container repository is being used.

For example we are using GCP container register,

Hence image name starts by “gcr.io” followed by path of the registry

If we use Dockerhub repository then,

Image name should start by path of the docker repository

to { 

image="aniketcodeprism/github-actions:${scmVersion.version}".toString()

}

The format of the image name should be like this:

image=”<path to registery>:<image tag>”

1. Now login to gcloud using terminal by following command
2. After Successfully logging in,run following command to update your docker settings for 

gcloud echo y | gcloud auth configure-docker

1. Now try running the following command : 

./gradelw jib.

You will notice that a image file will be uploaded in your container registry.

Getting service key for GCP  

After the jib config next thing we need is to get a service key json file.this json will be used by github actions to authorize the gcp on github platform.You don't need this if you are not planning to use GCP container registry.

1. Go to the following link : https://console.cloud.google.com/iam-admin/serviceaccounts
2. Select your project and make sure billing is enabled.
3. On the top click on Create Service
4. Fill in the basic details like name and description
5. Next you have to select the role .Make sure it is same as bellow screenshot

1. After that Click on done.
2. You will notice that a new Service account has been created.
3. Click on that account and go to the key section.
4. Next create a new key ,Select JSON.A json file will be downloaded automatically.

Configuration of github actions.

Configuration of github action is very easy.You can refer to some videos if you want to learn about all the specific commands.For now you can use below code to easily create CICD.yml file for you git actions.

# This workflow uses actions that are not certified by GitHub.

# They are provided by a third-party and are governed by

# separate terms of service, privacy policy, and support

# documentation.

# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time

# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-gradle

name: Java CI with Gradle

on:

  push:

    branches: [ "master" ]

  pull_request:

    branches: [ "master" ]

permissions:

  contents: read

jobs:

  build:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v3

      - name: Set up JDK 17

        uses: actions/setup-java@v3

        with:

          java-version: '17'

          distribution: 'temurin'

      - name: Install Protoc

        uses: arduino/setup-protoc@v1

      - name: Grant execute permission for gradlew

        run: chmod +x gradlew        

      - name: Gradle createVersion

        id: version-cv

        run: |

          version=$(./gradlew cV | grep "version =" | awk '{print $3}')

          echo "::set-output name=version::$version"          

      - name: Gradle createVersion in Starter-api

        run: |

          cd starter-api/

          ../gradlew cV          

      - name: Gradle createVersion in Starter-server

        run: |

          cd starter-server/

          ../gradlew cV          

      - name: Gradle createRelease

        id: release-cr

        run: |

          release=$(./gradlew cR -Prelease.disableSnapshotsCheck | grep "name =" | awk '{print $3}')

          echo "::set-output name=release::$release"

#      - name: Login to Docker Hub

#        uses: docker/login-action@v2

#        with:

#          username: '${{ secrets.DOCKER_USERNAME }}'

#          password: '${{ secrets.DOCKER_TOKEN }}'

      - name: "GCloud Login"

        id: 'auth'

        uses: 'google-github-actions/auth@v1'

        with:

          credentials_json: '${{ secrets.GCP_CREDENTIALS }}'

      - name: 'Set up Cloud SDK'

        uses: 'google-github-actions/setup-gcloud@v1'        

      - name: "gcloud auth configure-docker"

        run: echo y | gcloud auth configure-docker      

      - name: Build and Push Docker Image

        id: docker-build-image

        run: ./gradlew jib 

All of these commands are very simple .They are just a bunch of gradle and auth commands and their names are self explanatory.If you want to know more about them you can check git actions marketplace.

Now for the IMPORTANT PART

Configuration of the Credentials in GitHub Actions.

Github actions needs some credentials in order to run that yml file.

1. Go to repo settings.
2. Then go to Secrets and variables.
3. Select Actions
4. Now create New Repo Secret.
5. In the name Section ,type GCP_CREDENTIALS
6. In Secret copy and paste the contents of the service account json and click on ok.
7. Similarly you can configure for the Docker username and access the secret key for docker repo.

Some More Information about CI/CD 

CICD is also made of two fundamental components:

CI(Continuous Integration):It is the practice of frequently integrating code changes into a shared repository, and then verifying that the code builds and passes automated tests. This helps catch integration errors early and ensures that the codebase is always in a stable state.

CD(Continuous Deployment):It is the practice of automating the deployment of code changes to production environments. This involves using automated testing, staging environments, and deployment pipelines to ensure that code changes are released safely and quickly.

Some Misunderstandings

Now before we move further into this ,I want you to be clear of misunderstanding to make sure you understand what this is and What is this is not.

CI/CD is just about automation: While automation is a key aspect of CI/CD, it is not the only thing that matters. CI/CD is also about creating a culture of collaboration and continuous improvement, where developers, testers, and operations teams work together to deliver high-quality software quickly and reliably.

NO Programming: There is almost no coding required for the automation, however, we do have to write configuration files required for the tasks/jobs.These configs are not in any of the traditional language so it may become tedious task for a new comer.

CI/CD is only for large organizations: While CI/CD can be complex to implement in large organizations, it can also be beneficial for small teams and startups. Even small teams can benefit from the increased efficiency, improved quality, and faster time-to-market that CI/CD can provide.

CI/CD is only for web applications: While CI/CD is often associated with web applications, it can be applied to any type of software development, including desktop applications, mobile apps, and embedded systems.

CI/CD is a silver bullet: While CI/CD can help improve software development and deployment processes, it is not a magic solution that can solve all problems. It requires careful planning, coordination, and continuous improvement to achieve the desired results.

CI/CD eliminates the need for manual testing: While CI/CD can automate many testing tasks, manual testing is still an important part of the software development process. Manual testing can help catch issues that automated tests may miss, and can provide valuable feedback on the user experience and overall quality of the software.

Overall having a CICD in your project is a good thing, but it is not Everything.

Advantages and disadvantages of CICD

CI/CD has several advantages and disadvantages:

Advantages:

1. Faster delivery of software: CI/CD helps developers deliver software faster and more frequently, which is critical in today's fast-paced business environment.
2. Improved quality: With automated testing and continuous integration, CI/CD helps catch errors and issues early, which can reduce the risk of bugs and improve overall quality.
3. Increased collaboration: CI/CD promotes collaboration and communication between developers, testers, and operations teams, which can help identify and resolve issues more quickly.
4. Greater efficiency: By automating tasks such as building, testing, and deployment, CI/CD can help reduce the time and effort required to deliver software changes.
5. More reliable deployments: With continuous delivery, deployments are more consistent and reliable, which can reduce the risk of errors and downtime.

Disadvantages:

1. Initial setup and maintenance: Setting up a CI/CD pipeline can be complex and time-consuming, and requires ongoing maintenance and updates. 
2. Complexity: CI/CD can involve a lot of tools and processes, which can be overwhelming and confusing for some teams.
3. Cultural change: Adopting CI/CD requires a cultural shift in the way teams work, which can be challenging for some organizations.
4. Resource requirements: CI/CD can require significant resources, including hardware, software, and personnel, which may be a barrier for some organizations.
5. Increased risk: While CI/CD can help reduce the risk of errors and issues, it also introduces new risks, such as configuration errors and security vulnerabilities, which need to be managed and mitigated