Development
Changes are written and tried on a development computer, away from the application visitors use.
How it works
Behind the software.
Everything connected.
Follow the code from a development computer to a running application. See how the server, monitoring and backups work together.
01 / 05Release an update
Build away from the live system.
Write and try a change on a development computer. Visitors continue using the existing application.
The pieces, explained
A system has a life
beyond launch.
This is a simplified example. The exact services, backup schedule and recovery plan depend on the application.
Version history
A shared source repository stores named versions of the code. A push sends changes here; it does not by itself change the live application.
Release checks
Tests and a build check the proposed change. A reviewed release can then be sent to the server. A failed check keeps it from moving forward.
Virtual server
A virtual private server provides the computing resources that run the application. Access rules, process supervision and system updates help keep it managed.
Visitors
A browser sends an encrypted request to the application. The server checks access, performs the requested work and returns a response.
Monitoring
Health checks, resource measurements and logs help reveal problems. Alerts prompt investigation; maintenance and updates address the underlying cause.
Application data
The application reads and writes its records and files here. These change separately from the code, so rolling back a release is not the same as restoring data.
Separate backups
Selected data and configuration are copied to separate storage. Multiple recovery points help protect against loss; a copy on the same server is not enough.
Recovery test
A backup is restored in an isolated environment and checked for usability. Recovery planning includes both the application and its data.