AUTOMATING INFRASTRUCTURE

DEPLOYMENT AND APPLICATION

DELIVERY ON AWS WITH CI/CD
1
Ashutosh Sharma, 2Sushant Mishra, 3Tanay Pandey, 4Vishakha Tomar

Department of Computer Science and Engineering

Shri Ram Murti Smarak College Of Engineering And Technology, Bareilly

Mail us : tny.pndy@gmail.com , mishrasushant1920@gmail.com

ashutoshsharma20011114@gmail.com

Abstract testing the functionality of the software, building

the software with build tools, adding features to the
Continuous Integration and Delivery (CI/CD)
software, fixing bugs, realising new versions and
pipelines entail the build process automation on
managing versions, maintaining the infrastructure,
dedicated machines, and have been demonstrated to
moving to different infrastructure etc. These tasks
produce several advantages including early defect
are separate tasks and all of them are particularly
discovery, increased productivity, and faster release
important for a successful software development
cycles. The effectiveness of CI/CD may depend on
project. Managing these tasks manually is very
the extent to which such pipelines are properly
time consuming and resource intensive and is often
maintained to cope with the system and its
prone to errors. Hence, we need automated system
underlying technology evolution, as well as to limit
which takes care of connecting these tasks and
bad practices.
running them based on the defined set of rules. This
system is analogous to an automated Continuous
Integration and Continuous Delivery (and
1. Introduction Continuous Deployment) pipeline. A practice
The definition of the modern world would be which simplifies the process of performing the
imperfect without the mention of software development tasks of SDLC and focuses on quality
development. Due to this rising demand for IT assurance and successful release of the product is
products, new methods are required to called Continuous Integration and Continuous
revolutionize how software’s are developed. In Delivery (and Continuous Deployment). As the
order to meet this rapidly growing demand, name suggests, it is a continuous process and a part
software companies have evolved different of the overall software development project. A set
methodologies, such as Agile, Continuous of tasks which are well defined and are
Integration(C.I.), Continuous Deployment, automatically triggered based on the defined rules
Continuous Delivery , DevOps and more. and correspond to the CICD practices is a CICD
pipeline. The practice of Continuous Integration
“Software methodologies now focus on developing and Continuous Delivery (and Continuous
software applications that are highly adaptable and Deployment) is perfectly compatible with Agile
can be changed easily over time, resulting in less of methodology of software development project
a need for rigid, upfront planning.” (Ingeno, 2018) management.
The various stages of the SDLC and the tasks “Continuous Integration, Delivery, and Deployment
involved there need to be somehow integrated well are relatively new development practices that have
to make sense and deliver a product. Some of the gained a lot of popularity in the past few years.
most common tasks except 3 the administrative Continuous Integration is all about validating
tasks in the SDLC are writing code, maintaining software as soon as it's checked in to source
the code-base in a repository, testing the code, control, more or less guaranteeing that software
works and continues to work after new code has not even be necessary for a single software
been written. Continuous Delivery succeeds development project. Also, all the tools used have
Continuous Integration and makes software just a their alternatives which may have certain benefits
click away from deployment. Continuous over the tools used in this implementation.
Deployment then succeeds Continuous Delivery Specifically, our choice of version control system
and automates the entire process of deploying GIT can be easily replaced by SVN (However not
software to your customers (or your own servers).” so popular), Bitbucket can easily be replaced by
(Sander Rossel, 2017) GitHub, Gitlab or other cloud repository providers,
AWS can easily be replaced by Azure, GCP or
One important purpose of adopting a CICD some other etc. The choice is, and always should
pipeline in the industrial scene is to effectively be, upon the developer, depending on the
integrate code changes, effortlessly perform the requirement specifications, to decide what kind of
tests and reducing the time for the software tools and technology should be used.
delivery into production so that the new features
are available for the end users in the earliest
manner and the company stays ahead of the
3. Concept and Background Of CI/CD
competition. For the software developers, adoption
of CICD practices frees them from mundane Once upon a time, a developer would spend a few
repetitive tasks and supplies them more time to months building a new feature. Then they’d go
focus on developing new features at the same time through the gargantuan effort of “integration”. That
reduces the risk of introducing many bugs and is, merging their changes into an upstream code
misconfiguring the infrastructure. repository, which had inevitably changed since they
started their work.
This task of integration would often introduce
2. Literature Review regressions, bugs, and in some cases might even be
impossible or irrelevant, leading to months of lost
All software development work is different and work.
there are differences in preferences of tools and Then, probably in the 1990s, someone had the
technology used among developers themselves, the bright idea of doing integration continuously. This
architecture of a potential CI/CD pipeline must be reduced the integration risk substantially, by
carefully thought of. Also, a CI/CD pipeline can be minimizing, and frequently completely eliminating,
simpler, if the project does not require all the aspect the code drift that happens between the mainline
of the pipeline, or quite complex if the project branch and an in-progress feature.
requires many steps and iterations and involved a This continuous integration was greatly aided by
lot of intermediary processes. Often, a simple the now ubiquitous automated test pipeline, which
CI/CD setup can sufficiently work as a starting helps ensure that each incremental change doesn’t
point for a beginning of the software development introduce unintentional behavioral regressions.
project, and as the team grows and the development Then, starting around 2009, we started hearing
work advances forward, more components can about Continuous Deployment and Continuous
easily be added and the pipeline can be modified. Delivery, which as a concept, are “in essence the
Working with DevOps mentality, adopting Agile principle of continuous integration [pipelines]
way of working and using CICD pipelines, hence, taken to its logical conclusion”, according to
has clear benefits and improves the quality of not authors Jez Humble and Dave Farely.
only the software but the software development Traditionally, most organizations tend to follow this
process as well. It is financially beneficial for same chronology when implementing Continuous
companies to adopt these practices and encourage Deployment, as well.
their developers to use automated CICD pipelines. They start by building an automated test suite, then
It has also been clear from this research that the putting them into a pipeline that runs for every
automated CICD pipelines can reduce the risk of code change. Some time later they’ll start doing
project failure, create more feedback loop automated builds, perhaps nightly at first, then
enhancing the communication and keep increase eventually for every code change. At some point in
the overall efficiency of software development the future, when they’re confident that their entire
pipeline is reliable, they’ll start deploying these
teams.
builds into production automatically.
Some of the components of the CICD pipeline such
as deployment in a containerised environment may
Continuous Integration and Continuous Delivery CI/CD is an automated process that involves
(CI/CD) is a software development approach that frequent code integration, automated testing, and
aims to improve the speed, efficiency, and continuous deployment of software changes to
reliability of software delivery. This approach production.
involves frequent code integration, automated Let's explain each step in a little more detail:
testing, and continuous deployment of software Code Integration
changes to production. The first step in the CI/CD pipeline is code
integration. In this step, developers commit their
Before the adoption of CI/CD in the software code changes to a remote repository
development industry, the common approach was a (like GitHub, GitLab or BitBucket), where the code
traditional, waterfall model of software is integrated with the main codebase.
development This step aims to ensure that the code changes are
In this approach, developers worked in silos, with compatible with the rest of the codebase and do not
each stage of the software development life cycle break the build.
completed in sequence. The process typically  Automated Testing Once the code is
involved gathering requirements, designing the integrated, the next step is automated
software, coding, testing, and deployment. testing. Automated testing involves
running a suite of tests to ensure that the
The disadvantages of this traditional approach code changes are functional, meet the
include: expected quality standards, and are free of
defects.
 Slow Release Cycles: Since each stage of
