Deployment Strategies Powerpoint Presentation Slides

Deployment
Strategies
Your C ompany N ame

2
Agenda
03 Your Text Here
This slide is 100% editable. Adapt it to your needs and capture your
audience's attention.
04 Put Text Here
02 Routing Techniques
01 Company Software Updates
Deployment Strategy

Contents
01 Deployment Overview
02 Challenges of Modern Applications
03 Rolling Deployments
04 Rolling Deployment Use Case
05 Blue/Green Deployments
06 Blue/Green Deployment Use Case
07 Canary Deployments
08 Canary Deployment Use Case
09 Routing Techniques
10 Deployment Best Practices
11 Deployment Strategies Comparisons
12 Post-Deployment Monitoring
3

Deployment Overview
4
DEPLOYMENT OVERVIEW
Number of Sites or Release Recipients Target Deployments Target Group Scheduled Dates
<Identify the number & location (if applicable) of the sites/ release recipients for the software
application/system>
Initial Deployment <Site/Release Recipients> <Month/Year>
General Availability Release <Site/Release Recipients> <Month/Year>
Description
<Describe the deployment approach that will be used for deploying the software application/system>
Benefits (Tangible & Intangible) & Risks
<Describe tangible & intangible benefits realized from the recommended approach>
DEPLOYMENT APPROACH
Assumptions
<List any assumptions associated with the deployment approach>
Risks
<List any associated with the deployment approach
ASSUMPTIONS & RISKS

Challenges of
Modern Applications
This slide covers challenges faced by the modern applications
Listed here are some of
the challenges faced by
modern applications. User
can add according to their
requirements.
52%
of internet traffic
is bot generated, half of which is attributed to “bad” bots.
79%
of organizations
can’t make a clear distinction between good and bad bots.
Unfortunately,
One of the most important challenges faced by a web-
facing application is the ability to handle a large number
of concurrent users.
Modern applications need to be able to handle large
amounts of data.
Lack of handling failures gracefully without any data loss
or interruptions.
This slide is 100% editable. Adapt it to your needs and capture your audience's attention.
52%
79%
5

In this slide we have covered rolling deployment architecture
Both Nodes Running…. Patching 1st Node…. Patching 2nd Node…. Both Nodes Running….
This slide covers rolling
deployments nodes
model and its working,
user can edit according to
his requirements.
In a rolling deployment, an application’s new version gradually replaces the old one.
The actual deployment happens over a period of time.
During that time, new and old versions will coexist without affecting functionality or user experience.
Deployment Strategy - Rolling Deployments
6

Rolling Deployment Pattern
7
This slide covers the
rolling deployment pattern
i.e. how new version
upgrades or modified
without affecting existing
users, user can alter
according to their
requirements.
State 0
State 1
State 2
Final State
The original applications were deployed in containers, the
upgrade can tackle one container at a time.
Each container is modified to download the latest image
from the app vendor’s site.
Old Version New Version
The old version is shown in blue and the new version is shown in green across each server in the cluster.

Rolling Deployment
Use Case
This slide shows the deployment of the application to PROD environment in
four phases.
This slide covers the use
of rolling deployment in
PROD environment with
in different phases. User
can alter according to his
requirements.
The Application
consists of three
tiers, the Web,
App and DB tiers.
We will deploy the
application to the
PROD environment
in four phases:
First Phase
Deploy only to
the DB tier and
verify the DB
upgrade
Second Phase
Deploy to a few
resources in the App and
Web tiers and verify that
the application was
deployed successfully
Third Phase
Deploy to a few
more resources in
the App tier based
on some rules
Fourth Phase
Deploy to the
remaining
resources
Phase
This slide is 100% editable. Adapt it to your needs and capture your audience's attention. 8

Deployment Strategy - Blue-Green, Red-Black or A/B Deployment
9
This slide explains the functioning of blue green deployment strategy
This slide covers the
functioning of blue green
deployment environment,
while new version is
deployed the older one
serves the traffic. User
can alter according to
their requirements
Two identical production environments work in parallel.
The blue/green deployment strategy will be used with dynamic cloud environments.
There are two physically separate environments. At any time, only one of these environments is live, serving
all of the production traffic.
While new versions of the applications are deployed to the second (blue) environment, the first environment
(green) is serving production traffic.
All Users
USERS Router
O l d V e r s i o n
N e w V e r s i o n
Web Server
Web Server
Database Server
Database Server
Application Server
Application Server

