Embracing the Continuous Delivery Philosophy for Software Development by developing Auto Updating Applications

1. Auto Updating Applications
Embracing the Continuous Delivery
Philosophy for Software Development

2. Continuous Delivery
It’s a Software Development practice wherein we
use techniques such as Automated Testing,
Continuous Integration and Continuous
Deployment to :
1.
Achieve High standards
2.
Easily Package and Deploy builds to Test
Environments.
End Users
3.
Ability to rapidly, reliably and repeatedly push
out enhancements and bug fixes to customers
at low risk and with minimal manual overhead
Having an inbuilt mechanism to update Applications at user’s end is most
Critical to achieve Continuous Delivery BUT often most neglected.

3. Auto Updating Applications
An Auto Updating Application can be simply described as a software which is able to Update itself with
minimum intervention from the End User.
We may have already put all the effort to setup a source control system, a build server, an automated versioning process
and all are configured so that we can release a new Build with the press of a button.
BUT how do we get the new build version to the end users?
This is where an automatically updating application comes into picture.
If we design an application, which is able to query a server periodically (or on user action) for available updates and is
able to update itself to a newer version, we save a lot of time, effort and money invested by IT support to distribute
application updates.

4. Who does it? Who doesn’t?
Who Does it?
•
Almost all commercially available applications are able to automatically update themselves.
•
Popular application are Google Chrome, MS Office, Adobe reader etc.
Who Does NOT?
•
Enterprises using application management tools like TIVOLI for software distribution (inside their organization).
•
A number of applications developed by enterprise Service Provider companies, for apparently no valid/relevant
reason(s).

5. Enterprise/Commercial Application Types
Web Applications (No need for Auto updating mechanism on Client Side)
Internet
•
Deployed on a Central Web/application server.
•
The end user needs to be ‘connected’ to a network to access it.
•
Runs inside using a browser (Chrome, IE, Firefox).
Desktop Applications
•
Runs as Desktop application on the end users system
•
May or may NOT need to connect to a network
•
Absolutely essential to have Auto Updating mechanism
The Desktop application
needs to be Installed on
the End Users’ system.

6. Benefits to Enterprises
Considering and developing an Auto Update strategy should be a part of the very first Design of a Desktop/Windows
Application. Its brings along with it a lot of benefits in the long run to the Enterprise:
1. Reduced cost of Deployment : Enterprises would save on Licensing costs involved in procuring tools like IBM’s
TIVOLI used for managing software distribution inside their organization.
2. Faster and Reliable releases : Since pushing updates to the End users does not require any manual intervention
from an IT support executive or using distribution medias such as CD/DVDs, the updates can happen whenever the
device is connected to a network, hence they are quicker and hassle free.
3. Reduced cost of IT Support infrastructure : Deploying a new version of the application does not require any
specialized skill, since it is handled by the application itself. This in turn results in reduced cost of Onsite production
support.

7. Auto Update Use Case Scenario
Suppose we have a scenario wherein we have End users using our application at geographically remote locations on various devices.
In such a scenario Auto Update comes in handy when we have to update and maintain Devices running different versions of the application.
Remote End User Workplace
Deployment Server
Publish
Project Team
 Code & Bug Fixing
 Unit & Integration Test
 New version of build
provided
New
Version
1.00.00
2.00.00
New
Version
2.00.00
3.00.00
Old
Version
New
Version
3.00.00
Updates
Old
Version
Old
Version
Check For Update
Update Available
NA
Release Team
 Version Maintenance
 Software Packaging
Central
DataBase
 Maintain an audit of versions
published for various devices.
 Publish multiple versions
of the Build
 Serve different versions
to different devices
<Devices are Updated based on their Current app version>

8. Auto Update Use Case Scenario…continued
Auto Update Workflow
 New version of the application Build provided to the Release/Build Team by Project Team.
 The Release Team publishes the Updated version of the Build on the Deployment Server for specific Devices.
 The User (in their Workplaces), clicks on “Check For Updates” from within the Application.
 If an update is published for that particular device, it is downloaded and installed automatically on the User’s device.
 After the update completes, the application restarts automatically and the can just start using the new version.
 The Application informs the user if “No Updates” are available for a particular Device.
 We can publish different versions of the Build for different devices. So whenever a device requests for an update, the
Update Service on the Deployment server will check its DeviceID and serve it with the appropriate version.

9. “You Have 2 Update(s) Available..”
Sounds Familiar!!
Auto Updating
Applications
Having such a provision inbuilt into our
applications can prove to be a boon to
any enterprise.
Refer the link below to learn more.
Find out more about implementing Auto Update
(Click the above link in Slide show mode)