This step helps identify issues early in the
the software development life cycle was
development process, allowing developers
completed in sequence, the release cycle
to fix them quickly and efficiently.
was slow, which made it difficult to
 Continuous Deployment After the code
respond quickly to changing customer
changes pass the automated testing step,
needs.
the next step is continuous deployment. In
 High Failure Rates: Software projects
this step, the code changes are
were prone to failure due to a lack of
automatically deployed to a staging
automated testing, which meant that
environment for further testing.
developers had to rely on manual testing,
This step aims to ensure that the software
leading to errors and bugs in the code.
is continuously updated with the latest
 Limited Collaboration: The traditional
code changes, delivering new features and
approach did not encourage collaboration
functionality to users quickly and
between developers, testers, and other
efficiently.
stakeholders, which made it difficult to
 Production Deployment The final step in
identify and fix issues.
the CI/CD pipeline is production
 High Cost: The manual nature of software
deployment. In this step, the software
development meant that it was expensive,
changes are released to end-users. This
with high costs associated with testing,
step involves monitoring the production
debugging, and fixing errors.
environment, ensuring that the software is
 Limited Agility: Since the traditional
running smoothly, and identifying and
approach was linear, it was not possible to
fixing any issues that arise.
make changes to the software quickly or
The four steps of a CI/CD pipeline work together to
respond to customer needs in real-time.
ensure that software changes are tested, integrated,
CI/CD emerged as a solution to these and deployed to production automatically. This
disadvantages, by introducing a more agile and automation helps to reduce errors, increase
collaborative approach to software development. efficiency, and improve the overall quality of the
CI/CD enables teams to work together, integrating software.
their code changes frequently, and automating the By adopting a CI/CD pipeline, development teams
testing and deployment process. can achieve faster release cycles, reduce the risk of
software defects, and improve the user experience.
Keep in mind that the pipeline stages might look
different given the specific project or company
4.Working of CI/CD we're talking about. Meaning, some teams might or
might not use automated testing, some teams might
or might not have a "staging" environment, and so  Highly customizable with a wide range of
on. plugins
The key parts that make up the CI/CD practice are  Supports integration with various tools
integration and deployment. This means that the and technologies
code has to be continually integrated in a remote  Provides detailed reporting and analytics
repository, and that this code has to be continually
deployed to a given environment after each Cons:
integration.  Requires some technical expertise to set
The Key Benefits of CI/CD up and maintain
The key benefits of CI/CD include:  Can be resource-intensive, especially for
 Faster Release Cycles: By automating the large projects