Blue-Green, Red-Black or A/B Deployment Pattern
10
This slide covers the two identical production environments works in parallel
Below shown are the
blue green environment
deployment pattern.
Which user can alter
according to his
requirements.
• One is the currently-running production environment receiving all user traffic
(depicted as Blue).
• The other is a clone of it, but idle (Green).
• Both use the same database back-end and app configuration:
• The new version of the application is deployed in the green environment
& tested for functionality and performance
• Once the testing results are successful, application traffic is routed from
blue to green
• Green then becomes the new production
Currently Running
Clone
User Traffic
Code Version 1 Code Version 2
Load Balancer
User Traffic
Load Balancer

Blue-Green, Red-Black or A/B Deployment Use Case
11
This slide covers how to create blue and green deployment strategy as blue green are two physically separated environments, and can be configured in the Electric Flow environment model
Number Task Name Description
1 DeployShoppingCart
This is another process task similar to what is in the DEV and QA stages that the environment name is parameterized. The
system will automatically switch deployments between the BLUE and GREEN environments
2 CertifyDeployment This is a manual step to review and certify the deployment
3 CompletePostCertificationTasks
This is an automation task to run any post certification tasks such as updating the load balancer and switching the environment
in preparation for the next pipeline run (for example, update the TargetENV parameter)
Listed here are the blue
green strategy deployment
use case i.e.
Modelling of the blue green
environment through these
steps and tasks. User can
alter according to their
requirements.
Creating Four
Environments
(DEV, QA, BLUE,
and GREEN)
Mapping the Environments to the Shopping
Cart Application
Select the Shopping Cart application, and map the application tiers to the corresponding
environment tiers in DEV, QA, BLUE, and GREEN.
Creating a Pipeline with Three Stages
Create a pipeline with three stages called DEV, QA and PROD.
Creating Three Tasks for the PROD stage.
In PROD stage, create three tasks:

This slide covers before
staring and starting steps
for the blue green
deployment. User can
alter according to his
requirements.
Blue-Green, Red-Black or A/B Deployment Use
Case Cont.
In this slide we have covered pipeline for the blue green deployment
Running the Pipeline
Before running the pipeline, the GREEN environment is serving all of the production traffic, and the BLUE environment is
ready to be upgraded to the new software version.
• We have to set Rolling/TargetEnv property to the first environment to which we want to deploy on the project.
• RollingDeploy/TargetEnv will be set to BLUE because the GREEN environment is currently catering to end-user traffic
Before Starting the Deployment,
1. The pipeline will start at the DEV stage and continue to the PROD stage.
2. Once the deployment reaches the PROD stage, the application process task will deploy to the BLUE environment based on the property
value $[/myProject/RollingDeploy/TargetEnv], which was set to BLUE at the beginning of the run.
3. Once the deployment task has completed, there is a manual step to functionally verify the deployment.
4. If there was a need for some automated testing, those tasks can easily be added to the pipeline stage.
5. Once the deployment completes successfully, switch the user traffic to the BLUE servers, and update the RollingDeploy/TargetEnv property
to GREEN.
6. Setting the property value to GREEN will ensure that the next deployment will happen to the GREEN environment while the BLUE environment
serves all of the production traffic.
When the Pipeline Starts:
This slide is 100% editable. Adapt it to your needs and capture your audience's attention. 12

O l d V e r s i o n
Web Server Database Server
Application Server
N e w V e r s i o n
Web Server Database Server
Application Server
Router
USERS
Most Users
95%
Some Users
5%
This slide explains about the working of canary deployment environment
Deployment Strategy -
Canary Deployment
This technique is an advanced variation of the blue/green deployment
one environment is handling the production traffic. During deployment
time, new versions are applied to the second inactive environment similar
to a blue/green deployment.
Once the second environment with the newer version is satisfactorily
tested, a portion of the end-user traffic is diverted to it.
The first environment runs the old production version of the applications
and bears the majority of the traffic while the second environment runs the
new version of the applications and caters to a small portion of the traffic.
This is a way to test the new version with live traffic, and if everything
looks fine, all the traffic can be diverted to the new version, or if there are
issues with the new version, the older version can be kept instead.
In this slide we cover
canary deployment
environment working by
testing new version without
deleting the old one. User
can alter according to their
requirements.
13

