Lect_8:

Application
Deployment
Semester I 2022/23
SKR4307
1. Challenges of Modern Apps
• Often distributed and cloud-based.
 Scale elastically to meet demand and are more resilient
to failure

• Almost always have frequent deployments.

 May undergo several changes within a month (even
deployed to production multiple times a day)

• Use microservice architectures – several

components work together to deliver full
functionality.
 Can be different release cycles for different components,
but they all have to work together seamlessly.
… cont.
• Increased number of moving parts
mean more chances for something to
go wrong.
 Multiple development teams making
changes throughout the codebase – can
be difficult to determine the root cause of
a problem when one inevitably occurs

• The abstraction of the infrastructure

layer – now being considered code.
 Deployment of a new application may
require the deployment of new
infrastructure code as well
2. Deployment Strategies –
Modern Apps
• The biggest change to software development –
frequency of deployments
 Teams deploy releases to production earlier (and more
often)
 Months or years-long release cycles – rare (especially
among those building pure software products)

• Using a service-oriented architecture (SOA)

and microservices approach – developers can
design a code base to be modular
 Write and deploy changes to different parts of the code
base simultaneously
3. Deployment Cycles

• The benefits of shorter deployment cycles are clear:

 Time-to-market is reduced
 Customers get product value in less time
 Customer feedback also flows back into the product team faster – the team
can iterate on features and fix problems faster
 Overall developer morale goes up
3.1 Deploying Mobile Apps

• Test app on a simulator or on an actual device to assess the behaviour

and ease of use – before can publish for distribution to end users
 Deploying an iOS application bundle (.ipa and .app files) or
 Android application package (.apk) file to the platform-appropriate device or
simulator
• Releasing a native mobile app requires submitting the app to the app
stores – e.g., developer account
 Apple App Store for iOS apps
 Google Play Store for Android apps.
… cont.

• Released app in the app store

requires preparing metadata
including:
 Your app’s title
 Description
 Category
 Keywords
 Launch icon
 App store screenshots
4. Deployment Strategies
 4.1 Big Bang strategy
• Update whole or large parts of an
application in one fell swoop
 Strategy goes back to the days when software
was released on physical media and installed
by the customer
 Required to conduct extensive development
and testing before release, often associated
with the "waterfall model" of large sequential
releases
• Suitable for non-production
systems (e.g., re-creating a
development environment) or
vendor-packaged solutions like
desktop applications
… cont.

• Modern app – not suitable for big bang – (makes big bang
approach slower and less agile for modern teams)
• Time consuming and costly (even low risk)
• Characteristics:
 Major pieces packaged in one deployment
 Largely or completely replacing an existing software version with a new
one
 Resulting in long development and testing cycle
 Minimal chance of failure as rollbacks may be impossible or impractical
 Completion times are usually long and can take multiple teams’ efforts
 Requiring action from clients to update the client-side installation
4.2 Rolling/phased/step
deployment
• Better than big bang – minimize many of
the associated risks, including user-
facing downtime without easy rollbacks
• An application’s new version gradually
replaces the old one
 The actual deployment happens over a
period
 NEW and OLD versions - coexist without
affecting functionality or user experience
 Process makes it easier to roll back any new
component incompatible with the old
components
 … cont.
• An application suite upgrade – an
example of a rolling deployment
• If 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
 If there is a compatibility issue for one of the
apps, the older image can recreate the container

• New and old versions of the suite’s

applications coexist until every app is
upgraded
4.3 Blue-green, Red-black
or A/B deployment
• A fail-safe process
• TWO identical production
environments work in parallel
 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
Once the testing results are successful, The new version of the application is
application traffic is routed from blue to deployed in the green environment and
green. Green then becomes the new tested for functionality and performance.
production.

If there is an issue after green becomes

live, traffic can be routed back to blue
 4.4 Canary
Deployment
• Like blue-green – except it’s more
risk-averse (reluctant to risk)
 Instead of switching from blue to green
in one step, use a phased approach
• 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
– minimizes any impact
• With no errors reported, the new
version can gradually roll out to the
rest of the infrastructure
… cont.

• Main challenge – to devise a way

