Practical No 2

Aim : study practical on installation of java tomcat server

Introduction :

Apache Tomcat is an open-source web server and servlet container for Java code. Tomcat
executes programs written in the Java programming language, and it implements many Java
EE specifications, including Jakarta Servlet, Jakarta Server Pages, and others.

will learn to install the Apache Tomcat server on Windows.

Prerequisites:

 Java JRE installed and configured

 Administrator privileges
How to Install Tomcat on Windows

In this section, we will cover two ways of installing the Tomcat web server:

 Via Windows Service Installer.

 From a zip archive.

Follow the steps below to download and install Tomcat.

Step 1: Download Tomcat for Windows

To download the Tomcat installation file, follow the steps below:

1. Browse to the official Apache Tomcat website. Locate the Download section and click

the latest Tomcat version available. At the time of writing this article, the latest Tomcat version
was version 10.

2. On the Download page, scroll down and locate the Binary Distributions area.

In the Core list, depending on the installation type you prefer, click the download link for
the Windows ServiceInstaller 

or the 32bit/64bit
Windows zip file.

Step 2: Install Tomcat

Install Tomcat via the Windows Service Installer for an automated and wizard-guided

experience. The service installer installs the Tomcat service and runs it automatically when the
system boots.

For a portable experience, install Tomcat using the zip file and avoid installing the service.
Easily uninstall Tomcat when it is no longer needed by deleting the Tomcat directory, or move it
around when necessary.

Note: Take a look at our list of 13 best Java IDEs, which help write, debug, and test Java code.
Method 1: Install Tomcat Using the Windows Service Installer

Follow the steps below to install Tomcat using the Windows Service Installer.

1. Open the downloaded Windows Service Installer file to start the installation process.

2. In the Tomcat Setup welcome screen, click Next to proceed.

3. Read the License Agreement and if you agree to the terms, click I Agree to proceed to the
next step.

4. In the Tomcat component selection screen, choose Full in the dropdown menu to ensure the
wizard installs the Tomcat Host Manager and Servlet and JSP examples web applications.
Alternatively, keep the default Normal installation type and click Next.
5. The next step configures the Tomcat server. For instance, enter the Administrator login
credentials or choose a different connection port. When finished, click Next to proceed to the
next step.

6. The next step requires you to enter the full path to the JRE directory on your system. The
wizard auto-completes this if you have previously set up the Java environment variables.
Click Next to proceed to the next step.

7. Choose the Tomcat server install location or keep the default one and click Install.
8. Check the Run Apache Tomcat box to start the service after the installation finishes.
Optionally, check the Show Readme box to see the Readme file. To complete the installation,
click Finish.

9. A popup window appears that starts the Tomcat service. After the process completes, the
window closes automatically. The Apache Tomcat web server is now successfully installed .

Conclusion :
 Practical No 03
Aim : study practical on software development life cycle
Theory: What does software development life cycle (SDLC) mean?

The software development life cycle (SDLC) is the process of planning, writing, and modifying
software. It encompasses a set of procedures, methods, and techniques used in software
development. Developers use the approach as they design and write modern software for
computers, cloud deployment, mobile phones, video games, and more.

In IT, the term "life cycle" was first used in the 1950s and 1960s to describe the stages involved in
developing a new computer system, but it is now commonly used to refer to all stages in the
production of any piece of software.

Understanding the different SDLC stages and best practices

The process of the software development life cycle encompasses all aspects of the software-
making process. It begins with scoping the requirements you need for your program and ends with
you delivering it and managing maintenance protocols. Each stage in the SDLC has its own set of
activities that need to be performed by the team members involved in the development project. The
cycle can vary from company to company and from project to project, but it generally includes
these stages:

Software development process approaches

You can choose from many software development approach models available in the market. Each
of them has its advantages and disadvantages. Each is suited to different types of projects, too.
Some of the approaches you might like to learn about are listed below:

Agile model

The Agile software development process aims to deliver high-quality software early, often, and at
a low cost. The Agile model offers more flexibility than the Waterfall model, but it is not always
suitable for large-scale projects with complex requirements because it lacks initial documentation.

Iterative model

The Iterative model is an approach to software development that organizes the development
process into small cycles instead of a strictly linear progression. This allows developers to make
changes incrementally and frequently so they learn from mistak before they become expensive

V-shaped model

Also called the Verification and Validation model, the V-Shaped model allows for simultaneous
development and testing. Like Waterfall, this model follows a linear progression, but you only
move on to the next stage once the team finishes the previous one, which can extend the amount of
time it takes to complete the project.

