Workflow in CI/CD Pipeline - Jenkins, Kubernetes and SVN/GitHub Code Repository

Question

I am trying to use Jenkins, Kubernetes and my SVN repository for implementing CI/CD pipeline for deployment of my Spring Boot micro services. When I am exploring, I found that in Jenkins+Kubernetes deployment, the Docker image is pulling from image registries. And when I exploring sample implementation, I found that option for automated image building within Jenkins and options for defining the code repository like GitHub/SVN.

Regarding the Jenkins workflow, I had felt doubts and adding here,

1. If the Docker image is pulling from some image registries for deployment using Jenkins and Kubernetes, then why we again defining the code repositories source link (GitHub/SVN) in Jenkins?

Reason for doubt- I am thinking thinking that, Kubernetes and Jenkins are only depending image registry for deployment by image pulling. So I felt doubt that why we defining our GitHub repository link in Jenkins. This is only reason for this doubt. Please correct me if I am thinking in wrong direction.

2. When I am exploring I found that automated Docker image building option within Jenkins using some scripts (I don't know properly exact working, I found in you tube video). So if we are pulling image from image registry, Then why we again using automated Docker image build within Jenkins? If this is a alternative option, what is the difference between image pulling and automated image building in Jenkins? Is those all are according to our requirement? Or is there any other concept behind this?

Answer 1

I am sorry, but I did not fully understand your question. I try to explain our CI/CD workflow. Maybe this helps.

1. Developer commits code to GIT.
2. Jenkins automatically
   • checks out the repo
   • builds spring boot microservices (tests, code coverage, etc)
   • builds docker image
   • commit the docker images to a registry

With different switches/build parameters the developer can decide to build SNAPSHOT builds which are deployed only to a specific snapshot-registry for developers only, or to build real releases.

The developer can also decide to deploy the Docker image afterwards to the int or prod system. In this case Kubernetes pulls the image from the registry (which Jenkins previously deployed there).

Answer 2

We're working on an open source project called Jenkins X which is a proposed sub project of the Jenkins foundation aimed at automating CI/CD on Kubernetes using Jenkins and GitOps for promotion.

When you merge a change to the master branch, Jenkins X creates a new semantically versioned distribution of your app (pom.xml, jar, docker image, helm chart). The pipeline then automates the generation of Pull Requests to promote your application through all of the Environments via GitOps.

Here's a demo of how to automate CI/CD with multiple environments on Kubernetes using GitOps for promotion between environments and Preview Environments on Pull Requests - using Spring Boot and nodejs apps (but we support many languages + frameworks).

Note that Jenkins X only supports git right now though.