Canary Deployment Pattern
14
In this slide we cover phased approach for canary deployment
Majority Infrastructure
User Traffic
Most Users Few Users
All Infrastructure
Code Version 2
User Traffic
Instead of switching
from blue to green in
one step, we use a
PHASED
APPROACH.
Canary deployment is like blue-green, except it’s more risk-averse
› Deploy a new application
code in a small part of the
production infrastructure
› Once the application is
signed off for release, only a
few users are routed to it.
This minimizes any impact.
› No errors reported, the
new version can
gradually roll out to the
rest of the infrastructure
This slide covers phased
approach for canary
deployment, in which new
version roll out to the rest
of the infrastructure when
no error reported. User
their requirements.

15
Canary Deployment
Use Case
This slide shows the canary deployment use, that how application deployed
in subset of servers.
This slide covers that
how canary deployment
is to deploy an
application to a small set
of servers. User can alter
according to his
requirements
The purpose of a canary deployment is to deploy an
application to a small set of servers for validation by a
subset of users.
Once user validation is complete, the application is
rolled out to a larger set of servers.
This is very similar to blue/green deployments where you
can model separate environments and use pipelines to
control deployments to higher-order environments.
The key difference with canary deployments is that part
of the traffic is routed to the environment with the latest
version.

Using an application logic to unlock
new features to specific users and
groups. This logic is removed when the
application goes live for the rest of the
users.
Exposing internal users to the
canary deployment before
allowing external user access;
Basing routing on the source
IP range
Releasing the application in
specific geographic regions;
Routing Techniques:
16
This Slide Shows Various Techniques For Routing New Users
Listed are the routing
techniques for testing the
new versions of the
application. User can
requirements.

Deployment Best Practices
17
This slide explains the best practices to minimize the deployment risks
This slide covers the best
practices for the
deployments techniques
which user can follow before
deployments and can alter
according to their
requirements.
Use standard operating
environments (SOEs)
Ensure environment consistency.
You can use tools like Vagrant
and Packer for development
workstations and servers.
Use a deployment
checklist
An item on the checklist may be to
"backup all databases only after
app services have been stopped"
to prevent data corruption.
Adopt Continuous
Integration (CI)
CI ensures code checked into the
feature branch of a code
repository merges with its main
branch only after it has gone
through a series of dependency
checks, unit and integration tests,
and a successful build.
Adopt Continuous
Delivery (CD)
With CD, the CI-built code artifact
is packaged and always ready to
be deployed in one or more
environments.
Enable automated
rollbacks for
deployments
that fail health checks, whether
due to availability or error rate
issues.

Deployment Strategies Comparisons
18
This slide shows the comparison of deployment strategies on different bases.
Strategy
Zero
Downtime
Real Traffic
Testing
Targeted
Users
Cloud
Cost
Rollback
Duration
Negative
Impact on
User
Complexity of
Setup
Rolling Deployment
The old version is shown in blue & the new version is
shown in green across each server in the cluster
BLUE / GREEN
Version B is released alongside version A, then the
traffic is switched to version B
CANARY
Version B is released to a subset of users, then proceed
to a full rollout
A / B TESTING
Version B is released to a subset of users under specific
condition
Add Text Here
Listed are the routing
techniques for testing the
new versions of the
application. User can
requirements.