Spiral model

The Spiral model combines elements of other models, namely Waterfall and Iterative. Developers
work in shorter cycles, and the work within the cycles follows a linear progression. After each
cycle (iteration), the software gets better and better through a gradual progression. 

Waterfall Model - Design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process ofsoftware development is
divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts as
the input for the next phase sequentially.
The following illustration is a representation of the different phases of the Waterfall Model.

The sequential
phases in Waterfall
model are −
 Requ
irem
ent
 Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement
specification document.
 System Design − The requirement specifications from first phase are studied in
this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture.
 Implementation − With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next phase.
Each unit is developed and tested for its functionality, which is referred to as Unit
Testing.
 Integration and Testing − All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
 Deployment of system − Once the functional and non-functional testing is done;
the product is deployed in the customer environment or released into the market.
 Maintenance − There are some issues which come up in the client environment.
To fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the
customer environment.

Waterfall Model - Application

 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.

Waterfall Model - Advantages

Some of the major advantages of the Waterfall Model are as follows −
 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

Waterfall Model - Disadvantages

The major disadvantages of the Waterfall Model are as follows −
 No working software is produced until late during the life cycle.
  High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.

Conclusion: Thus we have studies practical on software development life cycle.

Practical no 4
Aim :- Study practical on DevOps life cycle & stages
DevOps is an approach to software development that emphasizes collaboration and
communication between software developers, IT professionals, and business stakeholders. It
aims to reduce the time, cost, and risk of software development while improving the quality of
the final products. 
DevOps is not just a technical concept. It's also a way of thinking about software development
and operations holistically. The DevOps life cycle is designed to cover all aspects of
application development and deployment, including change management , testing, monitoring,
and other quality assurance processes. This article will look at some of the phases in the
development lifecycle. 
It is a relatively new concept in IT departments. Still, it has been gaining popularity over the
past few years because it helps companies reduce costs, improve efficiency and improve
customer service by reducing downtime caused by errors. 
What is DevOps?
DevOps is a software development process that emphasizes the time-saving benefits of
continuous integration, deployment, and measurement. It's a cultural and professional
movement that seeks to optimize the flow of work between software developers and IT
operations to create high-quality applications faster. The DevOps lifecycle phases are in order
from left to right, with each phase building upon the last. 
DevOps is a set of principles that enable organizations to automate services, push features out
quickly to customers and resolve issues faster than ever before. 
It is about automating the process of building, testing, deploying, and maintaining
applications to reduce time-to-market for new features and functionality. DevOps also aims to
increase application reliability by making it easier for developers to build features quickly
without breaking existing functionality. 
DevOps has become a hot topic in recent years because it's an approach that can help
companies deliver software faster without sacrificing quality. It allows organizations to
develop, test and deploy applications more quickly while providing better service to
customers. To achieve a good job, students can take DevOps training courses online.  
What is DevOps Lifecycle? 
DevOps Lifecycle is a methodology software development teams use to bring products to
market more quickly and efficiently. It's a way of managing the entire software lifecycle from
development through release, focusing on collaboration between developers and IT operations
professionals. Constant software creation, development, verification, release, and management
are part of the DevOps lifecycle.  
The DevOps strategy supports innovative thinking, speed, and adaptability to produce, verify,
utilize, and develop software applications. To innovate goods, services, and operations,
encourages a spirit of innovation, review, and continuous improvement. To adopt DevOps,
though, a thorough grasp of the various stages of the DevSecOps lifecycle is required.  
Engineers should be completely informed of all steps of the DevOps lifecycle to produce
quick results. The complete development approach can be time-consuming and difficult when
they're not. Every element of the DevOps lifecycle is broken down and analyzed in detail
here. Let's take a quick look at how the DevOps lifecycle functions at each step. 
1. Plan - Professionals determine the commercial need and gather end-user opinions
throughout this level. In this step, they design a project plan to optimize business impact
and produce the intended result.
2. Code - During this point, the code is being developed. To simplify the design process, the
developer team employ lifecycle DevOps tools and extensions like Git that assist them in
preventing safety problems and bad coding standards.
3. Build - After programmers have completed their task, they use tools such as Maven and
Gradle to submit the code to the common code source. 
4. Test - To assure software integrity, the product is first delivered to the test platform to
execute various sorts of screening such as user acceptability testing, safety testing,
integration checking, speed testing, and so on, utilizing tools such as JUnit, Selenium,
etc. 
5. Release - At this point, the build is prepared to be deployed in the operational
environment. The DevOps department prepares updates or sends several versions to
production when the build satisfies all checks based on the organizational demands.
6. Deploy - At this point, Infrastructure-as-Code assists in creating the operational
infrastructure and subsequently publishes the build using various DevOps lifecycle tools.
7. Operate - This version is now convenient for users to utilize. With tools including Chef,
the management department take care of server configuration and deployment at this
point. 
8. Monitor - The DevOps workflow is observed at this level depending on data gathered
from consumer behavior, application efficiency, and other sources. The ability to observe
the complete surroundings aids teams in identifying bottlenecks affecting the production
and operations teams' performance. 

