Day 23 Task: Jenkins Freestyle Project for DevOps Engineers.

What is CI/CD?

Continuous Integration and Continuous Deployment (CI/CD)

CI/CD is a set of practices and methodologies that aim to streamline and automate the process of building, testing, and deploying software applications. These practices promote collaboration, speed, and reliability throughout the software development lifecycle.

Continuous Integration (CI): CI is the practice of frequently integrating code changes from multiple developers into a shared repository. With CI, developers regularly commit their code changes to a version control system (like Git), and an automated build process is triggered. The code is compiled, tested, and verified to detect integration issues and bugs early on. This ensures that the main codebase remains stable and consistent, as any issues are identified and resolved rapidly.

Benefits of CI:

Early bug detection
Faster feedback loop
Improved code quality
Increased collaboration

Continuous Deployment (CD): CD takes CI a step further by automating the deployment of code changes to production or staging environments after successful testing. When code passes all tests in the CI process, it is automatically deployed to production, making the release process quick and efficient. CD aims to deliver new features and updates to end-users as soon as they are ready, reducing manual interventions and deployment errors.

Benefits of CD:

Faster time-to-market
Lower risk of manual errors
Increased release frequency
Improved customer satisfaction

Continuous Delivery vs. Continuous Deployment: Continuous Delivery (CD) and Continuous Deployment (CD) are often used interchangeably, but there is a subtle difference. In Continuous Delivery, code changes are automatically prepared and verified for deployment to production, but the actual deployment to production is still triggered manually. In Continuous Deployment, the code is automatically deployed to production without human intervention once it passes all tests in the CI process.

What Is a Build Job?

In Jenkins, a Build Job represents the fundamental unit of work that automates the process of building and testing software applications. It is a critical component of the Continuous Integration (CI) process. A Build Job defines the steps and actions needed to compile source code, run tests, and produce artifacts (such as executables or libraries) from the source code.

The Anatomy of a Build Job: A typical Build Job in Jenkins consists of the following elements:

Source Code Management (SCM): This defines the source code repository from which Jenkins fetches the latest code changes. Common SCMs supported by Jenkins include Git, Subversion, and Mercurial.
Build Triggers: These determine when the build should be triggered. Common triggers include scheduled builds, code commits, pull requests, or dependencies on other jobs.
Build Steps: These are the heart of the Build Job. Build Steps define the specific actions to be taken during the build process, such as running build scripts, compiling code, and executing tests.
Post-Build Actions: These are actions performed after the build is complete, such as archiving artifacts, sending notifications, or triggering downstream jobs.

Purpose and Benefits of Build Jobs: Build Jobs serve several essential purposes in the CI/CD pipeline:

Automated Builds: Build Jobs automates the build process, ensuring that code changes are automatically built and tested as soon as they are committed, preventing integration issues.
Consistency and Reproducibility: Build Jobs enforce a consistent build environment, ensuring that every build is reproducible and independent of the developer's machine.
Early Bug Detection: By running tests in the build process, Build Jobs help identify and address bugs and issues early in the development cycle.
Faster Feedback Loop: Automated builds and tests provide developers with rapid feedback on the code changes they make, reducing the time between code commits and issue identification.
Facilitating Collaboration: Build Jobs promotes collaboration among team members by providing a centralized and standardized way to build, test, and share code.

Jenkins Build Job Configuration: In Jenkins, Build Jobs are created using the Jenkins web interface. Users can define the build steps, triggers, and post-build actions through the Jenkins UI or by using a Jenkinsfile for the pipeline-as-code approach.

In summary, a Build Job in Jenkins is a crucial component of the CI/CD pipeline that automates the build process, ensuring code changes are continuously integrated, tested, and delivered with efficiency and reliability.

What is Freestyle Projects ??

Freestyle Projects in Jenkins are one of the oldest and most versatile project types available. They allow users to create custom build and deployment pipelines using a combination of build steps and post-build actions.

While Freestyle Projects are still widely used, Jenkins users are increasingly adopting newer pipeline-based projects, such as Jenkins Declarative Pipelines or Jenkinsfile-based pipelines. These pipeline approaches provide more structured and versionable ways to define and manage complex build and deployment processes.

In conclusion, Freestyle Projects offers a flexible and straightforward approach to building and deploying software in Jenkins. They remain a valuable option for users with specific requirements or those transitioning from older Jenkins configurations.

Task 1

Create a new Jenkins freestyle project for your app.

Click on 'New item' and enter the name of the project and select 'Freestyle Project'. Add the GitHub path where your docker file is present.

In the "Build" section of the project, add a build step to run the "docker build" command to build the image for the container.
Add a second step to run the "docker run" command to start a container using the image.

Task 2: Docker-compose

Create Jenkins project to run "docker-compose up -d" command to start the multiple containers defined in the compose file (Hint- use day-19 Application & Database docker-compose file)
Set up a cleanup step in the Jenkins project to run "docker-compose down" command to stop and remove the containers defined in the compose file.

Thanks for reading the blog & do share them with someone in need.

Please share your views and suggestions, they are always welcome.

See you then in the next blog.