to route some users to the new
application
• Also, some applications may
always need the same group of
users for testing, while others may
require a different group every time
… cont.
• Route new users – several techniques:
i. Exposing internal users to the canary
deployment before allowing external
user access
ii. Basing routing on the source IP range.
iii. Releasing the application in specific
geographic regions
iv. Using an application logic to unlock
new features to specific users and
groups
• Logic is removed when the
application goes live for the rest of
the users
5. Best Practices
i. Use a deployment checklist
ii. Adopt Continuous Integration (CI) and Continuous Delivery
(CD)
iii. Use standard operating environments (SOEs) – ensure
environment consistency
iv. Use Build Automation tools to automate environment builds
v. Use configuration management tools – e.g., Puppet, Chef, or
Ansible in target servers to automatically apply OS settings,
apply patches, or install software
vi. Use communication channels – e.g., Slack for automated
notifications of unsuccessful builds and application failures
vii. Create a process for alerting the responsible team on
deployments that fail
viii. Enable automated rollbacks for deployments that fail health
checks, whether due to availability or error rate issues
5.1 Post-deployment Monitoring
(e.g., Rollbar – error monitoring)
• Monitoring for issues occurring immediately after
a deployment
• Important as planning and executing a perfect
deployment
• Application performance monitoring (APM) tool
– help team monitor critical performance metrics
including server response times after deployments.
• Changes in application or system architecture can
dramatically affect application performance
• An error-monitoring solution like Rollbar is
equally essential
• Quickly notify team of new or reactivated errors from a
deployment that could uncover important bugs
requiring immediate attention
… cont.
• Without an error monitoring tool:
 Bugs may never have been discovered
 Negative customer experience can lead
to satisfaction issues over time, or worse,
prevent business transactions from taking
place now
• Error monitoring tool – creates a
shared visibility of all the post-
deployment issues among Operations /
DevOps (OpDev) teams and
developers
• Shared understanding allows the teams to
be more collaborative and responsive
Bugsnag: Error Monitoring & Reporting Tool for App Stability:
• https://www.bugsnag.com/
Sentry: Application Monitoring and Error Tracking Softw
are:
• https://sentry.io/
Airbrake: Full-stack Application Monitoring Software:
• https://airbrake.io/
5.2 App Licensing

• Big business
• Apps have become big brands,
generating revenues from
licensed merchandise. (e.g.,
Angry Birds, which has over
200 licensing partners)
• A good precaution with a free
app – help maintain ownership
of the app’s concept
 https://developer.android.com/google/play/licensing
• License term options:
1. Perpetual license: does not expire.
2. Non-perpetual license: must be renewed annually.

• Can’t change app’s license terms once the app is approved.

• Releasing an approved app under a different license term requires
submitting another app under a new name (title).
5.3 With or Without Licensing
1. Best case scenario with licensing: A user buys your app and copies the .apk file
to another user’s device. The other user hasn’t paid for your app. The other user
tries to run the app but can’t run it because of the licensing restrictions.
2. Worst case scenario without licensing: A user buys your app and copies
the .apk file to a file-sharing website. People download and install your .apk file
and run the code for free. (Ooo! That’s bad!)
3. Worst case scenario with licensing: A user buys your app, cracks the licensing,
and copies the .apk file to a file-sharing website. People download and install the
cracked version of your .apk file and run the code for free. (That’s bad, too.)
4. Best case scenario without licensing: No one ever tries to steal your app. Or, if
someone steals your app, the additional distribution of your app works to your
advantage.
5.4 Code Implements – Policies

1. Strict policy: Device asks the Google Play server for approval to
run the app.
 If the user tries to launch app when the device has no connectivity, the user is
out of luck. Life’s tough.
2. Server-managed policy: Device stores a copy of the user’s license.
 Uses the copy when network connectivity is unavailable. The license is
difficult– license keeps track of trial periods, expiration dates, and other stuff.
This is the default policy, and it’s the policy that Google highly recommends.
3. Custom policy: Own policy with Java code in app.
 Very sensitive situations, this choice might be the best.
5.5 Publish the app

1. Publish an App on Google Play: A Step-by-Step

Guide:
https://medium.com/@the_manifest/how-to-publish-a
n-app-on-google-play-a-step-by-step-guide-80f9f533e
370

2. App To the App Store USING APP STORE

CONNECT:
https://codewithchris.com/submit-your-app-to-the-app
-store/

3. Build and release an Android app:

https://flutter.dev/docs/deployment/android
5.6 Mobile app versioning: A numbers
game

• https://medium.com/@daptronic/mobile-app-ve
rsioning-a-numbers-game-f1ea9dbd1ded
• Versioning an Android app [How & Why]:
https://droidmentor.com/versioning-an-android-
app-how-and-why/

Use App Versioning

References

 Win-Win Deployment Strategies for

Modern Apps:
https://rollbar.com/blog/deployment-strate
gies/
 Mobile App Development Process: Step-
by-Step Guide [2021]:
https://www.invonto.com/insights/mobile-
app-development-process/