Post-Deployment Monitoring (1/2)
19
This slide covers the post deployment monitoring framework
This slide covers
dimensions, area of
focus etc. to monitor
performance after
deployment. User can
requirements.
• Agentless (RUM) – [First]
• Multiple Protocol Analytics
• Synthetic Probes & Robots
• Trans, Path Snapshots
• Bottom Up/ Top Down
• Monitor Cloud Apps
• User-defined Transactions
• URL / Page Definitions
• 8 to 12 high level groups
• Add Text Here
• Add Text Here
• Add Text Here
• Add Text Here
• Add Text Here
• Add Text Here
Area of Focus
• APM Value : 80% comes from the EUE
• Agentless is low risk (Port Mirroring)
o Quick Implementation < 2 Days
• Robots = Availability & low vol. trends
• Better service dependency mappings
o Understanding how network topologies
interact with application architecture
• Change impact assessment
• Meaningful SLAs to the Business
strengthen trust with Business
• Provide early warning trend reports
• Add Text Here
• Add Text Here
• Add Text Here
• Add Text Here
• Add Text Here
• Add Text Here
Potential Benefits
Application
Performance
Management
End User
Experience
Runtime
Application
Architecture
Business
Transactions
Add
Text Here
Add
Text Here
Dimensions

Post-Deployment Monitoring (2/2)
20
This slide covers the post deployments monitoring dashboard to measure performance
This graph/chart is linked to excel, and changes automatically based on data. Just left click on it and select “Edit Data”.
This slide shows the
KPIs and metrices to
measure performance
after deployment. User
their requirements.
6.01%
21.19%
72.79%
0% 20% 40% 60% 80% 100%
Frustrated
Tolerated
Satisfied
0
200
400
600
0%
2%
4%
6%
89.3%
4.9%
3.2%
2.2%
0.4%
401 500 403 400 422 503
HTTP
Failure Codes
10 K Failed Requests
2 % Failure Rate
HTTP Failure Rate
Transaction Throughput
0.5M Requests
Response Time Experience
0.1 sec Apdex Threshold
0.83 Apdex Score
Avg.
Response Time
160.24 ms 0.5 M
Total Requests
10 K
Failed Requests
2 %
Failure Rate
0
50
100
150
200
250
Jan
(12:00
pm)
Feb (6:00
pm)
Mar
(12:00
am)
Apr (6:00
am)
May
(12:00
pm)
Jun (6:00
pm)
Jul (12:00
am)
Aug (6:00
am)
Sep
(12:00
pm)
Oct (6:00
pm)
Nov
(12:00
am)
Dec (6:00
am)
Expressjs
Remote HTTP Calls
Postgres
Rendering
Remote HTTP Calls
86.18 ms from 14 : 15 till 15 : 10
160.24 ms
Overall Avg
7 ms
Expressjs
37.43 ms
Remote HTTP Calls
7.59 ms
Postgres
6 ms
Rendering

Icons Slide for Deployment Strategies
21

Stacked Bar
23
50%
65%
-15%
-9%
40%
50%
-19%
-2%
-30% -20% -10% 0% 10% 20% 30% 40% 50% 60% 70%
This graph/chart is linked to excel, and
changes automatically based on data. Just
left click on it and select “Edit Data”.
Product 01
changes automatically based on data. Just
left click on it and select “Edit Data”.
Product 02

Clustered Bar Chart
24
15
25
10
25
50
20
changes automatically based on data.
Just left click on it and select “Edit Data”.
Product 01
changes automatically based on data.
Just left click on it and select “Edit Data”.
Product 02

Puzzle
25
This slide is 100% editable. Adapt
it to your needs and capture your
Text Here
Text Here
Text Here
Text Here
Text Here
Text Here

26
This slide is 100% editable. Adapt it to your needs and
capture your audience's attention.
Target Audiences
Premium Services
Value Clients
About Us

27
Mission
Vision
Goal
Our Mission

Timeline
28
Start
End
This slide is 100%
editable. Adapt it to your
needs and capture your
2015
This slide is 100%
2017
This slide is 100%
2019
This slide is 100%
2016
This slide is 100%
2018
This slide is 100%
2020

29
Text Here
01
Text Here
02
Text Here
03
Text Here
04
Our Target

Financial
30
1.3
Billion
Text Here
532 Million
Text Here
10
Million
Text Here

31
Thank You
Address
# street number, city, state
Email Address
email address123@gmail.com
Contact Number
0123456789

Deployment Strategies Powerpoint Presentation Slides

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Deployment Strategies Powerpoint Presentation Slides

Similar to Deployment Strategies Powerpoint Presentation Slides (20)

More from SlideTeam

More from SlideTeam (20)

Recently uploaded

Recently uploaded (20)

Deployment Strategies Powerpoint Presentation Slides