Pipeline as code with Jenkins
This chapter covers  How pipeline as code works with Jenkins  An overview of Jenkinsfile structure and syntax  Introduction to Blue Ocean, the new Jenkins user experience  Declarative versus scripted Jenkins pipelines  Integration of a GitFlow model within Jenkins projects  Tips for productivity and efficiency while writing Jenkinsfiles for complex CI/CD pipeline

There’s no doubt that cloud computing has had a major impact on the way companies build, scale, and maintain technology products. The ability to click a few buttons to provision machines, databases, and other infrastructure has led to an increase in developer productivity we’ve never seen before. 
→ cloud = increase agility in software teams 
While it was easy to spin up simple cloud architectures, mistakes can easily be made while provisioning complex ones. Human error will always be present, especially when you can launch cloud infrastructure by clicking buttons on the cloud provider’s web console.

The only way to avoid these kinds of errors is through automation, and infrastructure as code (IaC) is helping engineers automatically launch cloud environments quickly and without mistakes. The growth of DevOps and the adoption of its practices have led to more tooling that can implement the IaC paradigm to a larger degree.

 In the past, setting up CI/CD workflow has been a manual process. It was commonly done via defining a series of individual jobs for the various pipeline tasks. Each job was configured via web forms—filling in text boxes, selecting entries from dropdown lists, and so forth. And then the series of jobs were strung together, each triggering the next, into a pipeline.
Jenkins somewhat lagged in this area until the release of Jenkins 2. Although widely used and a primary workflow tool for creating CI/CD pipelines, this way of creating and connecting Jenkins jobs to form a pipeline was challenging. It did not meet the definition of IaC. Job configurations were stored only as Extensible Markup Language (XML) files within the Jenkins configuration area. This meant that the files were not easily readable or directly modifiable. And the Jenkins application itself provided the user’s primary view and access to them.
NOTE Jenkins 2 is the name we are generally applying to newer versions that support the pipeline-as-code functionality, as well as other features. 
→ from jenkins 2 version the concept of pipeline as code is introduced 

Introducing the Jenkinsfile Pipeline as code (PaC) describes a set of features that allow Jenkins users to define pipelined job processes with code, stored and versioned in a source repository. These features allow Jenkins to discover, manage, and run jobs for multiple source repositories and branches—eliminating the need for manual job creation and management.

PaC helps you automate the CI/CD workflows in a repeatable, consistent manner, which has many benefits:  Speed—You can quickly and easily write a CI/CD workflow for sandbox, staging, and production environments, which can help you deliver your product on time.  Consistency—PaC completely standardizes the setup of CI/CD, so there’s a reduced possibility of any human errors or deviations.  Risk management—Because the pipeline can be version-controlled, PaC allows every change to your CI/CD workflow to be documented, logged, tracked, and tested just like application code. Hence, you can revert to a working version in case of failure.  Efficiency—It minimizes the introduction of human errors and helps your application’s deployment run more smoothly.

The bottom line is simple: adopting the PaC paradigm will create a culture that generates better software, and will save you a lot of money, time, and headaches trying to implement complex CI/CD workflows through UIs and web forms. So how does PaC work with Jenkins?
→ adopting Pac paradigm will create a culture that generates better software 
→ save mony 
→ save times 
—> and headaches 
The core ideas presented about using Pipeline as Code (PaC) with Jenkins are:
Jenkinsfile for PaC: Projects using Jenkins for CI/CD should have a Jenkinsfile at the root of their repository. This file defines the pipeline.
Stages Define the Pipeline: The Jenkinsfile contains stages, which are the individual steps or tasks in the CI/CD process (e.g., build, test, deploy).
Automated Pipeline Execution: Whenever code is pushed to the repository, Jenkins automatically executes the pipeline defined in the Jenkinsfile. This is the core of continuous integration.
Jenkinsfile Under Version Control: The Jenkinsfile lives alongside the source code and is treated like any other code file. This enables:
Versioning: Track changes to the pipeline process itself.
Collaboration: Multiple developers can work on and improve the pipeline.
Rollback: Revert to earlier versions of the pipeline if necessary.