Phases of DevOps Lifecycle

DevOps is a methodology that aims to optimize the process of software development and
operation. It is an approach that helps organizations produce software products and services
faster while meeting customer expectations.  
Everything in DevOps is ongoing, from strategy to maintenance, as we mentioned previously.
Now, let's split out the entire lifespan into seven stages, using stability as the focus. Every
DevOps life cycle phase can repeat several times across the program until it is completed. The
goal is to create an environment where code can move quickly through the pipeline while
maintaining high-quality levels. 

1. Continuous improvement 
The phase is critical in defining the overall strategy for the software development lifecycle. It
relies mostly on program design and programming. Program needs are obtained and addressed
with partners at this stage. Furthermore, for continual software design, the item backlog is
managed to depend on customer response and is divided down into shorter versions and
goals. 
Once the team has agreed on the company requirements, the production team begins
programming for the desired criteria. It's a continual procedure in which programmers must
code the program's requirements anytime shift or if there are any areas for improvement.  
The production group needs certain DevOps lifecycle tools for programming management.
However, there are no tools for planning. Version management tools include Git, TFS,
Confluence, and Subversion. In addition, several businesses choose agile cooperation methods
such as Scrum, Lean, and Kanban. Amongst all these tools, GIT and Jira are the most widely
utilized for complicated tasks and excellent team interaction during development.  
2. Continuous integration 
The most important phases of DevOps lifecycle are ongoing integration. Upgraded
programming and add-on functionality and additions are created and merged into the current
code during this phase. Moreover, throughout this stage, errors in the program are recognized
and detected at every stage via the testing phase, and the source code is updated
correspondingly. The stage transforms integration into a continual process in which code is
evaluated after each commit. In addition, the necessary tests are planned during this period.  
Jenkin, GitLab CI, and CircleCI are some of the DevOps tools used to improve the program
process more efficiently. Jenkin, for instance, is a popular open-source application for
automating builds and testing. But on the other side, CircleCI and Buddy are business
products. So, whichever continuous integration solutions you choose, make sure they are
compatible with your company's and project's needs. 
3. Ongoing Testing 
Certain organizations complete the continual monitoring phase before the connection, whereas
others do so later. Quality testers use Docker instances to test the software for faults and
issues in this step. In the event of a bug or error, the program is returned to the integration
phase to be fixed. Automation screening also reduces the time and energy required to produce
high-quality findings. During this level, organizations employ tools like Selenium.
Furthermore, test automation improves the test assessment report and lowers the expense of
delivering and maintaining the testing environment. 
JUnit, Selenium, TestNG, and TestSigma are some of the DevOps tools that were utilized for
continual monitoring. Selenium is perhaps the most widely used open-source automated
testing software, with compatibility for various platforms and devices. But on the other side,
TestSigma is a comprehensive AI-driven testing automation system that uses artificial
intelligence to reduce the technical intricacy of test automation. 
4. Continuous deployment 
The completed program is released to operational servers in this stage, which is of the greatest
importance and involved in the life cycle of DevOps. Configuration control is included in
continual deployment to ensure that machines release programming accurately and smoothly.  
The production groups distribute the code to computers and plan server upgrades, ensuring
that the settings remain constant across the production phase. Containerization solutions also
aid distribution by ensuring uniformity between development, testing, operational, and staging
systems. In addition, this method enabled the generation of new functionalities constantly.  
The setup administration tools Ansible and Chef are utilized to ensure the deployment
workflow is seamless and constant across the process of production. 
5. Feedback regularly 
To study and enhance the program code, constant feedback is created. User behavior is
analyzed on each distribution during this phase to enhance upcoming updates and
deployments. Companies can collect advice in either a controlled or uncontrolled manner.
Polls and quizzes are used to obtain feedback on the structural approach. Input is collected in
an uncontrolled manner via social media sites. Ultimately, this phase is critical in enabling
continual delivery so that a better edition of the program can be introduced.  
Pendo is a business monitoring platform that collects and analyses consumer feedback. An
additional tool, Qentelli's TED, follows the complete DevOps workflow and collects valuable
intelligence for faults and flaws. 
6. Continuous Monitoring  
The application's functioning and attributes are regularly checked throughout this stage to
identify network faults such as low RAM, a non-reachable host, etc. The procedure assists the
IT staff in promptly identifying app execution problems and the underlying causes. If IT
teams discover a serious problem, the app is re-run via the DevOps lifecycle to identify a fix.
At this stage, though, safety vulnerabilities can be recognized and corrected immediately.  
7. Operational continuity 
The DevOps lifecycle's final step is critical for decreasing scheduled downtime, like
scheduled service. To perform the modifications, programmers usually have to take the
system down, which raises downtime and may result in a major loss for the organization. In
the end, continuous operation simplifies the procedure of starting and updating the
application. In addition, this eliminates interruption by utilizing unit management solutions
such as Kubernetes and Docker. 
Such container management solutions make the process of developing, testing, and deploying
an app across various environments much easier. The main goal of this stage is to increase the
app's uptime so that services can continue uninterrupted. Designers save effort by doing
continuous processes, which can be leveraged to reduce the app's time-to-market.  
Conclusion

