Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
56 views110 pages

Module 2

Uploaded by

shezrisa
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)
56 views110 pages

Module 2

Uploaded by

shezrisa
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/ 110

Source Code Management

Release 2.0

Copyright @ Xebia 2022


Module Objective:
• Brief need and necessity of DevOps ?
• Define DevOps in details with industry based examples
• How IT was surviving without DevOps
• Major Challenges get overruled by introducing DevOps
• How DevOps is getting fitted into the source code management/How DevOps one of the major component of
DevOps?
• How DevOps is revolutionising the things in IT ?
• Different Industries can adapt DevOps intentions for their purpose?
• Amendment in current scope can be made :
• To show the sequence of steps required to achieve DevOps.
• Advantages of steps
• Turn around time of each steps
• Identify the basics of continuous practices
• What ,Why and How : Continuous Integration.

Copyright @ Xebia 2022


Continue:
• Best Practices of Continuous Integration?
• Advantages of Continuous Integration?
• What ,Why and How :
• Continuous Delivery.
• Identify the need of Continuous Delivery
• Advantages of Continuous Delivery
• Work flow of Continuous Delivery
• What ,Why and How :
• Continuous Delivery.
• Identify the need of Continuous Deployment
• Need of Continuous Deployment
• Advantages of Continuous Deployment
• Work flow of Continuous Deployment

Copyright @ Xebia 2022


DevOps:
• DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver
applications and services at high velocity: evolving and improving products at a faster pace than organizations using
traditional software development and infrastructure management processes.

• Working Of DevOps: A DevOps team includes developers and IT operations working collaboratively throughout the product
lifecycle, in order to increase the speed and quality of software deployment. It’s a new way of working, a cultural shift, that
has significant implications for teams and the organizations they work for.
• Under a DevOps model, development and operations teams are no longer “siloed.” Sometimes, these two teams merge into
a single team where the engineers work across the entire application lifecycle — from development and test to deployment
and operations — and have a range of multidisciplinary skills.
• DevOps teams use tools to automate and accelerate processes, which helps to increase reliability. A DevOps toolchain helps
teams tackle important DevOps fundamentals including continuous integration, continuous delivery, automation, and
collaboration.
• DevOps values are sometimes applied to teams other than development. When security teams adopt a DevOps approach,
security is an active and integrated part of the development process

Copyright @ Xebia 2022


Why DevOps? How Does DevOps Work?
• DevOps, essentially as an approach or a work culture, is implemented by the right amalgamation of collaboration,
automation, integration, continuous delivery, testing and supervising.
• Reason behind introducing DevOps.
• Prior to the introduction of DevOps, the traditional or classic waterfall model was followed for software delivery.
• This process model involved a sequential flow of a defined set of phases where the output of one phase becomes the input of the
next phase.
• Therefore, all the phases are dependent on each other, and the completion of one phase marks the beginning of the other.
• Despite the simplicity of the Software Delivery Life Cycle (SDLC) model, it has been found to have several defects.
• It has been observed that in the ever-changing contemporary world, a business is met with multifaceted problems which require
quick fixes.
• Changes in the product like adding new features, fixing bugs, etc require it to go through at least 4-5 different silos in traditional
SDLC, causing delays and increasing cost.
• the conflict and friction that develops among different teams to provide a stable software solution while at the same time respond
instantly to dynamic needs leads to “a horrible downward spiral that leads to horrendous outcomes.” He further explains that the
delay in production in traditional model leads to “hopelessness and despair” in the organization.
• In its essence, DevOps is a more inclusive approach to the software development process, where the development and operations
teams work collaboratively on the project. Resultantly, the software development life cycle is shortened with the help of faster
feedback loops for more frequent delivery of updates and features.

Copyright @ Xebia 2022


Challenges in Traditional IT

Copyright @ Xebia 2022


Challenges in Traditional IT
Siloed structures and management bottlenecks
• The classical SDLC method segregated the software developers, test engineers and maintenance team to three different groups
where they performed the operational functions systematically one after another, without any empathetic communication. The
developers who were in charge of coding are unable to cooperate with the test engineers or operation team that was assigned to
maintain the stability of the software. The lack of communication, along with an isolated structure of departments not only
resulted in uncoordinated and time-consuming approach but also led to faulty output.
Insufficient tests and high probability of errors
• In this process, the tests are conducted individually in unit forms. For higher functionality and proper detection of flaws, these
tests are not enough to create a standard quality output. The test experts fail to maintain a continuation of testing in each stage of
development due to fixed silos of departments. Owing to these loopholes, the teams end up with several issues like post-release
bugs which could have been fixed if there was continuous testing at each stage before releasing the end product.
Late feedback and lack of transparency
• Due to fixed isolated work stages, the customer is intimated with the product at a very later stage. This brings in major gaps in the
expected and the delivered product, which leads to rework. Also, the lack of integration and collaboration make the employees
work overtime, and they fail to respond to the complaints of the users in the stipulated time.
Late fixes and updates
• With the absence of any direct relationship or transparency between the testing engineers and developers, fixing a bug and
making new changes and implementing them can take weeks or even months. One fails to make progress in the market if they
repeatedly fail to deliver the project on time.

Copyright @ Xebia 2022


Lifecycle Of DevOps

Copyright @ Xebia 2022


Lifecycle Of DevOps
Plan:DevOps teams should adopt agile practices to improve speed and quality. Agile is an iterative
approach to project management and software development that helps teams break work into smaller
pieces to deliver incremental value.

Build :Git is a free and open source version control system. It offers excellent support for branching,
merging, and rewriting repository history, which has led to many innovative and powerful workflows and
tools for the development build process.

Continuous integration and delivery:CI/CD allows teams to release quality products frequently and
predictably, from source code repository to production with automated workflows. Teams can merge
code changes frequently, deploy feature flags, and incorporate end-to-end testing.

Monitor and alert:Quickly identify and resolve issues that impact product uptime, speed, and
functionality. Automatically notify your team of changes, high-risk actions, or failures, so you can keep
services on.

Copyright @ Xebia 2022


Continue:
Operate Manage the end-to-end delivery of IT services to customers. This includes the practices
involved in design, implementation, configuration, deployment, and maintenance of all IT
infrastructure that supports an organization’s services.

Continuous feedback DevOps teams should evaluate each release and generate reports to improve
future releases. By gathering continuous feedback, teams can improve their processes and incorporate
customer feedback to improve the next release.

Copyright @ Xebia 2022


Advantages of DevOps :
How can a business organization move ahead in the competitive market and become more efficient in delivering the best
features to the end-users in the set time? Well, here are some of the prime benefits a company can enjoy after adopting the
DevOps way of working:
1. Ensure faster deployment
• Faster and more frequent delivery of updates and features will not only satisfy the customers but will also help your
company take a firm stand in a competitive market.
2. Stabilize work environment
• Do you know that the tension involved in the release of new features and fixes or updates can topple the stability of your
workspace and decreases the overall productivity? Improve your work environment with a steady and well-balanced
approach of operation with DevOps practice.
3. Significant improvement in product quality
• Collaboration between development and operation teams and frequent capturing of user feedback leads to a significant
improvement in the quality of the product.

Copyright @ Xebia 2022


