Ultimate CICD Pipeline Explanation of Flow
Ultimate CICD Pipeline Explanation of Flow
Jenkins Pipeline only doing the continous integration here till New image
pushed to dockerhub as after that there is pull mechanism and after part
is continous delivery.
CI - Ensures that build is smooth , all test are executed , code quality is
maintained and image is created things like these.
We can go to jenkins and get the webhook url and put it into the settings
and where you can define for which actions webhooks has to be triggered
like on commit pull request and on issues.
As first git hub will trigger the change to the webhook and it will be pulled
by jenkins then jenkins using maven will build the application.
To configure the maven plugin we go to jenkins and go to configure
system and install maven or the other thing we can use a docker agent
directly so we don’t have to do installation and configuration by ourself as
there are already prepared docker agents are available.
As part of build unit test runs and if successful then can perfom static
code analysis then on next stage if your build stage goes down or fails
therefore in such cases you can configure some alerts using API's via
plugins and then it goes to the next stage where we can integrate it with
Sonar cube or any other code scanning tools or the security scanning
tools so that we can verify what happed in your previous stage and check
is it reached a specific threshold of our organisation then if there are no
security vulnerabilities then we can proceed with the creation of docker
image or we can create a docker plugin here to by writing a shell script
then we will send that docker image to a docker registry.
Jenkins also can talk to jenkins using polling and can also configure some
Now in the end of CI you have a image ready with new tag and the image
artifact with the new version will be pushed into the docker container
registry.
Now the CD part needs to start with continous delivery tools in which
gitops based are best because what git ops says and practices is smaller to
our source code.
We should use git repository for application manifest too which contains
files like pod.yaml , deploy.yaml and service.yaml and we use this so that
not anyone without checking can enter into the cluster to update the
pod.yaml.
Argo image updater we can use to know whenever an new image version
is pushed to the registry it directly update the git repository and there
Argo CD is contiously watching the git repositroy and whenever the
change arrives then take the new helmchart , pod.yml , deploy.yml and
service.yml to the kubernetes cluster.
CI PROCESS -