Practical No. 5
Study practical on DevOps Tools (Docker, Jenkins, Git, Jira, copado)
The above image shows the various sub-stages of DevOps and the tools used in each of them.
Each of the tools in DevOps is bound to a particular phase of DevOps. Now let us discuss the
phases of DevOps and the tool that is used in that phase. All of these phases together constitute
the DevOps lifecycle.

1.

.DevOps tools – JIRA:

Jira Software is part of a suite of products designed to assist

teams of all sizes in managing their workload. Jira was originally intended to be a bug and issue
tracker. Jira, on the other hand, has evolved into a powerful work management tool for all use
cases, ranging from requirements and test case management to agile software development.
Jira Software serves as the central hub for the coding, collaboration, and release stages for an
increasing number of teams today. Jira integrates with a variety of add-ons for test management,
allowing QA testing to be seamlessly integrated into the software development cycle.
Jira for agile teams
Jira Software includes scrum and kanban boards out of the box for teams that use agile
methodologies. Boards are task management hubs that map tasks to customizable workflows.
Boards ensure teamwork transparency and visibility into the status of each work item. Teams can
closely monitor their productivity over time with time-tracking capabilities and real-time
performance reports (burn-up/down charts, sprint reports, and velocity charts).
To know more about Jira, you can check out the following video:
Jira Tutorial 
The next phase after the Continuous Development Plan is the Continuous Development Code.
Phase 2:Continuous Development Code
Tools used: Git, SVN, CVS, Mercurial
4. DevOps tools – Git:

Git plays a crucial role when it comes to managing the code that the
collaborators contribute to the shared repository. This code is then pulled for performing
continuous integration to create a build and test it on the test server and eventually deploy it on
the production.
Git enables communication between the development and the operations team. When you are
working on a large project with a huge number of collaborators, it becomes very critical to have
communication between the collaborators while making changes in the project.
Commit messages in Git play a vital role in communicating among the team. The bits and pieces
that we all deploy lie in the Git. To be successful in DevOps, you need to have all of the
communication in Version Control.
DevOps tools – Jenkins:

Jenkins is an open-source automation tool that is written in Java with plugins built for
Continuous Integration purposes. Jenkins builds and tests your software continuously making it
easier for developers to integrate changes to the project, and making it easier for users to obtain a
fresh build. It also allows continuous delivery of your software by integrating with a large
number of testing and deployment technologies.

With Jenkins, organizations can fasten the software development process through automation.
Jenkins integrates development life-cycle processes such as build, document, test, package,
stage, deploy, static analysis and much more.
Jenkins achieves Continuous Integration with the use of plugins. Plugins allow the integration of
Various DevOps stages. If you want to integrate a particular tool, you just need to install the
plugins for that tool. There are numerous plugins in Jenkins such as Git, Maven 2 project,
Amazon EC2, HTML publisher, etc.
DevOps tools – Docker:

Docker is a platform that packages an application and all its dependencies together in the form
of containers. This containerization aspect of Docker assures you that the application can work in
any environment.
 
As you can see in the diagram, each and every application runs on separate containers and has its
own set of dependencies & libraries. This makes sure that each application is independent of
other applications, giving developers surety that they can build applications that will not interfere
with one another.
So a developer can build a container that can have different applications installed on it and give
it to the QA team. Then the QA team would only need to run the container to replicate the
developer’s environment.
COPADO

