The document discusses Continuous Integration Continuous Delivery (CICD) end-to-end flows. It describes how code committed to GitHub by a development team triggers a child pipeline to run tests and analysis in parallel. If successful, a merge request is created and sent for approval. If approved, the master pipeline is triggered to deploy to QA, perform testing, and deploy to staging and production while sending notifications. It also discusses configuring Jenkins masters and slaves, using webhooks to trigger pipelines from GitLab branches, and the different types of Jenkins pipelines including declarative and scripted.
The document discusses Continuous Integration Continuous Delivery (CICD) end-to-end flows. It describes how code committed to GitHub by a development team triggers a child pipeline to run tests and analysis in parallel. If successful, a merge request is created and sent for approval. If approved, the master pipeline is triggered to deploy to QA, perform testing, and deploy to staging and production while sending notifications. It also discusses configuring Jenkins masters and slaves, using webhooks to trigger pipelines from GitLab branches, and the different types of Jenkins pipelines including declarative and scripted.
The document discusses Continuous Integration Continuous Delivery (CICD) end-to-end flows. It describes how code committed to GitHub by a development team triggers a child pipeline to run tests and analysis in parallel. If successful, a merge request is created and sent for approval. If approved, the master pipeline is triggered to deploy to QA, perform testing, and deploy to staging and production while sending notifications. It also discusses configuring Jenkins masters and slaves, using webhooks to trigger pipelines from GitLab branches, and the different types of Jenkins pipelines including declarative and scripted.
The document discusses Continuous Integration Continuous Delivery (CICD) end-to-end flows. It describes how code committed to GitHub by a development team triggers a child pipeline to run tests and analysis in parallel. If successful, a merge request is created and sent for approval. If approved, the master pipeline is triggered to deploy to QA, perform testing, and deploy to staging and production while sending notifications. It also discusses configuring Jenkins masters and slaves, using webhooks to trigger pipelines from GitLab branches, and the different types of Jenkins pipelines including declarative and scripted.
Download as PPTX, PDF, TXT or read online from Scribd
Download as pptx, pdf, or txt
You are on page 1/ 12
CICD End To End Flow
Session 6
By Praveen Singampalli
By Praveen Singampalli 11th June 2022(4-6 PM) 1)Why CICD and E2E Flow RoadMap
CICD 6) Sonar Analysis
2) How to implement CICD
discussion: 5) WebHook 3) What tools Trigger are needed
4) Auto Version implementation in Github Different types of Jenkins Pipeline • Declarative Pipeline Syntax The declarative syntax is a new feature that uses code for the pipeline. It provides a limited pre-defined structure. Thereby, it offers an easy & simple continuous delivery pipeline. Moreover, it uses a pipeline block. • Scripted Pipeline Syntax Unlike declarative syntax, the scripted pipeline syntax is the old traditional way to write the Jenkinsfile on Jenkins web UI. Moreover, it strictly follows the groovy syntax and helps to develop a complex pipeline as code. Scripted Pipeline Declarative Pipeline(Jenkinsfile add to git repo )
JenkinsFile Data Key concepts of Jenkinsfile
• Pipeline - A pipeline is a set of instructions that includes the processes of continuous delivery. For example, creating an application, testing it, and deploying the same. Moreover, it is a critical element in declarative pipeline syntax, which is a collection of all stages in a Jenkinsfile. We declare different stages and steps in this block. • pipeline{ } Node - A node is a key element in scripted pipeline syntax. Moreover, it acts as a machine in Jenkins that executes the Pipeline. • node{ } Stage - A stage consists of a set of processes that the Pipeline executes. Additionally, the tasks are divided in each stage, implying that there can be multiple stages within a Pipeline. The below snippet shows the different stages that one can define in a Pipeline. • Steps - A step in Jenkins defines what we have to do at a particular step in the process. There can be a series of steps within the stage. Moreover, whatever step we define in a stage would be executed within it. • Agent - An agent is a directive that enables the users to execute multiple projects within the same Jenkins instance by distributing the load. Moreover, we assign an executor to the build through an agent. You can either use a single agent for the entire pipeline or use a distinct agent for the different stages of the pipeline. Subsequently, some of the parameters used with agents are - • Any- Any of the available agents execute the pipeline. • None- It is used at the pipeline root and implies no global agent, but each stage must specify its own agent. • Label- The labeled agent is used to execute the pipeline or the specific stage. • Docker- One can use the Docker images as the execution environment & specifying the agent as docker. Child Pipeline -
Sonar/Blackduck/Fortify(Stage 1 - In Parallel) Build Code (Maven) Artifact Push (Jfrog) Pull Artifact(Ansible) Deployment to QA(OnPrem/Cloud) Performance testing/Integration testing Deployment to Syage Send Notification via Email • In your project or group, on the left sidebar, select Settings > Webhooks. • In URL, enter the URL of the webhook endpoint. Webhook Setup • In Secret token, enter the secret token to validate payloads. • In the Trigger section, select the events to trigger the webhook Jenkins Master slave Config 1 2
3 4
5 Trigger a pipeline from JenkinsFile GitLab Branching Strategy • Master Branch – This branch mainly deals with the prod deployment(Prod Pipeline) • Hotfix Branch – This branch deals with any issues related to prod fixes (Bug/Feedback from customer)(Hotfix Pipeline) • Release Branch (Release Pipeline) – The code from this branch is deployed in higher environments(QA/STAGE) except prod • Develop Branch (Dev Pipeline)– Called as Dev branch and it deals with the changes done by developers for their own branch • Feature Branch – Deals with the new features taken up for the sprint(We usually use to merge the feature to release branch and then deploy) THANK YOU ALL
