What is CI/CD?

CI/CD stands for Continuous Integration and Continuous Delivery/Continuous Deployment, and it represents a set of practices and principles aimed at improving the software development and delivery process. These practices help automate and streamline the building, testing, and deployment of software applications, leading to more efficient development cycles, faster releases, and higher software quality.

1. Continuous Integration (CI):

   • Objective: The primary goal of CI is to integrate code changes from multiple contributors into a shared repository frequently.

   • Process:

     • Developers regularly commit code changes to a version control system (e.g., Git).

     • An automated CI server (such as Jenkins) monitors the repository for changes.

     • Upon detecting changes, the CI server triggers an automated build process to compile the code, run tests, and generate artifacts.

     • The CI server provides immediate feedback to developers, indicating whether the build was successful or if there are issues that need attention.

Continuous Integration helps identify integration issues, bugs, and conflicts early in the development process, enabling teams to address them promptly.

1. Continuous Delivery (CD):

   • Objective: Continuous Delivery extends the principles of CI to automate the entire software release process, making it ready for deployment at any time.

   • Process:

     • Automated builds and tests are performed as part of the CI process.

     • After successful builds and tests, the software is automatically staged in a pre-production environment.

     • The deployment to production is a manual decision, but the entire process leading up to deployment is automated.

     • The software in the pre-production environment is production-ready and undergoes additional testing and validation.

Continuous Delivery ensures that software is always in a deployable state, allowing teams to release new features or bug fixes to production quickly and with confidence.

1. Continuous Deployment (CD):

   • Objective: Continuous Deployment takes the automation further by automatically deploying every successful build to production without manual intervention.

   • Process:

     • Similar to Continuous Delivery, automated builds, tests, and staging are performed.

     • However, in Continuous Deployment, the decision to deploy to production is automated and immediate upon a successful build and test cycle.

Continuous Deployment aims to reduce the time between code changes and making those changes available to end-users. It requires a high level of confidence in the automated testing and deployment processes.

What Is a Build Job?

A build job, in the context of continuous integration and build automation, refers to the automated process of compiling, assembling, and testing source code to produce executable software or artifacts. Build jobs are typically defined and executed by a continuous integration (CI) server, and they play a crucial role in the CI/CD pipeline.

Here's an overview of what a build job involves:

1. Source Code Retrieval:

   • The build job starts by retrieving the latest version of the source code from a version control system (e.g., Git, SVN).

2. Compilation and Assembly:

   • The source code is compiled into executable binaries or libraries. This step involves translating human-readable source code into machine-readable code.

3. Dependency Resolution:

   • Build jobs often involve resolving dependencies, which are external libraries or modules required by the application. These dependencies are typically specified in a configuration file (e.g., a package.json file for Node.js projects).

4. Unit Testing:

   • Automated tests, known as unit tests, are executed to verify that individual components of the code function as expected. Unit testing is a critical step in ensuring the correctness of the code.

5. Artifact Generation:

   • The build job produces artifacts, which are the output of the build process. These artifacts can include executable files, libraries, configuration files, or any other files necessary for the application to run.

6. Publishing Artifacts:

   • After a successful build, the artifacts are typically published or stored in a designated location, often referred to as a repository. This can be a local repository, a cloud-based repository, or a container registry, depending on the technology stack.

7. Reporting:

   • The build job generates reports summarizing the results of the build process. This may include information on test results, code coverage, and other relevant metrics.

8. Notification:

   • The CI server notifies relevant stakeholders, such as developers or the operations team, about the outcome of the build job. Notifications may include success messages or details about any issues encountered during the build.

What is Freestyle Projects ??

A freestyle project in Jenkins is a type of project that allows you to build, test, and deploy software using a variety of different options and configurations. Here are a few tasks that you could complete when working with a freestyle project in Jenkins