Copado Devops Tool is the first firm to offer the greatest deployment and release management
solution, which supports Salesforce users. It is the only DevOps solution for Salesforce that
enables for point-and-click deployment of changes from the development environment to
production and simple configuration. Copado, which is based on Salesforce, provides a unified
framework for managing development across clouds.

Architecture Of COPADO

A combination of technologies called Copado DevOps Platform enables you to design a

DevOps process that functions with various clouds like MuleSoft or Heroku. It comes with a lot
of default functionality and has certain requirements for the backend that all technology ought to
meet. The Copado pipelines can be used to orchestrate tests, automate manual operations, and
deploy to various clouds and platforms.

Copado requires OAuth protected web service authentication to connect to a salesforce.org, the
login is done on your browser (using your computer’s IP address) and then it passes the session
Id to the connecting service (Copado).
Copado Devops Tool is a managed package that is installed in a production org. All users who
will use  must have a Salesforce license that gives them access to managed package objects
(AppExchange App) and the Push Topics object. Any Copado user must have at least a Platform
Starter license from Salesforce.

Salesforce API: Salesforce’s latest API version, which is Copado Essentials’ default, is used for
deploying metadata from Salesforce to Salesforce. To keep current with the most recent
Salesforce release, the default API is frequently updated.

Git API: For committing the metadata from Salesforce Org to Git,Copado Essentials
automatically determines the API version of the metadata presently kept in the GIT repository
before retrieving it from the source Salesforce Org.

Copado API: With the help of a Copado API key,it allows actions to be scheduled securely and
validated in the Copado server.

Cloud VS On-premise: Cloud software is hosted on the vendor’s server and accessed using a
web browser, whereas on-premise software is locally installed on the PCs and servers of your
company. So, the customers will choose on Cloud or On-Premise based on different
requirements that will influence the choice of the deployment strategy.

BackEnd: Copado Devops Tool is built on salesforce and interacts with Heroku using Copado
API.CI/CD(Continuous Integration/ Continuous Delivery) best practices can help organizations
achieve greater levels of control over their technology stack, through iterative processes and
continuous testing.

HOW TO SETUP A COPADO PLAYGROUND

👉 Prerequisites

In order to work with playgrounds, you will need a Git repository and GitHub account.

👉 Steps to follow for creating playground

📌 Our Success community’s Copado Playgrounds tool enables you to instantly set up a full

Copado setup with all the necessary configurations, such as Git repositories, sandboxes, and
scratch orgs.

📌 Copado trial orgs and scratch orgs are valid for 30 days from the date they are created.

📌 For a step-by-step method on how to set up a playground following the wizard, take a look at
the article Copado Playground Setup Wizard. (use ctrl+click)

📌 After following the setup wizard, you will observe the setup contains Six salesforce orgs, a
Copado implementation, a connection to Git with all the necessary records and preset branches.
1) GIT Account.

2) Production Org.

3) Scratch Orgs: Six Salesforce orgs are created as a result of the setup: Copado (the trial org
where Copado is installed), Production org, Hotfix, UAT, DEV1 and DEV2.

📝 For Copado, this is a great way to create an independent training environment.

ADVANTAGES OF COPADO 

1. Salesforce Copado has a very interactive UI (User Interface) and is easy to understand.

2.  Copado is a Continuous Integration/ Continuous Delivery tool for deployment.

3.  It also has very good features like Back promotions, User Stories, Sprints, Worklogs, Conflict
Resolution, Data Uploading and Version Control.

4. Performing and managing Git repositories can be done within a few clicks in Copado.

5. Copado helps us to deploy quicker as well as smarter with fewer errors and no more repetitive
manual tasks.

6. Uses quality gates to build testing, compliance, and security into your development process.

7. We can track the deployments under user stories at which stage the deployment has reached.

COPADO LIMITATIONS

1. Back promotions are sometimes difficult and behave in a weird manner.

2. After the deployment to production, next changes in the pull request shows all the changes
from the previous release as well.

3. Cannot be used through mobile.

4.While deployment, the Query can be lost while editing, which can cause a lot of problems.

CONCLUSION
 Practical No. 6
Learn about DevOps Pipeline (CI /CD) using any tool
A CI/CD pipeline aims to mitigate the risks involved in releasing the software into production.
However, its efficiency relies heavily on test automation, so achieving success with DevOps
stands or falls with how well the development department works with automation and which
tools are at their disposal.
One of the main responsibilities of DevOps managers is to support the creation of a release
pipeline, which is the route a piece of code or feature must travel from a developer’s local
computer into production.
There are different best practices to apply in the building of the pipeline: Continuous Delivery,
Continuous Deployment, Continuous Integration, and more. Nevertheless, when creating the
ideal release pipeline, you should make sure that it will:

 Increase product quality

 Increase the agility of the product’s development
 Reduce the stress and last-minute panic associated with product releases