Advantages of DevOps :
4. Automation in repetitive tasks leaves more room for innovation
• DevOps has greater benefits when compared to the traditional model as it helps in
detecting and correcting problems quickly and efficiently. As the flaws are repeatedly
tested through automation, the team gets more time in framing new ideas.
5. Promotes agility in your business
• It’s no secret that making your business agile can help you to stay ahead in the market.
Thanks to DevOps, it is now possible to obtain the scalability required to transform
the business.
6. Continuous delivery of software
• In DevOps methodology, all of the departments are responsible for maintaining
stability and offering new features. Therefore, the speed of software delivery is fast
and undisturbed, unlike the traditional method.

Copyright @ Xebia 2022


Advantages of DevOps :
7. Fast and reliable problem-solving techniques
• Ensuring quick and stable solution to technical errors in software management is one of the primary benefits of
DevOps.
8. Transparency leads to high productivity
• With the elimination of silo(ing) and promotion of collaboration, this process allows for easy communication
among the team members, making them more focused in their specialized field. Therefore, incorporating DevOps
practices has also led to an upsurge in productivity and efficiency among the employees of a company.
9. Minimal cost of production
• With proper collaboration, DevOps helps in cutting down the management and production costs of your
departments, as both maintenance and new updates are brought under a broader single umbrella.

Copyright @ Xebia 2022


Advantages of DevOps :

Copyright @ Xebia 2022


How DevOps comes with Different Benefits of DevOps for
Different Stakeholders:

• However, in the greater picture, different stakeholders have different business goals. And different business goals require
them to look at the benefits of DevOps differently. The standpoint of CIO is different from that of CEO, whose perspective
is different from that of an IT Manager or any other stakeholder – this dissimilarity in looking at the benefits of DevOps
was researched by David Linwood, a renowned IT Director who referred to the different perspectives as ‘lenses’.
For IT managers, it is important that the procedural and technological metrics are improved. As a result, output
performance metrics govern the advantages of DevOps from an IT manager’s point of view. The benefits are:
• Lower volume of defects
• Lower cost of a release
• Improved software performance
• Lower cost of investment
• Frequent release of new features, fixes and updates
• Improved MTTR (Mean Time To Recovery)

Copyright @ Xebia 2022


The CTO / CIO of the organization focuses more on the strategic goals involving people-centric metrics for the successful
implementation of DevOps. From the lens of a CIO, DevOps offers the following benefits:
• Individual improvement and cross-skilling
• Greater flexibility and adaptability
• Freedom to brainstorm and experiment
• Increased engagement by team members
• Cooperative and happier teams
• Appreciation from senior managerial teams
• Better process management
• Reliable and faster fixes, along with enhanced operational support.

Copyright @ Xebia 2022


• For a CEO, the benefits of DevOps are governed by business-based outcome of decreased production costs and
increased revenue. Listed below are the advantages of DevOps as per the corporate vision of a CEO:
• Improved product quality
• Satisfied customers
• Lower cost of production
• Increased revenue
• Reliable and stable IT infrastructure
• Lower downtime
• Improvement in productivity of the organization

Copyright @ Xebia 2022


Achieve DevOps
More and more companies are switching to DevOps to overcome the challenges faced in traditional SDLC model.
As DevOps has become a common transformative journey in the IT world, many software companies still struggle
to take the onset steps to the DevOps takeoff. It is important to have a roadmap in place before the transformation
to DevOps begins. Elucidated below are the steps to take before you embark on the DevOps upgradation:
1. Evaluate the need to switch to a different model
• Shifting from a classic model to a modern one is not easy. Before incorporating DevOps in your business, make
an assessment on the necessity to switch to a different process. Changing to a different practice solely because
of its popularity in the market is unlikely to yield desired results. For some organizations, adopting DevOps has
yielded good results while for some, switching to the new strategy did out turn out to be as successful. Your
business goal should be the dominant factor when it comes to choosing the right model to run the organization.
2. Confirm if everyone is on the same page
• Before you decide to transform your working environment, make sure everyone is willing to embrace the new
model and say goodbye to the former technological and cultural setup. Start by educating teams on what is
DevOps and why the organization has chosen to implement DevOps culture. Since DevOps is essentially about
breaking down silos and working collaboratively, developing a unified perspective among teams with differing
priorities and viewpoints is the most crucial step of the journey.

Copyright @ Xebia 2022


Achieve DevOps
3. Measure each step
• To gauge the success of DevOps, it is imperative to measure the current metrics of different stages of the software development
life cycle (for e.g., time taken to develop, test etc.) The metrics should be measured again after the implementation of DevOps
practices. Comparing and analysing the before and after scenarios help in effective assessment at each point of the journey.
4. Encourage collaboration
• Collaboration among all the sectors is the key to make DevOps model successful. Break down the organizational silos and pave a
path for communication and easy access to information. Pay equal attention to the differences among different teams as well as to
the overlapping ideas of the teams. A healthy environment and cooperation among team members go a long way in ensuring
DevOps success.
5. Plan the budget accordingly
• Another significant factor that needs to be taken into consideration before the transition is the planning of the budget. It is
important to create a rough estimate of the expenses the organisation will bear while transitioning and integrating as unplanned
methodology leads to wastage of money and reduction in productivity.
6. Start small
• Make small changes in your organization and scale up gradually over time instead of turning all the departments into the DevOps
model at once. It is always safe to get started by incorporating the culture of collaboration to a small team and observe their
achievements or improvement and make subsequent decisions on implementing the model on another team and therefore,
adoption of DevOps best practices on a larger scale.

Copyright @ Xebia 2022


Copyright @ Xebia 2022
7. Do not attempt to automate everything at once
• Understand that the transition from the traditional approach to DevOps does not happen overnight, and so rushing to
make changes will not be a viable option. Do not get fooled by the term automation and expect the infrastructure to be
managed by code at once. Before putting the responsibility of automation entirely on the IT team, it’s always safe to hire a
professional who is experienced in the field of automation and can guide the team to perfection.
8. Choose tools that go hand-in-hand with the IT environment
• If you are considering implementing DevOps, make sure the tools of automation chosen are compatible with each other
and enhance the working environment. It is recommended that all tools be bought from the same seller as they are more
integrated with each other than different tools from different vendors. Tools should be bought widely to ensure smooth
operation and management of configuration.
9. Ensure continuous integration and delivery
• Establishing continuity in integration and delivery should be one of the primary objectives of an organization before
implementing DevOps without which the idea of smooth operation will go in vain. Continuous integration is a part of the
agile process where software is developed in small and regular phases with immediate detection and correction of flaws.

Copyright @ Xebia 2022


10. Evaluate the performance of an individual as well as the team
• The art of collaboration being a new concept, tracking the performance of the new team is necessary to check the progress.
Observe and make an assessment of an individual’s assigned role and actual execution of a task.
11. Draw your attention to enhancing security
• Strengthening the security is another fundamental step and negligence in this field can make the DevOps transformation
ineffective. As the traditional model focused more on the development of software and unit testing, the companies failed to invest
resources and time in strengthening security.
• With DevOps, a number of business organizations have implemented an integrated security system. Along with the developers and
operational personnel, it is recommended to hire skilled security teams for strict monitoring of the configuration, infrastructure
and integrity.
12. Emphasize customer/end-user satisfaction
• One of the prime drawbacks of the traditional model is that it takes days and months to receive feedback and make new changes
and updates to the software. Additionally, in the traditional SDLC, the software is not made to go through tests at each small phase
of development resulting in an unsatisfactory end product.
• The delay in communication between the department and the customers makes the latter lose faith in the product. In DevOps
practices, end-user satisfaction is a priority. Focus on the demand of the customers and make faster changes or improvements to
the software based on their feedback.
• Within the perimeters of the integrated system, the transparency among different sectors and the will to work unitedly keeps the
customers happy with the result and helps the business flourish.

