0% found this document useful (0 votes)
649 views

CI CD PipeLine

CI/CD pipelines allow developers to frequently and reliably integrate changes into shared code repositories. With CI, each commit triggers an automated build and testing process. This helps catch errors early and improves code quality. CD then automates the deployment of code changes to production environments. Together, CI/CD support continuous delivery of code in a safe and sustainable manner.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
649 views

CI CD PipeLine

CI/CD pipelines allow developers to frequently and reliably integrate changes into shared code repositories. With CI, each commit triggers an automated build and testing process. This helps catch errors early and improves code quality. CD then automates the deployment of code changes to production environments. Together, CI/CD support continuous delivery of code in a safe and sustainable manner.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

CI CD PipeLine

Whenever we are working with any product or document we should have the
version and the date of issue of the document. By this we can identify which
version has got what changes and for which period of time.

Why do we use Git?


Git is a version control system, in a team several developers are working on the
same project and they all are committing their code over the git. Now if
someone wants to see what changes has done recently and what was the
problem with older version, they can see the changes on Git.

If we talk about of old approach for managing projects versions, we used to


save the project with the name calculator (V1) and put it into a separate folder
in drop box. After doing some changes and modifications into a code it will be
second version of your project which is calculator (V2). But managing project
by this approach is very difficult, because it requires many folders for different
version has to be created and it is very difficult to remember that which folder
version has got what features.

To solve this problem we use GIT, Git uses distributed version control system.
But before Distributed version control we used to follow central version control
system.

Centralized version control System:


Distributed version control System:

Distributed version control system means, we can have a local repository for
each developer and they can work on it and make changes. Git will take care of
version control system, and finally we can push the code to the remote
repository.

Master branch:
A place where a final solution will be available.
DevOps:

Developer:
A developer is responsible for writing the code as per the client requirement
without any bugs.

Operations:
Operations are used to deploy the application in the production environment
also need to maintain the application and troubleshoot whenever it is needed.

DevOps Definition:

DevOps is the combination of development and Operations

Here developer is responsible of developing and deploying the application but


using some software tools.

 Dependency management
 Infrastructure as code  chef, puppet
 Vigrant is also a devOps tool for creating virtual machine on top od OS

Nightly build System:

In the context of software development, build refers to the process that


converts files and other assets under the developers’ responsibility into a
software product in its final or consumable form.

Developers write source code in human readable programming languages which


is then needs to be processed further so it can be deployed, for example, to a
production server.
These processing steps could be compiling Java or C++ to binary format.
The build may include:

 compiling source files


 packaging compiled files into compressed formats (such as jar, zip)
 producing installers
 creating or updating of database schema or data

The underlying idea behind a nightly build is that developers do not work on the
source code at night, so the build process does not interfere with anybody’s
work and they have to wait for the current version to deploy. Thus, a nightly
build makes sense for organizations unless they are working on common
software in opposite time zones that are far apart.

Ideally, software development should only take place in one time zone or, at
best, in closely spaced time zones.

Note: But during the built process, if any developers make some changes in the
source code, then the built error will occur. Because of this all developers have
to wait until the issue gets fixed and they can’t make any changes in the source
code until the problem resolved.

To solve this problem we use CI CD.

CI (Continuous Integration):
In continuous integration (CI) after every commit done by a developer, it will go
for built process, and during the built process it will go through build, test and
finally it will give you a success/failure message based on the last commit.
Example: Hobbes for Assignment

CI (Continuous Integration):
1. Continuous integration is a development practice that requires developers
to integrate code into a shared repository several times a day
2. Each check-in is then verified by an automated build, allowing teams to
detect problems early
3. By integrating regularly, you can detect errors quickly, and locate them
more easily
4. Continuous integration is a way to increase code quality without putting
an extra burden on a developer.
5. Tests and checks of your code are handled on a server and automatically
reported back to you.

Why CI?
1. Run your tests in the real world
2. Increase your code coverage
3. Deploy your code to production
4. Built stuff now
5. Built stuff faster
6. Don’t break stuff
7. Decrease code review time

CI Process:
1. Developers check out code into their private workspaces
2. When done, commit the changes to the repository
3. The CI server monitors the repository and check out changes when they
occur
4. The CI server builds the system and runs unit and integration testing
5. The CI server releases deployable artefacts for testing
6. The CI server assigns a build label to the version of the code it just built
7. The CI server inform the team of the successful built
8. If the build or tests fails, the CI server alerts the team
9. The team fixes the issues at the earliest
10. Continue to integrate and test throughout the project

CI Tools:
 Jenkins
 Circle CI
 Travis CI
 Github CI
 Gitlab CI

The common thing among all this tools are, they all are using yml for
configuration.

Every CI tool has its own configuration file name format, for Gitlab CI it is as
follows:

.gitlab-ci.yml

After creating an yml file we need to create a runner using a runner machine or
we can call it as Virtual Machine. This runner machine will be responsible to
execute the pipeline, where each pipeline is going to clean, compile, from
maven and run the test cases, and finally it will tell you that you are good go.

You might also like