Code Reviews for Pipelines: Just like application code, the Jenkinsfile can undergo code reviews. This ensures quality, consistency, and best practices in the pipeline definition.
In essence, the passage emphasizes that using a Jenkinsfile brings the CI/CD pipeline under version control, making it more manageable, collaborative, and reliable. It treats the pipeline as code, subject to the same best practices as application code.
Jenkinsfile uses a domain-specific language (DSL) based on the Groovy programming language to define the entire CI/CD workflow. Figure 2.1 is an example of a classic CI/CD workflow.
—> Jenkinsfile use domain-specific language (DSL) based on the Groovy programming language 
Those phases can be described in a Jenkinsfile by using the stage keyword. A stage is a block that contains a series of steps. It can be used to visualize the pipeline process. The following listing is an example of a simple Jenkinsfile for figure 2.1.
→ stage is a block that contains a series of steps ,
→ it can be visualize as the pipeline process 
The following listing is an example of a simple Jenkinsfile for figure 2.1. node('workers'){ try { stage('Checkout'){ checkout scm } stage('Quality Test'){ echo "Running quality tests" } stage('Unit Test'){ echo "Running unit tests" } stage('Security Test'){ echo "Running security checks" } stage('Build'){ echo "Building artifact" } stage('Push'){ echo "Storing artifact" } Listing 2.1 Jenkinsfile stages 24 CHAPTER 2 Pipeline as code with Jenkins stage('Deploy'){ echo "Deploying artifact" } stage('Acceptance Tests'){ echo "Running post-integrations tests" } } catch(err){ echo "Handling errors" } finally{ echo "Cleaning up" } } We’ll dive deep into the syntax in the next chapter, but for now, let’s focus on what the stages are doing:  Checkout—Pulls the latest changes from the source code repository, which can be GitHub, Bitbucket, Mercurial, or any SCM.  Quality tests—Contains instructions on how to execute static code analysis to measure code quality, and identify bugs, vulnerabilities, and code smell. It can be automated by integrating external tools like SonarQube to fix code-quality violations and reduce technical debt.  Unit tests—In this stage, unit tests are executed. If tests are successful, a code coverage report will be generated that can be consumed by Jenkins plugins to show a visual overview of the project’s health and keep track of the code coverage metrics as your project grows. Code coverage can be an indication of how much your application code is executed during your tests, and can give some indication as to how well your team is applying good testing practices such testdriven development (TDD) or behavior-driven development (BDD).  Security tests—Responsible for identifying project dependencies and checks if any known, publicly disclosed vulnerabilities exist. A security report will be published with the total number of findings grouped by severity (critical, high, medium, or low). A well-known open source Jenkins plugin is OWASP Dependency-Check (http://mng.bz/MvR7).  Build—In this phase, the needed dependencies will be installed, the source code will be compiled, and an artifact will be built (Docker image, zip file, Maven JAR, and so forth).  Push—The artifact built in the previous stage will be versioned and stored in a remote repository.  Deploy—In this stage, the artifact will be deployed to a sandbox/testing environment for quality assurance or to production after the user has approved the deployment.  Acceptance tests—After the changes are deployed, a series of smoke and validation tests will be executed against the deployed application to verify that the application is running as expected. The tests can be simple health checks with cURL commands or sophisticated API calls. Introducing the Jenkinsfile 25 If any of these stages throws an exception or error, the pipeline build’s status will be set to fail. This default behavior can be overridden by using try-catch blocks. The finally block can be used to clean up the Jenkins workspace (temporary files or build packages) or to execute post-script commands such as sending Slack notifications to alert the development team about the build status.

Q- just for the proof of concept using docker , spring boot , and jenkins give me step by step tutor from spring insilser inter running the pipeline how to create this demo  ?