Copyright @ Xebia 2022


What Makes DevOps a Success?

DevOps, as a service, prioritizes the satisfaction of the customers by providing quick delivery of features and updates. This
makes DevOps a more preferred method than the traditional model.
• The key factors that ensure a successful implementation and working of DevOps of a company are:
1. Continuous integrated operation
• It is the leading factor that involves gathering the changes of code and collectively making them go through systematic and
automated test phases. This process, unlike the traditional method, helps in detecting flaws, correcting them early and
ensuring the quality before releasing the product/feature.
2. Constant delivery
• All the new changes in code are delivered to the production phase where general testing takes place. After that, the
deployed output is further made to go through a standard testing process.
3. Consistent and constant communication among different teams
• This process involves breaking down single and segregated services and connecting them to work in unity as multiple yet
independent services.

Copyright @ Xebia 2022


What Makes DevOps a Success?
4. Less manual management of infrastructure
• Say goodbye to the flawed traditional infrastructure management method. The new process ensures proper management
and use of infrastructure through code. There are several DevOps tools that help in managing the updates efficiently.
5. Code for policy management
• As codification replaces the manual management of important configurations and infrastructure, tracking flaws and
reconfiguration has become easier and automated. Therefore, it saves time and increases efficiency.
6. Configuration Management
• The implementation of DevOps leads to the elimination of manual and toilsome management of host configuration. Both
the operational work and configuration will systemically get managed through code.
• Transforming to DevOps is no small undertaking. Changing the mentality of your teams from “I have done my job” to “the
product/feature is now ready to be deployed” is what DevOps is all about. It is crucial to plan out the transformation to
DevOps properly before implementing it.

Copyright @ Xebia 2022


Achieve DevOps/Implementation of DevOps

Copyright @ Xebia 2022


Achieve DevOps
• The DevOps Implementation Roadmap involves Six Steps:
Introduce DevOps Initiative
• The Organization is focusing here in introducing a DevOps initiative as a part of the organization’s IT activity and facilitating
requirements such as investment and human resources. Accordingly, changes are made to the development and
operations activities and the program manager designs a DevOps strategy and monitors its implementation.
Develop DevOps Strategy
• The best practices that enhance team collaboration and facilitate new ways of infrastructure provisioning, software
development and testing are crucial to DevOps strategy. Our program managers set a common goal and align teams in a
shared environment and we implement Infrastructure-as-Code (IaC) mechanism, automate testing, integration,
deployment and release processes.
Use Containerization
• We implement containerization to ensure software reliability while traversing between processes. Through
containerization, individual parts of the software run independently of the overall infrastructure and add to their abilities
to run on any environment without dependencies. Moreover, our container packaging helps Ops teams to manage
application quickly in case of any change required for a specific microservice .

Copyright @ Xebia 2022


Achieve DevOps
Integrate Infrastructure with CI/CD Tools
• By integrating infrastructure automation tools such as Kubernetes with CI/CD tools such as Jenkins, Bamboo, or GoCD can
address configuration management concerns and effective deployment. These tools prepare containers for risk tolerance
by way of continuous monitoring and rolling software updates.
More Test Automation and QA-Dev Alignment
• Recommend test automation to achieve faster delivery cycles. Depending on the extent of test automation cases,
functional testing can remain manual. On the other hand, QA-Dev alignment is crucial to address post-release issues. This
alignment helps in early bug detection and helps address the issue before the release of the next build.
Application Performance Monitoring
• Application performance monitoring helps in detecting, prioritizing and isolating application defects and their root causes
using respective software. These issues are usually revealed at the time of application server and UX monitoring activities.

Copyright @ Xebia 2022


Achieve DevOps
Continuous Integration

Continuous Delivery

Version Control

Agile Methodology and Learning

Monitoring and Logging

Public and Hybrid Clouds

Infrastructure as a Code

Microservices

Containers

Copyright @ Xebia 2022


Deep Dive to get the Steps Details :
• Continuous Integration: is a development practice where developers integrate code into a shared
repository frequently, preferably several times a day. Each integration can then be verified by an automated build and
automated tests. While automated testing is not strictly part of CI it is typically implied. Workflow of CI is :

Copyright @ Xebia 2022


Advantages of CI is :
Smaller Code Changes

Fault Isolations

Faster Mean Time To Resolution (MTTR)

More Test Reliability

Faster Release Rate

Smaller Backlog

Customer Satisfaction

Copyright @ Xebia 2022


Continuous Delivery:
• Continuous delivery expands upon continuous integration by deploying all code changes to a testing
environment and/or a production environment after the build stage.”
• Process to build, test, configure, and deploy from a build to a production environment. Multiple testing or
staging environments create a Release Pipeline to automate the creation of infrastructure and deployment of a
new build
• Continuous delivery is an ongoing DevOps practice of building, testing, and delivering improvements to software
code and user environments with the help of automated tools. The key outcome of the continuous delivery (CD)
paradigm is code that is always in a deployable state.

Copyright @ Xebia 2022


Continuous Delivery:

Copyright @ Xebia 2022


Advantages :

Deliver software with fewer bugs and


lower risk

Release new features to market more


frequently — and learn.

Respond to marketing conditions more


quickly.

Streamlining workflows.

Enhancing teamwork

Improving operational confidence.

Copyright @ Xebia 2022


Version Control:
• Version control, also known as source control, is the practice of tracking and managing changes to software code. Version
control systems are software tools that help software teams manage changes to source code over time.
• A category of software tools that helps in recording changes made to files by keeping a track of modifications done in the
code.

Copyright @ Xebia 2022


Advantages of VCS:

Reduction Of Open Channels


Document Branching And Management Adherence To
Traceability Identity Duplication And Of Efficiency
History Merging Overview Compliance
Errors Communication

Copyright @ Xebia 2022


Agile Methodology and Learning
• A way to manage a project by breaking it up into several phases. It involves constant collaboration with stakeholders and
continuous improvement at every stage. Once the work begins, teams cycle through a process of planning, executing, and
evaluating.
• Turn a vision for a business need into software solutions. Agile is a term used to describe software development
approaches that employ continual planning, learning, improvement, team collaboration, evolutionary development, and
early delivery. It encourages flexible responses to change.

Copyright @ Xebia 2022


Advantages of Agile:

More Control

Better Productivity

Better Quality

Higher Customer Satisfaction

Higher Return on Investment

It continuously gave attention to


technical excellence and good design.

Copyright @ Xebia 2022


Monitoring and Logging
• Tracking and storing data to ensure application availability and to assess the impact of state transformations on
performance. Monitoring is a diagnostic tool used for alerting DevOps to system-related issues by analyzing metrics.
• Learn about potential threats and discover events that lead to a security breach.
• Include many facets of system evaluation, but in this context, we're referring to application performance monitoring
(APM). APM is the process of instrumenting an application to collect, aggregate and analyze metrics to better evaluate the
use of the system by gauging availability, response time, memory usage, bandwidth, and CPU time consumption.

Copyright @ Xebia 2022


Advantages of Monitoring and Logging

