Table of contents
What is CI/CD ?
Continuous Integration (CI)
Imagine you're working on a team project where multiple people are contributing code to a single project. CI is the process of automatically building and testing that code to ensure it all works together seamlessly. Here's how it works:
Developers commit their code changes to the central code repository (like GitHub or Stash) frequently, usually multiple times a day.
Automated tools (like Jenkins or Travis CI) monitor the repository for new changes and trigger a build process when they detect any.
The build process compiles the newly committed code and runs a series of automated tests to ensure it meets the required standards.
If the code passes the tests, it's merged into the main codebase. If it doesn't pass, the developer who made the changes is notified, and they need to fix the issues before the code can be merged.
Once the code is merged, it's automatically tested again to ensure it works correctly with the rest of the codebase.
The benefits of CI are:
Faster bug detection and fixing: CI helps identify issues early on, so they can be addressed before they become bigger problems.
Easier collaboration: CI ensures that all developers are working with the same codebase, reducing conflicts and making it easier to integrate their work.
Improved software quality: By continuously building and testing the code, CI helps ensure that the software is stable and reliable.
Faster time-to-market: With CI, developers can release new features and updates more quickly, as the code is always ready to be deployed.
Continuous Delivery (CD)
CD is the process of ensuring that the software is always ready to be released to customers. It builds upon the foundation of CI by adding additional steps to ensure that the software is error-free and ready for production.Here's how it works:
After the code has been merged into the main codebase through CI, it's deployed to a staging environment (a testing environment that mimics the production environment).
In the staging environment, automated tests (like integration and regression tests) are run to ensure that the code works correctly and doesn't break any existing functionality.
If the code passes the tests, it's ready to be released to customers.
The release process is automated, so that the software can be deployed at any time.
The benefits of CD are:
Faster time-to-market: With CD, the software is always ready to be released, so new features and updates can be deployed quickly.
Reduced risk: By thoroughly testing the code in a staging environment, CD helps ensure that the software is error-free and won't break in production.
Improved quality: CD ensures that the software is thoroughly tested and validated before it's released to customers.
To conclude, CI is the process of automatically building and testing code changes to ensure they work together seamlessly, while CD ensures that the software is always ready to be released to customers by thoroughly testing it in a staging environment and automating the release process. Together, CI and CD help teams deliver high-quality software quickly and efficiently.
What is a Build Job?
Jenkins is a popular tool used for automating various tasks in the application-building process. A Jenkins build job contains the configuration for automating a specific task or step in the application building process. These tasks include gathering dependencies, compiling, archiving, or transforming code, and testing and deploying code in different environments.
Jenkins supports several types of build jobs, such as freestyle projects, pipelines, multi-configuration projects, folders, multibranch pipelines, and organization folders. Here are some of the most commonly used types of Jenkins build jobs:
Freestyle Project: This is a regular and popular job in Jenkins that allows us to build our project, integrate our builds or source code management with Jenkins, poll the SCM, create triggers, and many more**.**
Maven Project: Enables us to build our maven projects. We need to only specify the location of the pom.xml file, and Jenkins will automatically pick the POM files, make configurations, and run our build.
Pipeline: A pipeline is a set of instructions that can be processed by Jenkins to build, test, and deploy applications. It is a powerful tool that allows you to define complex build processes using a simple, easy-to-read syntax**.**
Multibranch Pipeline: This project type enables you to configure different jobs for different branches of the same project. In a multi-branch pipeline configuration, Jenkins automatically discovers, manages, and executes jobs for multiple source repositories and branches.
Jenkins build jobs are at the heart of the Jenkins build process. They can be considered as a particular task or step in your build process. By automating these tasks, Jenkins provides a mechanism to simplify the delivery of the product/software. Jenkins build jobs can be created, configured, and run to test applications or projects.
Tasks
1)
- Create an agent for your app. ( which you deployed from docker in earlier task)
Go to Manage Jenkins, click on set up Agent, give the agent node name, select a permanent option, and click on 'Create'.
Provide remote root directory location give labels to this node and select 'Use WebSocket'.
Click on save to create an agent and now the agent is created.
- Create a new Jenkins freestyle project for your app.
Go to new item and select a freestyle project and name it accordingly.Add a description.
As we are taking the SCM from Github select GitHub and as shown in the picture,insert the relevant links in place. (Note : The branch should be the same as the one shown on Github)
- 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 created in step 3.
Now click on Save and then build it.
We now need to check if this build is working.
The issue you can encounter here is that the port rules should be changed in the Security Management of the EC2 instance as explained in one of the last blogs.
Also, keep in mind that the relevant port should be exposed(this can be checked by going through the project's readme file) example here in this case port 8000.
2)
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.
All the steps for the project will be similar, only the build steps will differ.
echo "code cloned"
docker-compose down
docker-compose up -d --no-deps --build web
echo "code deploy"
Save it Run it and then build it by doing the same steps as done in task 01.
Thank you for reading and exploring my blog.
Lets connect :
LinkedIn