Standard Elements of a CI/CD Pipeline

A standard release pipeline consists of the main elements or environments listed below.
Depending on the software and compliance requirements, environments might be added or
removed from the pipeline, either permanently or by demand.

1. Local development environments; the individual developers’ personal computers

2. A Continuous Integration (CI) server, or development server
3. Test servers for functional UI testing of the product
4. A production environment
Related Reading: CI/CD and Continuous Testing: What, Why and How
A release pipeline ensures that no code slips into the production environment (4) without being
exposed by the so-called ‘gates’. A gate is a set of requirements that must be met for a build (a
piece of code) to pass to the next stage, or environment, of the pipeline. For example, a gate
could set the following requirements:

 The code should build without errors

 All unit tests must pass
 All functional UI tests must pass
In the following, all stages and gates of the CD release pipeline are color-coded to make it very
easy to identify and understand the flows and checks of the process:
Local development
This environment is the local PCs of the individual developer. This is where the code is produced
and added to the source control system. The piece of code can be a new feature or module to the
product, or it can be a fix or change to some existing code.
Related reading: How to Automate Functional UI Tests in a DevOps World
Development
This is where the code is built on a build server and deployed to a CI server.
Test environment gate
After development, the code is ‘checked in’ at the Purple Gate. To pass this gate, the following
requirements must be met:

 The code can build.

 The code must have passed all unit tests.
 The code must have passed a local verification by the individual developer.
The checks of the Purple Gate are very critical because the Development environment is
designed to imitate the Production environment. This means,  if the code works in Development,
it is likely to work in Production.
More requirements can be added to the Purple Gate. In any case, if any of the checks fail, the
check-in should be rolled back and the move to Test should be cancelled.
Test
This environment is for product tests of all kinds. It can contain multiple server setups to
accommodate for various test types: functional tests, performance tests, load tests, etc.
Preproduction gate
To pass this gate, the following requirements must be met:

 The code must have passed all automated functional UI tests (regression testing)
 The product must have passed a verification of its visual appearance
 The server log files must have been inspected after regression tests
 Performance data must have met an acceptable benchmark
Again, more requirements can be added to this gate. If any of the checks fail, the check-in should
be rolled back and the move to Production should be cancelled.
Production
This is where the final software is produced. There is no specific gate following this stage, but
there are still checks associated with this final step: Smoke testing is for identifying any bugs
before the end-user does. Obviously, this improves the end-user experience as the product is
better received.

Setting Up Your CI/CD Pipeline With Jenkins and GitHub

OPEN SOURCE AUTOMATION

CI/CD (Continuous Integration/Continuous Delivery) is a holistic DevOps process that focuses

on creating a compatible blend between the development cycle and the operations process. This
is done by automating workflows and rolling out automatic updates to improve ROI. The CI/CD
pipeline implementation is the backbone of the entire DevOps paradigm and facilitates the
process of introducing the product to the marketplace faster than ever before. 

In this article, we will be providing a comprehensive guide for creating and deploying your
CI/CD pipeline with Jenkins and GitHub. 
Table of Contents:
 What is Continuous Integration/Continuous Delivery?
 Creating Your CI/CD Pipeline With Jenkins: An Overview
 Why Use CI/CD with Jenkins?
 Configuring Automated CI/CD with Jenkins & GitHub – Step by Step

What is Continuous Integration/Continuous Delivery?

Continuous Integration, which was first proposed as a term by Gary Booch, integrates the source
code with the repository. This facilitates the developers to carry out the development process in a
quick and sophisticated manner.

CI is not entirely an essential prerequisite required for creating a stable software product.
However, it definitely serves an important role when developing software products or
components that require frequent changes. Furthermore, it also ensures that all the components
of an application are integrated properly. 

In the SDLC, CI mainly covers the Source and Build phases. A CI pipeline typically involves
these steps:      
 Detect changes in the code 
 Analyze the quality of the source code
 Build
 Execute all unit tests
 Execute all integration tests
 Generate deployable artifacts
 Report status

If any of the above steps fail, the integration stops immediately, and the team is notified about
the result. 

Continuous Delivery, on the other hand, is a set of software development practices that ensures
the deployment of code to production while performing efficient testing in the process. Precisely
speaking, CD starts where CI ends. Continuous Delivery is responsible for pushing the code to
the testing environment where different tests such as system testing, unit testing, and integration
testing are performed.