MONITOR ALL EVENTS/METRICS IN ONE PLACE

IMPROVE SYSTEM PERFORMANCE

SAVE TIME

CORRECT ISSUES AUTOMATICALLY

CENTRALIZED LOG DATA

TIME_EFFICIENT MONITORING

Copyright @ Xebia 2022


Public and Hybrid Clouds
• Delivery of computing services—including servers, storage, databases, networking, software, analytics, and intelligence—
over the Internet (“the cloud”) to offer faster innovation, flexible resources, and economies of scale.
• On-demand availability of computer services like servers, data storage, networking, databases, etc. The main purpose of
cloud computing is to give access to data centers to many users. Users can also access data from a remote server.

Copyright @ Xebia 2022


Advantages
Reduced IT costs

Scalability

Business continuity

Collaboration efficiencyFlexibility of work practices

Access to automatic updates

Quality Control

Disaster Recovery

Copyright @ Xebia 2022


Infrastructure as a Code:
• Process that applies best practices from DevOps software development to the management of cloud infrastructure
resources.
• A form of configuration management that codifies an organization's infrastructure resources into text files. These
infrastructure files are then committed to a version control system like Git.
• Deals with the state of any given infrastructure or software system at any given time.

Copyright @ Xebia 2022


Advantages of Infrastructure as a Code:
Decreased risk

Stable & consistent environments for faster iterations

Cost optimization

Self-documenting

Increased efficiency in software development

Integrate with your process

Automated scanning.

Copyright @ Xebia 2022


Microservices:
Architectural and organizational approach to software development where software is composed of small independent
services that communicate over well-defined APIs.
Microservices are an architectural and organizational approach to software development where software is composed of
small independent services that communicate over well-defined APIs. These services are owned by small, self-contained
teams.
Architectural design for building a distributed application using containers. They get their name because each function of the
application operates as an independent service. This architecture allows for each service to scale or update without
disrupting other services in the application.

Copyright @ Xebia 2022


Advantages of Microservices:

Better resiliency

Increased scalability

CI/CD

Optimize business functionality

Better Fault Isolation for More Resilient Applications

Better Data Security and Compliance

Faster Time to Market and “Future-Proofing”

Greater Business Agility and Support for DevOps

Copyright @ Xebia 2022


Containers :
• A lightweight, standalone, executable package of software that includes everything needed to run an application: code,
runtime, system tools, system libraries and settings.
• Provides a emerging way of virtualization and easy to configure.

Copyright @ Xebia 2022


Advantages of Containers:
Less overhead

Increase Portability

More consistent Operation

Great Efficiency

Better Application Development

High Scalability

Speed: Start, Create, Replicate or Destroy Containers in Seconds

Copyright @ Xebia 2022


Continuous Practices:
software development practice where developers regularly merge their code changes into a central
repository, after which automated builds and tests are run.
Three main pillars of continuous practice :

Continuous
Integration

Continuous
Delivery

Continuous
Deployment

Copyright @ Xebia 2022


Continuous Integration:
• To identify the customer needs with timely delivery meet the increased competition in the market ,organizations have
decided to pay attention over the continuous practices to develop and deploy the end product as per customer
requirement
Continuous Integration :
• Continuous integration is a DevOps software development practice where developers regularly merge their code changes
into a central repository, after which automated builds and tests are run. Continuous integration most often refers to the
build or integration stage of the software release process and entails both an automation component (e.g. a CI or build
service) and a cultural component (e.g. learning to integrate frequently). The key goals of continuous integration are to
find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software
updates.
Why is Continuous Integration Needed?
• In the past, developers on a team might work in isolation for an extended period of time and only merge their changes to
the master branch once their work was completed. This made merging code changes difficult and time-consuming, and
also resulted in bugs accumulating for a long time without correction. These factors made it harder to deliver updates to
customers quickly.

Copyright @ Xebia 2022


Continuous Integration :

Copyright @ Xebia 2022


Continuous Integration:

• Focuses on preparing the early release.


• As per Martin Fowler, one of the authors of Agile Manifesto “ Continuous Integration is a software Development Activity
where members of team integrate their work frequently, usually each person integrates at least daily-leading to multiple
integrations per day”
• Each Integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
• This is actually reducing time integration problems and allows a team to develop cohesive software more rapidly.

Copyright @ Xebia 2022


How does Continuous Integration Work?

• With continuous integration, developers frequently commit to a shared repository using a version control system such as
Git.
• Prior to each commit, developers may choose to run local unit tests on their code as an extra verification layer before
integrating. A continuous integration service automatically builds and runs unit tests on the new code changes to
immediately surface any errors.

Copyright @ Xebia 2022


How does Continuous Integration Work?

Copyright @ Xebia 2022


Working Continuous Integration :
• With continuous integration, developers frequently commit to a shared repository using a version control system such as
Git. Prior to each commit, developers may choose to run local unit tests on their code as an extra verification layer before
integrating. A continuous integration service automatically builds and runs unit tests on the new code changes to
immediately surface any errors.

Copyright @ Xebia 2022


How Continuous Integration revolutionize the
Organization's Software Delivery ?
• Initially ,developers,tester,product managers were working in isolation and the developed code was integrated into the
code repository only after the complete process is done.
• This become really tedious , hectic and time consuming process .
• There were lots of merge with conflicts which consumed a lot of time
• Bugs kept on accumulating , count is high and because of this developers were able to identify and fix them only at later
stage.
• Multiple roadblocks with respect to :
• Identification of bugs
• Usage of developers and testers at right time with right time limit
• Clarification in process.
• Complex and ambiguous communication
• Multiple flow of communication and information.

Copyright @ Xebia 2022


Continue..
• With CI ,the software code is contained in a shared repository, accessible by developers so they can “check out” code to
individual workstations. When ready, they push the code back into the repository to commit changes. From there, the
automated CI server takes over, automatically building the system and running unit and integration tests to ensure the
code did not break another part of the software. If the build is unsuccessful, the server pinpoints where in the testing
process the code failed, letting the team address it at the earliest point of failure.
• This CI process occurs many times per day, meaning the system constantly builds and tests new code. The updated
software can then be released manually, or DevOps teams can further automate the project by electing to have the system
deploy and deliver the product.

Copyright @ Xebia 2022


Continuous Integration Practices:

Every
commit
Write
Commit Maintain a Don’t should build Fix broken All tests and Avoid
Automate Keep the automated Run Private Automated
code single source commit the main build inspection getting
the build build fast developer Builds Deployment
frequently repository broken code code on immediately must pass broken code
tests
integration
machine

Copyright @ Xebia 2022


Under Continuous Integration Steps as
practice :
• Commit Code Frequently :
• Prepare and integrate it early.
• Commit code to your version control repository ,atleast once in a day.
• Waiting for more than a day to commit the source code consumes a lot time and prevents other developers from
using the most updated version of the source code.

Make small change

Commit After Each Task

Copyright @ Xebia 2022


Importance of Frequent Code Commit

• Everyone committing at the same time may lead to confusions and conflicts
• Build errors may occur because of the Collison between changes .
• One of the central tenant of CI is integrated early and often developers must commit code properly and frequently in
order to gain the complete benefits of CI
• Frequent ways to commit the code :
• Make small changes :
• Avoid too many changes in one component at a time.
• Choose small tasks, write the unit/component/integrations tasks .
• Run your test cases
• Commit your code to the version control repository
• Commit after each tasks :
• Each Tasks and work should be broken up so that they can be finished quickly.
• Avoid having everyone commit the code ,should have lesser authorities to commit the code.
• There will be many build errors to manage because of the collision between changes made by developer at
same time