testing and deployment process, CI/CD  Lack of a centralized dashboard for
enables teams to release software more managing multiple projects
frequently, responding quickly to customer
needs.
 Improved Quality: Automated testing
Travis CI -Travis CI is a cloud-based CI/CD
ensures that software changes do not
platform that provides automated testing and
introduce new bugs or issues, improving
deployment for software projects. It supports
the overall quality of the software.
several programming languages and frameworks,
 Increased Collaboration: Frequent code
making it suitable for various development
integration and testing require developers
environments. Some of its key features include:
to work closely together, leading to better
collaboration and communication. Pros:
 Reduced Risk: Continuous deployment
allows developers to identify and fix  Easy to set up and use
issues quickly, reducing the risk of major  Cloud-based, so there's no need to set up
failures and downtime. and maintain infrastructure
 Cost-Effective: CI/CD reduces the  Supports a wide range of programming
amount of manual work required to deploy languages and frameworks
software changes, saving time and  Provides detailed reporting and analytics
reducing costs.
Cons:
In summary, CI/CD emerged as a solution to
the limitations of the traditional, linear  Limited customization options
approach to software development. By  Not suitable for large projects with
introducing a more agile and collaborative complex requirements
approach to software development, CI/CD  Limited support for on-premise
enables teams to work together, release installations
software more frequently, and respond quickly
to customer needs.
GitHub actions - GitHub Actions is a powerful
5.Tools For CI/CD CI/CD tool that allows developers to automate
workflows, run tests, and deploy code directly from
There are several tools available for implementing their GitHub repositories.
CI/CD pipelines in software development. Each
tool has its unique features, pros, and cons. Here Pros:
are some of the most commonly used tools in
 Integrated with GitHub
CI/CD pipelines today:
 Easy to use
Jenkins - Jenkins is an open-source automation  Provides large ecosystem and good
server that is widely used in CI/CD pipelines. It is documentation
highly customizable and supports a wide range of
Cons:
plugins, making it suitable for various development
environments. Some of its key features include:  Limited build minutes
 Complex YAML syntax
Pros:
Built-in CI/CD features by hosts
Popular hosts such as Vercel or Netlify have built- Continuous Integration and Continuous Delivery
in in CI/CD features that allow you to link an provides an ideal scenario for your organization’s
online repository to a given site, and deploy to that application teams. Your developers simply push
site after a given event occurs in that repo. code to a repository. This code will be integrated,
tested, deployed, tested again, merged with
Pros: infrastructure, go through security and quality
 Very simple to set up and use reviews, and be ready to deploy with extremely
high confidence. When CI/CD is used code quality
Cons: is improved, and software updates are delivered
quickly and with high confidence that there will be
 Limited customization options.
no breaking changes. The impact of any release can
be correlated with data from production and
operations. It can be used for planning the next
6. Result Analysis cycle, too—a vital DevOps practice in your
organization’s cloud transformation
After the complete development of our
application, the master code is pushed to 8. References
GitLab, which activates the CI/CD pipeline. 1. https://www.theseus.fi/bitstream/handle/
This pipeline implements the instructions 10024/345618/
from the .yml file (created previously) on to Thesis_Ramesh_Ghimire_1.pdf?
the master code, and during this process, sequence=2
creates a build application version out of the 2. https://jhall.io/archive/2021/09/26/a-brief-
history-of-ci/cd/
master code, tests it and deploys it to the
3. https://www.freecodecamp.org/news/what-
Fly.io server. The figure shows that the is-ci-cd/
pipeline run’s seven pre-defined jobs, two for 4. https://www.oreilly.com/library/view/
building, four for testing and one for building-cicd-systems/9781801078214/
deploying the application. All the passed jobs B17154_01_Final_JM_ePub.xhtml
are marked with a green tick and jobs that 5. https://docs.aws.amazon.com/
whitepapers/latest/practicing-continuous-
failed are marked with a red tick as seen in the
integration-continuous-delivery/
figure below. Also, jobs that failed but did not welcome.html
stop the pipeline execution are marked with
an exclamation mark. 6. https://www.theseus.fi/bitstream/

The next step is to check the efficiency of the handle/10024/786622/

CI/CD pipeline. One way to test the pipeline’s Singh_Vikas.pdf;jsessionid=670DBC48
productivity is by checking the run time of the
3BF62D5343654DC90413F103?
pipeline for one complete execution. The
execution time of the CI/CD pipeline for Our sequence=2
application was roughly 9 minutes, This means 7. https://www.ijraset.com/research-
developers have to wait approximately less
paper/ci-cd-pipeline-for-web-
than 10 minutes before receiving the results
from the pipeline, which is quite fast. Hence, applications
shorter the run time of a pipeline, the better it
becomes.

After a successful pipeline run, Our application

is deployed on Fly.io server. The hosted
application’s URL is given in the Fly.io
dashboard, which is used to access the
application.
7. Conclusion