A typical CI/CD pipeline works in 4 phases that are listed below:       

 Phase 1: Commit - This is the actual phase where developers commit changes to the code.
 Phase 2: Build – In this phase, the source code is integrated into the build from the
repository. 
 Phase 3: Test Automation - This step is an integral part of any CI/CD pipeline. The
source code previously integrated into the build is subjected to a systematic cycle of
testing.  
 Phase 4: Deploy - The tested version is finally sent for deployment in this phase.

While Continuous Integration covers the commit and build stages, Continuous Delivery, on the
other hand, ensures the process automation as well as testing till the deployment phase.

How Do You Create Your CI/CD Pipeline With Jenkins?

Jenkins is one of the most widely used open-source CI/CD DevOps tools. It enables developers
to implement CI/CD pipelines within the development environment in a comprehensive manner.
Jenkins is written in Java and supports various version control tools including Git and Maven.

Its popularity is based on the fact that Jenkins is an open source repository of rich integrations
and plugins that are well documented and extensible, based on an extended community of
developers who have developed hundreds of plugins to accomplish almost any task. 

Jenkins runs on the server and requires constant maintenance and updates. The availability of
Jenkins as a cross-platform tool for Windows, Linux, and various operating systems makes it
stand out among other DevOps tools. Moreover, it can easily be configured using CLI or GUI.

Why Use CI/CD with Jenkins?

The list of benefits of using CI/CD with Jenkins is a detailed one. The three main ones are:
1. Costs

While implementing CI/CD with Jenkins, developers and the DevOps team don’t need to worry
about the additional procurement costs involved in setting up code pipelines, as Jenkins is free
and open source. This simply means that they no longer have to get spending approval from
management. As far as cloud and infrastructure costs are concerned, these costs can be optimized
as well by efficiently utilizing the resources available and implementing the Infrastructure as
Code (IAC) approach using Jenkins. 
2. Plugins

Another remarkable feature that highlights Jenkins’ value is the extended variety of Jenkins
pluginsavailable in Jenkins. With this diverse range, users of different cloud providers can
feasibly utilize CI processes via Jenkins in a significantly lesser time. Moreover, Jenkins also
provides a default list of common tools and services that can be implemented either on-premises
or on the cloud. Top Jenkins plugins include Dashboard View, Test Analysis Plugins, and Build
Pipeline Plugins.
3. Open Source

Jenkins, with its long history of CI/CD practices, was introduced in the year 2011. Its availability
on the open-source platform provides it an edge over other tools used for the same purpose.
Numerous developers, community contributors, and users actively participate in the open-source
platform to maintain Jenkin’s functionality as an open-source product.

Configuring Automated CI/CD with Jenkins & GitHub — Step by Step

Configuring automated CI/CD with Jenkins and GitHub is a simple and straightforward process
and can help automate the entire workflow. Integrating Jenkins with GitHub enables the
developers to pull the source code from any Git repository in a hassle-free manner.

Furthermore, GitHub also supports bi-directional integration, which will automatically initiate a
trigger to Jenkins every time there is a change in the GitHub repository.

The step-by-step procedure for configuring Jenkins with GitHub is elaborated below. 
📕 Related Resource: Learn more about Selenium + GitHub: A Step-by-Step Testing Guide

Installation

To configure automated CI/CD with Jenkins, the first and the most obvious step is to install
Jenkins. Jenkins setup, with complete instructions on how to install it, is availablehere.

To implement it on the server or a remote computer, simply replace localhost with the IP
Address of the target machine. Jenkins provides long-term support and weekly releases for
several Operating Systems. For the scope of this blog, we will be setting up Jenkins on a local
Ubuntu machine. To use the Ubuntu repository, execute the command in the terminal:

wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add -

 After that, add the Jenkins repository by executing this command:

sudo sh -c 'echo deb https://pkg.jenkins.io/debian-stable binary/ >

/etc/apt/sources.list.d/jenkins.list'

Make sure to update the packages using the sudo command as shown here:

sudo apt-get update

 Finally, install Jenkins:

sudo apt-get install jenkins

 Make sure to install Java Runtime Environment (JRE) explicitly after installing Jenkins.
However, if you get a “package error”, you must check for the Java version by executing the
command given below:

java -version.

 If the package does not exist, then you will have to install it. For this, you will first search for
the available packages:

sudo apt search openjdk

 Next, pick the available version and install it.

sudo apt install openjdk-11-jdk

 
After the successful installation, check the Java version.