Copyright @ Xebia 2022


Managing Single Code Repository :
• Use a source code management system that serves as a centralized source code repository
• Source code management tools are available to maintain the code in single centralized location, from where developers
can check out the latest version of the main build
• Everything the developer creates should be pushed to this source code repository, including :
• Test properties : To test various features of an application
• Dataset with Schema and Data: To test the application
• install scripts and third party libraries to setup the infrastructure
• Most importantly, there should be a main single branch of the project that is production ready.

Copyright @ Xebia 2022


Managing Single Code Repository :

Copyright @ Xebia 2022


Managing Single Code Repository :
• Software Team today work in the distributed fashion .
• When multiple people build individual pieces of code ;it is really important that entire team has access to the source code
and the complete version of the software is upto date .
• Teams have build multiple tools to manage this code. These tools are collectively referred to as source code management
tools.
• Everyone in the team should be aware of the functionalities of the source code management system. The source code
repository is not only meant for the code, but developers should put in everything that is required for a build, including
test scripts, properties files, database schema, installation scripts ad third party libraries.
• Version control systems allow us to create multiple branches of the code, that can handle multiple streams of
development. This feature should be used judiciously, as too many branches will put people in trouble. It is essential that
there is be a single branch of the project that is currently under development, the mainline.
• In short, developers should store in the source control management system, everything they need to build.

Copyright @ Xebia 2022


Don't Commit Broken Code :
• Don't commit code that does not compile with other code or fails a test.
• Everyone in the development team should be aware that they should not commit code that doesn't work.
• Committing broken or non-functional code will affect the code in integration machine, and fellow developers will not get
the correct version of the code.
• Every developer should follow the practice of carrying out a private build before checking the code into the centralized
repository.
• Facilitator Notes: Explain the participants the importance committing only the working version of the code.
• A dangerous assumption on a project is that everyone knows not to commit code that doesn't work to the version control
repository. The ultimate mitigation for this risk is having a well-factored build script that compiles and tests the code in a
repeatable manner.
• Developers should always follow the practice of carrying out a private build (which closely resembles the integration build
process) before committing code to the version control repository.

Copyright @ Xebia 2022


Don't Commit Broken Code :

Copyright @ Xebia 2022


Automate the Build :
• The build process has to be automated in a Cl environment, which help build and launch the system using a single command.
• The command will run the build scripts necessary for automating the build process.
• A build process should include everything including getting the database schema from the repository and launching it in the
production environment.
• Most of the development environments that we use these days have built management systems ,but these are proprietory to the
development environment and fragile .Examples Ant, Ruby Rake, MSBuild.
• The build process includes source code compilation, gathering of files, loading of schemes on to databases etc.
• Working on the build process can be complicated and time consuming task.
• The build process has to be automated such that the entire process can be carried out using Scripts that are executed by running
single command
• A build process should include everything including getting the database scheme from the repository and launching in the
production environment.
• A build script allow us to do different things based on the use case. Many of the integrated development environments (DE) have
some sort of build management system, but these are proprietary to the IDE and could be fragile. IDE users can set up their own
projects and use them for individual development. It is important to have a master build that used on a server and is run using
other scripts

Copyright @ Xebia 2022


Keep the build Fast :
• Any build that takes an hour is considered unreasonable Extreme programming (XP) has set a guidline that every build
should take not more than X minutes
• Faster build is seeing up a deployment pipeline, which enables multiple builds in a sequence.
• The first build, also called commit build is the one that is triggered when a developer commits to the machine. The commit
build is done so quickly that it may bypass bugs and balanced approach is necessary to identity bugs and gain speed
• At stage deployment pipeline can do compilation and run multiple localized tests, and at the same time it here to be X
minute guideline

Copyright @ Xebia 2022


How to keep the build fast:
• The most crucial steps to start working on setting up a deployment pipeline.The idea behind the deployment pipeline (also
known as “build pipeline/Stage Pipeline”) is that there are infact multiple builds running in sequence.
• Commit to the main branch triggers the first build >> called as commit build.
• Commit build is the build that is needed when someone commits to the main branch.
• The commit build is the one that has to be done quickly as a result it will take a number of shortcuts that will reduce the
ability to detect bugs.
• Trick is to balance the needs of bugs finding and speed so that a good commit build is stable enough for other people to
work upon .
• Once the commit build is better than other people can work on the code .

Copyright @ Xebia 2022


Example: To keep the build fast:
• Two Stage Deployment Pipeline :
• The first stage would do the compilation and tests that are more localized unit tests with the database completely stubbed
out.
• Such tests can very fast keeping the X minute guideline. However any bugs that involve larger scale interactions
particularly those involving the real database won’t be found.
• The second stage build runs different suites of tests that do the real database and involve more end-to-end behavior. The
suite might take a couple of hours to run
• In this scenario people use the first stage as the commit build and use this as their main CI cycle.
• The second stage build runs when it can picking up the executable from me latest good commit build for further testing
• If this secondary build then this may not have the same stop everything Quality but the team does aim to fix such bugs as
rapidly as possible, while keeping the commit build running .
• As in this example later builds are often pure tests since these days it usually tests that cause the slowness

Copyright @ Xebia 2022


Example: To keep the build fast:
• If the secondary build detects a bug that’s a sign that the commit build could do with another test As much as possible you
want to ensure that any later-stage failure leads to new tests in the commit build that would have caught the bug, so the
bug stays fixed in the commit build. This way, the commit tests are strengthened whenever something gets past them.
There are cases where there's no way to build a fast running test that exposes the bugs, so you may decide to only test for
that condition in the secondary build.
• Most of time fortunately you can add suitable tests to the common build.
• This example is of two stage build pipeline but the basic principle can be extended to any number of later stages. The
builds after the commit can also be done in parallel so if you have Y(number) hours of secondary tests you can move
responsiveness by having “Z”(number) machines that run half the tests each.
• By using parallel secondary builds like this you can introduce all sorts of further automated testing ,including performance
testing into the regular build process.

Copyright @ Xebia 2022


Every Commit should build the MAINLINE
• Regular build should happen on the integration machine and the builds should succeed in order for the commit to be
considered as done.
• The developer who commits the latest code should be responsible for monitoring the mainline build ,so that they can fix if
anything breaks.
• A CI server act as a monitor the repository. Every time the commit gets done , the server check the source code onto the
integration machine and initialize the build.
• The result of the build process is also notified to the committer through email.
• Regular builds should also ensures that the problems are identified well in early.
• Before every commit, developers should update and build. Regular builds should happen on integration machine and a
commit is considered done only if the build succeeds. The developer who does the commit is responsible for the mainline
build, so that they can track and fix if there is any breakage to the code. Manual build process is simple that a developer
checks the mainline and starts the integration process. Continuous integration servers act as a monitor to the repository.
Once a commit happens, the server automatically checks out the source code onto the integration machine.
• Doing a regular build at night is not an advisable process, as the build stays unchecked for a long time, as a result bugs lie
undetected for the whole day, before anyone discovers them. This makes the idea of continuous integration pointless, as it
is all about early fault detection

Copyright @ Xebia 2022


Fix Broken Builds Immediately :
• A broken build is anything that prevents the build from reporting success.
• Though it is common for a mainline build to break, the key part is that any error in the mainline build has to be fixed right
away.
• Although it's the team's responsibility, the developer who recently committed code must be involved in fixing the failed
build.
• The best way to fix a broken mainline build is to revert the most recent commit from the mainline.
• It is not advisable to debug on a broken mainline, unless the cause of breakage is very obvious. Debugging should always
be done in the local development environment after reverting to the latest known good build
• A broken build is anything that prevents the build from reporting success. This may be a compilation error, a failed test or
inspection, a problem with the database, or a failed deployment. When operating in a Cl environment, these problems
must be fixed immediately; fortunately, in a Cl environment, each error is discovered incrementally and therefore is likely
very small. The most important aspect of Cl is that one should always develop on a stable version of the code.

Copyright @ Xebia 2022


Write Automated Developer Tests:
• A build should be automated. In order to run tests for a CI system, the tests must be automated.
• Verify that the software works using automated developer tests .Run these tests with your automated build and run them often
with CI.
• Testing can catch a lot of bugs, even from program that runs
• Methods lie extreme programming and test driven development TDD have put a lot of emphasis on self testing code and for this
automated test can check large part of code for bugs
• Writing tests in an Xunit framework such as Nunit/JUnit will provide the capability of running these tests in an automated fashion
• A build includes compiling linking and all the additional processes are required by a program to execute. A program may run, but it
may still contain bugs or errors
• Testing such a process that identifies errors even from program that executes e.g., working program including automated tests in
the build process can identity lots of such bugs, despite the program being complex
• In order to run tests for a CI system, the tests must be automated writing the tests
• Writing the tsts in XUNit framework such as NUnit or Unit will provide the capability of running these tests in an automated
fashion
• Methods extreme programming and test-driven development (TOD have put a lot of emphasis on self –testing code.
• A suite of automated test is is needed for a self testing code, that can check large chunk of code for bugs
• TDD has popularize the xUnit framework ,though testing cannot be guaranteeing a 100% clean code

Copyright @ Xebia 2022


All tests and Inspections must Pass :
• In a CI environment it is very important 100% of the tests must pass prior to committing of code to the version control
repository.
• Automated tests are as important as the compilation process.
• Keeping the main line with code that doesn’t pass the automated tests can result in low quality software.
• Coverage tools helps in identifying the source code that doesn’t have a corresponding tool. This ensures that the entire
code undergoes the testing phase
• In Cl environment the technical criteria is that 100% of projects automated test must pass the build for the build to pass.
• Everyone accepts that code that does not compile will not work therefore code that has tests errors will not work either
• Accepting code that does not pass the tests lead to lower-quality software
• Coverage to assist in pinpointing source code does not have a corresponding test.
• You can run code coverage tool as part of an integration build.
• The same goes for automated software inspectors. A general rule set of coding and design standards that all code must
pass, can be used.
• More advanced inspections may be added that don't tell the build, but areas of the code should be investigated have to be
identified

Copyright @ Xebia 2022


Run Private Builds:
• To prevent integration failures changes from other developers have to be received by getting the latest changes from the
repository and running full integration build locally known as a private system build.
• Developers should run an integration build in their local development environment after the code undergoes unit tests
• Code that the developer commits to the integration build server is less key to undergoes a private system build.
• To prevent broken build, developers should emulate an integration build on their local workstation IDE after completing
their unit tests. This build allows you to integrate your working software with the working software from the other
developers, obtaining the changes from the version control repository and successfully building locally with the recent
changes. Thus, the code each developer commit will be less likely to fail on the integration build server

Copyright @ Xebia 2022


Avoid getting Broken Code:
• Getting a failed build from the repository means the latest code is not checked out from the repository.
• This consumes a lot of time and effort as developer has to do some workaround to fix the error that has caused the build
failure for compiling and testing the code.
• Developer can wait for the change to fix the build failure and then getting the latest code.
• Though it is the responsibility of the team, the developer(s) who caused the breakage should fix the bug, for the build to
work fine.
• When the build is broken, one should not check out the latest code from the version control repository. Otherwise, the
developer will end up spending a lot of time, developing a workaround to the error that has caused the failure, just to
compile and test the code. Ultimately, it's the responsibility of the team to fix, but the developers responsible for breaking
the build should already be working on fixing their code and committing it back to the version control repository.
Sometimes a developer may not have seen the email on the broken build. It is critical that all developers know the state of
the code in the version control repository.

Copyright @ Xebia 2022


Automated Deployment :
• Automating the deployment is similar to automated build, we have a script that does the deployment automatically into
any environment.
• Automated deployment helps speed up the process and reduce errors.
• Automated deployment is an economically viable option because it requires the same capabilities that are required to
deploy in a test environment.
• There should be a provision for automated rollback, since failures can happen at any point in time.
• For testing new features or user interfaces, it is always suggested to deploy trial build deployed to a subset of users, who
will then decide if it can be deployed to all users.
• In continuous integration, there will be multiple environments and the artifacts need to be moved across these
environments many times a day. It is quintessential to do these deployments automatically into any environment. You
need to have scripts to do this automated deployment in the test and production environments with similar ease.
Deployment to production environment may happen every day, but having automated deployment improves speed and
reduces errors.
• Automated deployment is also an economically viable option, since the same capabilities are required to deploy in test
and production. If the application is deployed in production, there should be a capability for an automated rollback ,since
failures are anticipated at any point time.

Copyright @ Xebia 2022


How Continuous Integration Complements
Other Software Development Activities:
• Developer testing :
• Developers who write tests most often use some used some xUnit based framework such as Junit/Nunit. These tests
can be automatically executed from the build script; since the practice of CI advocates that build can be run any time
in a change is made to the software and that the automated tests are part of these builds.
• CI enables automated regression tests to be run on the entire code base whenever change is applied to the software.
• Coding Standard Adherence:
• set of guidelines that developers must adhere to an projects. On many projects .ensuring adherence is largely a
manual process that is performed by a code review.
• CI can run a build script to report on adherence to the coding standards by running a suite of automated static
analysis tools that inspects the code against the established standards whenever a change is getting applied.
• Refactoring:
• As Fowler states, refactoring is the process of changing the software system in such a way that it does not alter the
external behavior of the code yet improves its internal structure." Among other benefits, this makes the code easier
to maintain. Cl can assist with refactoring by running inspection tools that identify potential problem areas at every
build.

Copyright @ Xebia 2022


How Continuous Integration Complements
Other Software Development Activities:
• Collective ownership:
• Any developer can work on any part of the software system. This prevents 'knowledge silos', where there is only one
person who has knowledge of a particular area of the system. The practice of Cl can help with collective ownership
by ensuring adherence to coding standards and the running of regression tests on a continual basis.

• Small releases:
• This practice allows testers and users to get working software to use and review as often as required. Cl works very
well with this practice, because software integration is occurring many times a day and a release is available at
virtually any time. Once a CI system is in place, a release can be generated with minimal effort.

Copyright @ Xebia 2022


What are Continuous Integration, Delivery, and
Deployment

Copyright @ Xebia 2022


Continuous Integration, Delivery, and
Deployment
• Continuous integration :
• Developers practicing continuous integration merge their changes back to the main branch as often as possible. The
developer's changes are validated by creating a build and running automated tests against the build. By doing so, you
avoid integration challenges that can happen when waiting for release day to merge changes into the release branch.
• Puts a great emphasis on testing automation to check that the application is not broken whenever new commits
are integrated into the main branch.
• Continuous delivery
• Is an extension of continuous integration since it automatically deploys all code changes to a testing and/or
production environment after the build stage.
• This means that on top of automated testing, you have an automated release process and you can deploy your
application any time by clicking a button.
• With continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business
requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production
as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

Copyright @ Xebia 2022


Continuous Integration, Delivery, and
Deployment
• Continuous deployment :
• Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes
all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed
test will prevent a new change to be deployed to production.
• Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure
off the team as there isn't a "release day" anymore. Developers can focus on building software, and they see their
work go live minutes after they've finished working on it.

Copyright @ Xebia 2022


How the practices relate to each other

Copyright @ Xebia 2022


Difference between CI vs CD vs CD
Continuous Integration Continuous Delivery Continuous Deployment

CI is an approach of testing each change to CD is an approach to obtain changes of new


CD is an approach to develop software in a short cycle.
codebase automatically. features, configuration, and bug fixes.

CI refers to the versioning of source code. CD refers to the logical evolution of CI. CD refers to automated implementations of the source code.

CI focuses on automation testing to determine that Focuses on releasing new changes to your
Emphasis on the change in all stages of your production pipeline.
the software has no errors or bugs. clients properly.

In CD, developed code is continuously


CI is performed immediately after the developer In CD, developers deploy the code directly to the production stage when it
delivered until the programmer considers it
checks-in. is developed.
is ready to ship.

It allows developers to check software


It helps you to identify and rectify issues early. It enables you to rapidly deploy and validate new features and ideas.
updates.

Copyright @ Xebia 2022


Difference between CI vs CD vs CD
Continuous Integration Continuous Delivery Continuous Deployment

It uses unit tests. It uses business logic tests. Any testing strategy is performed.

Development team sends


continuous code merging You deliver code for review that Deploy code using an automated
requests even when the can be batched for release. process.
testing process is running.

You require a continuous


You require a strong foundation
integration server to monitor You need a good testing culture.
in continuous integration.
the main repository.

Copyright @ Xebia 2022


Advantages of Continuous Integration
• Helps you to build better quality software
• It enables you to conduct repeatable testing.
• CI allows software developers to work independently on features in parallel.
• It can increase visibility and enable greater communication.
• CI process help to scale up Headcount and delivery output of engineering teams.
• Continuous integration helps you to develop a potentially shippable product for a
fully automated build.
• Helps you to reduce risks by making deployment faster and more predictable
• immediate feedback when an issue arrives.

Copyright @ Xebia 2022


Advantages of Continuous Integration
• Avoid last-minute confusion at the release date, and timing automates the
build.
• It reduces risks and makes the deployment process more predictable.
• CI provides instant feedback when there is an issue.
• You can see the integration process in real time.
• It can avoid last-minute hassle at release dates.
• The current build is available constantly.
• Provides shippable products on a regular base.
• It is relatively easy to find a history of the software build.
• CI offers code stability.
Copyright @ Xebia 2022
Disadvantages of Continuous Integration

• Initial setup time and training is required to get acquainted with Cl server
• Well-developed test-suite required many resources for Cl server.
• It requires additional servers and environments.
• You need a conversion of familiar processes in one project.
• It goes for waiting when multiple developers integrate their code around the same time.
• Your team should write automated tests for each and every new feature or bug fix.
• You require a CI server that monitors the main repository and run the tests for new code commits.
• Developers should merge their changes as more often as possible.
• The unit testing procedure should pass for the Deployment.

Copyright @ Xebia 2022


Advantages of Continuous Delivery

• Automate the software release process for making delivery more efficient, rapid, and secure.
• CD practices increase productivity by freeing developers from manual work and complex dependencies.
• It helps you to discover software bugs early in the delivery process.
• CD helps your business team to deliver updates to clients immediately and frequently.
• It ensures the software is always ready to go to production.
• You can release software more frequently, which helps you to get fast feedback from your clients.
• There is less pressure on decisions for small changes.

Copyright @ Xebia 2022


Disadvantages of Continuous Delivery

• You should know continuous integration practices before you go for continuous delivery.
• Deployments are still manual, and hence it takes lots of time to deliver the software product.
• The automated tests should be written and function properly.
• Faulty tests can lead to damage while quality testing.
• It requires team coordination because code changes should be collected regularly in an efficient way.
• Continuous delivery requires a reliable and strong integration server for the automation test that is costly.

Copyright @ Xebia 2022


Advantages of Continuous Deployment

• It helps you to automate the repetitive tasks.


• CD makes your deployment flawless without compromising security.
• Easily scale from a single software application to an enterprise IT portfolio.
• You can ship cloud-native as well as traditional applications.
• It gives a single view across all environments and applications.
• You can connect your existing DevOps tools and scripts into a proper workflow.
• CD enables you to increase overall productivity.
• You can integrate processes and teams with a unified pipeline.

Copyright @ Xebia 2022


Disadvantages of Continuous Deployment

• Your testing culture should be good as the quality of the suite determines how good software releases are.
• Documentation procedures need to keep up with deployment pace.
• Releasing significant changes needs assurance by marketing, help, and support, and other departments.

Copyright @ Xebia 2022


Continuous Integration Best Practices

• Automate your software build.


• Keep the build as fast as possible.
• Every commit should result in a build
• Automate Deployment
• Commit early and often.
• You should never commit broken code
• Fix build failures immediately.
• Build-in every target environment Create artifacts from every build

Copyright @ Xebia 2022


Continuous Integration Best Practices

• The build of the software needs to be carried out in a manner so that it can be automated
• Do not depend on an IDE
• Build and test everything when it changes
• The database schema counts as everything
• Helps you to find out key metrics and track them visually
• Check-in often and early.
• Stronger source code control.
• Continuous integration is running unit tests whenever you commit code.
• Automate the build and test everyone.
• Keep the build fast with automated Deployment.

Copyright @ Xebia 2022


Continuous Delivery Best Practices

• The first stage must be triggered upon every check-in.


• Each stage should trigger the next one quickly upon successful completion.
• Maintain the version of the source code.
• Perform automated build and Deployment.
• Deploy to one instance of a virtual machine at a time.
• Perform unit and integration tests.
• You have to build your library only once.
• The team should use the same automated release method for each and every environment.
• This method enables you to eliminate conflicts and last-minute problems.
• In case any state fails, you should automatically pause the process and fix the issues.

Copyright @ Xebia 2022


Continuous Deployment Best Practices

• You should use an issue tracker for the development task.


• In your version controlling system, you should create a branch that contains the issue number and description of any
change you have made.
• When software is ready for the Deployment, you can create a pull request for the branch.
• Deployment software to pre-production staging servers.
• Promote your software once you are happy with its quality.

Copyright @ Xebia 2022


Challenges of Continuous Integration

• It makes the developing process slow.


• Exposes problems and sharing of issues.
• It may lead to a lack of maintenance of version control.
• It can force you to deal with problems.
• Difficulty in building automated code repository.
• Untested or broken code must not be committed.

Copyright @ Xebia 2022


Challenges of Continuous Delivery

• You need to keep the continuous delivery efficient without bothering the time.
• You need to cope up with tight deadlines release plan.
• Poor product-specific communication of teams may lead to revisions as well as deployment delays.
• The business team should have the budget to have the infrastructure needed to build more impressive software.
• Monitoring data/ information should be utilized by the research and development team.
• The organization should ensure that how open source software fits into the current workflow.

Copyright @ Xebia 2022


Challenges of Continuous Deployment

• CD requires continuous planning to achieve frequent and fast releases.


• Ensure the alignment between the requirement of the business context and application development.
• Rapid delivery must not be isolated to the software development process alone.
• The flow should go with the overall software development cycle.
• Experimental results must be continuously linked with the software roadmap.

Copyright @ Xebia 2022


Version Control System
• Version control systems are a category of software tools that helps in recording changes made to files by keeping a track of
modifications done in the code.
• The practice of tracking and managing changes to software code. Version control systems are software tools that help
software teams manage changes to source code over time. As development environments have accelerated, version
control systems help software teams work faster and smarter. They are especially useful for DevOps teams since they help
them to reduce development time and increase successful deployments.
• Version control software keeps track of every modification to the code in a special kind of database. If a mistake is made,
developers can turn back the clock and compare earlier versions of the code to help fix the mistake while minimizing
disruption to all team members.
• VCS is basically software designed to record changes within one or more files over time. It allows us to undo or to cancel
all made or pending changes within one or more files. If we're working on a project with many files, VCS enables us to
control the whole project.
• VCS enables us to control the whole project. If necessary, this allows us to revert one or more files any of their previous
versions or the whole project to a previous version. We can also compare changes to one file between two versions in
order to see exactly what was changed in each file, when it was changed and who made the change. We can also see why
the change was made.

Copyright @ Xebia 2022


Version Control System

Copyright @ Xebia 2022


Why Version Control system is so
Important?
• A software product is developed in collaboration by a group of developers they might be located at different locations and
each one of them contributes to some specific kind of functionality/features. So in order to contribute to the product, they
made modifications to the source code(either by adding or removing).
• A version control system is a kind of software that helps the developer team to efficiently communicate and manage(track)
all the changes that have been made to the source code along with the information like who made and what changes have
been made.
• A separate branch is created for every contributor who made the changes and the changes aren’t merged into the original
source code unless all are analyzed as soon as the changes are green signaled they merged to the main source code. It not
only keeps source code organized but also improves productivity by making the development process smooth.
• Basically Version control system keeps track on changes made on a particular software and take a snapshot of every
modification . Let’s suppose if a team of developer add some new functionalities in a application and the updated version
is not working properly so as version control system keeps track of our work so with the help of version control system we
can omit the new changes and continue with the previous version .

Copyright @ Xebia 2022


Why Version Control system is so
Important?
• Benefits of the version control system:
• Enhances the project development speed by providing efficient collaboration,
• Leverages the productivity, expedites product delivery, and skills of the employees through better communication and
assistance,
• Reduce possibilities of errors and conflicts meanwhile project development through traceability to every small change,
• Employees or contributors of the project can contribute from anywhere irrespective of the different geographical locations
through this VCS.
• For each different contributor to the project, a different working copy is maintained and not merged to the main file
unless the working copy is validated. The most popular example is Git, Helix core, Microsoft TFS,
• Helps in recovery in case of any disaster or contingent situation,
• Informs us about Who, What, When, Why changes have been made.
• Managing and Protecting the Source Code

Copyright @ Xebia 2022


Why Version Control system is so
Important?
• Version control systems offer numerous benefis to the development teams. Some of the important benefits of the case
given below.
• Creation of workflow: Version control workflows prevent the chaos of everyone using their own development process
with different and incompatible tools. Version control Systems provide process enforcement and permissions so everyone
stays on the same page
• Working with versions: Every version has a description for what the changes in the version do, such as for a bug or add a
feature. These descriptions help you follow changes in your code by version instead of by individual file changes. The code
stored in versions can be viewed and restored from version control at any time as needed. This makes it easy to base new
work of any version of the code
• Concurrent Coding: Version control synchronizes versions and make sure that one change doesn't conflict with other
changes from other developers version control integrates work done simultaneously by different team members. In most
cases edits to different files or even the same file can be combined without losing any work. In rare cases, when two
people make conflicting edits to the same line of file, then the version control system requests human assistance in
deciding what to do
• History of changes Version control keeps history of changes as your team saves new versions of your code. This history can
be reviewed to fined out why and when changes were made. History gives you the confidence to experiment since you can
roll back to a previous good version any time.

Copyright @ Xebia 2022


Use of Version Control System:

• A repository: It can be thought of as a database of changes. It contains all the edits and historical versions (snapshots) of
the project.
• Copy of Work (sometimes called as checkout): It is the personal copy of all the files in a project. You can edit to this copy,
without affecting the work of others and you can finally commit your changes to a repository when you are done making
your changes.

Copyright @ Xebia 2022


Types of Version Control Systems:

• Local Version Control Systems It is one of the simplest forms and has a database that kept all the changes to files under
revision control. RCS is one of the most common VCS tools. It keeps patch sets (differences between files) in a special
format on disk. By adding up all the patches it can then re-create what any file looked like at any point in time.
• Centralized Version Control Systems :Centralized version control systems contain just one repository globally and every
user need to commit for reflecting one’s changes in the repository. It is possible for others to see your changes by
updating. Two things are required to make your changes visible to others which are:
• You commit
• They update
• The benefit of CVCS (Centralized Version Control Systems) makes collaboration amongst developers along with providing
an insight to a certain extent on what everyone else is doing on the project. It allows administrators to fine-grained control
over who can do what.
• It has some downsides as well which led to the development of DVS. The most obvious is the single point of failure that
the centralized repository represents if it goes down during that period collaboration and saving versioned changes is not
possible. What if the hard disk of the central database becomes corrupted, and proper backups haven’t been kept? You
lose absolutely everything.

Copyright @ Xebia 2022


Centralized Version Control Systems

Copyright @ Xebia 2022


Distributed Version Control Systems
• Distributed version control systems contain multiple repositories. Each user has their own repository and working copy.
Just committing your changes will not give others access to your changes. This is because commit will reflect those
changes in your local repository and you need to push them in order to make them visible on the central repository.
Similarly, When you update, you do not get others’ changes unless you have first pulled those changes into your
repository.
• To make your changes visible to others, 4 things are required:
• You commit
• You push
• They pull
• They update
• The most popular distributed version control systems are Git, and Mercurial. They help us overcome the problem of single
point of failure.

Copyright @ Xebia 2022


Distributed Version Control Systems

Copyright @ Xebia 2022


Purpose of Version Control:

• Multiple people can work simultaneously on a single project. Everyone works on and edits their own copy of the files and it
is up to them when they wish to share the changes made by them with the rest of the team.
• It also enables one person to use multiple computers to work on a project, so it is valuable even if you are working by
yourself.
• It integrates the work that is done simultaneously by different members of the team. In some rare cases, when conflicting
edits are made by two people to the same line of a file, then human assistance is requested by the version control system in
deciding what should be done.
• Version control provides access to the historical versions of a project. This is insurance against computer crashes or data
loss. If any mistake is made, you can easily roll back to a previous version. It is also possible to undo specific edits that too
without losing the work done in the meanwhile. It can be easily known when, why, and by whom any part of a file was
edited.

Copyright @ Xebia 2022


End of Module

Copyright @ Xebia 2022

You might also like