java -version

 You will get a result like this:

The second step is to run Jenkins. However, you can also run Jenkins on several platforms
including Docker, Kubernetes, and Windows. Notice here that you will need to install Docker or
Kubernetes if you are planning to run Jenkins on these platforms. In this tutorial, we will run
Jenkins on localhost on Linux.
Starting the Server

After the successful installation of Jenkins, you will start it on localhost. For this step, you
should start Jenkins first using the systemctl command on the command line. 

sudo systemctl start jenkins

sudo systemctl enable jenkins

 To check the status of Jenkins service, use the status command as shown below:

sudo systemctl status jenkins

The output will be rendered as “Active” if everything has been configured successfully.
Post-Installation Setup

When you configure Jenkins for the first time, it is crucial to unlock it using an automatic
password. For this setup, typehttp://localhost:8080 in the browser, and wait for the Getting
Started page to appear. The automatically-generated password is stored
in /var/jenkins_home/secrets/initialAdminPassword file. The file can be also accessed via the
command-line interface using the cat command with the filename. 

Copy/paste the password in the Administrator Password field and click Continue. The dialogue

box will close and that’s it! You have successfully set up the user. After that, you will get
the Customize Jenkins page. From this page, you can install any number of plugins you require.
You can install suggested plugins as they are selected by default and you can also choose any
additional plugins. Make sure to install the Git Plugin.
Configure GitHub

Now that you have successfully configured the user, it is time to configure the GitHub repository
using Webhooks. Additionally, you can also perform this step after adding the Jenkins project. 

Head over to the existing GitHub repository, and click the Settings tab.

After that, click on the Webhooks option from the navigation panel on the left side of the screen.

Now, click on the Add webhook button on the right side of the screen.

You will see a new form appear in the webhooks section. In the Payload URL field, type in the
Jenkins endpoint. In our case, it is localhost: 8080. Since the localhost is behind a Firewall, make
sure to make it visible to your public GitHub repository by using a webhook proxy service. In
our case, we have used SocketXP. If you have a specific URL, make sure that it is publicly
available. At the end of the URL, type /github-webhook/.

 
Choose application/json as Content-Type from the drop-down menu, select Just the push event,
and click the Add webhook button.

For now, this repository will only call Jenkins on the push event. For other events, you will have
to select the Let me select individual events option instead of Just the push event.

That’s all! You are done with the configurations on the GitHub side.
Jenkins Project and Adding GitHub

After successfully logging in, the Jenkins dashboard will appear on the screen. Here, all the
CI/CD pipelines and their summary are visible to a user. On the Jenkins dashboard, click on
“New Item”. After that, enter the name of your project, choose “Freestyle Project” from the list,
and hit the enter key.
The next step is to configure the project on the Jenkins dashboard. In the General tab, choose
your GitHub Project, and enter the GitHub Repository URL. Now, head over to the Source Code
Management tab to add the credentials.

For this step, press the Add button and type Username and Password. Press Add again to close
the dialogue box. Be sure to select the main branch in the Branch Specifier.

Now, head over to the Build Triggers section to set the triggers for Jenkins. The purpose of
triggers is to necessarily indicate to Jenkins when to build the project. Select Poll SCM section,
which queues VCS on the predefined schedule. The predefined schedule is ***** which
represents every minute. That means, our Jenkins job will check for the change in our repository
every single minute. 
Build Jenkins Project

Now go back to the repository that you configured, and make a sample file, or edit any existing
file and commit the changes. 

After that, head over to Jenkins and click on the “Build Now” button from the navigation bar.
 
The build number will display a green tick if the build is successful, and the app will be
published on the localhost:8080. You can also use the output console to debug the application.

As you can see, Jenkins pulled the changes from the GitHub repository and reflected them in its
console.
 

Finally, you have successfully integrated Jenkins with the GitHub repository. With each push,
commit, or update, GitHub will trigger the Jenkins job, which in turn will execute the necessary
steps to deploy the changes.

DevOps is an ever-evolving ecosystem in the development industry, and the CI/CD tools in this
domain are highly critical. CI/CD practices effectively handle the misalignment between
developers and the operational team. There are several tools built for this purpose in the
marketplace today, but Jenkins holds an established position in the industry as well as a
promising future ahead of it because of its open-source benefits and a wide range of plugins.
Furthermore, it integrates well with GitHub allowing productivity and flexibility in the DevOps
cycle.
this detailed guide will assist you in setting up your first Jenkins CI/CD build with GitHub
repository successfully. Stay tuned for more tutorials and articles on the latest trends in the
software and IT industry!