An independent project · Linux and DevOps
A web platform on Linux. From release to operations.
A website with public pages and an active community needed to become a single platform. The challenge was to bring the new interface online while retaining existing accounts, content and access. This case study covers the documented September 2026 release and the checks carried out alongside it.
The context
One unified platform.
This independent web platform combines editorial content with a members-only area. The public pages and community previously had separate user journeys. The new platform brought them together in one Django application, with shared navigation and user recognition. The site's name and identifying references are omitted.
Illustrative diagram
The Linux release workflow.
An illustration of the documented work: preparing recovery, releasing the unified platform and running checks. It does not show the production topology. The backup restore was tested in isolation; rollback to the previous code was prepared.
Open the full-resolution diagramThe constraint
Preserve what was already there.
The main constraint was the existing data. A new interface could not introduce test accounts, replace credentials or lose content. The transition also needed to handle existing sessions and retain a previous version to return to, without deleting activity recorded after the release.
The release, step by step
The documented work.
Separate development from production
Automated checks used temporary databases and simulated email delivery. The release transferred application code and assets, excluding demonstration data. The previous version was retained as a rollback point.
Prepare and verify recovery
An encrypted backup was verified before publication. The project records also document a completed restore into a temporary database, with checksum verification and media extraction, without touching production. An encrypted off-site copy was also transferred and checked.
Bring the unified platform online
The transition kept the existing database. Comparing aggregate data fingerprints before and after the release confirmed that the checked data had been preserved. Session handling was adapted to the shared platform, and the web server was reloaded after its configuration had been checked.
Test the release and retain a way back
Public acceptance checks covered HTTPS responses, layouts and browser errors. A procedure was prepared to restore the previous code and configuration without rolling back the database, preserving content added after the release.
Project acceptance checks
The recorded checks.
Documented project checks, during preparation and at release.
- Before-and-after release comparisons
- Data preserved
Aggregate fingerprints matched for the existing data that was checked; no demonstration data was imported.
- Public HTTPS acceptance checks
- 13 pages
Checked with two browser engines at five viewport widths, from 320 to 1440 pixels: HTTP 200 responses, with no overflow or JavaScript/CSP errors detected.
- In a temporary environment
- Restore tested
Backup recovery was completed in isolation, checking checksums, the database and media without changing production.
Scope of the results
What the checks cover.
The acceptance checks describe the state observed at release. Backup recovery was tested in a temporary environment; the procedure for returning to the previous code was prepared for possible later use. The documented checks cover data integrity, application behaviour and the ability to recover.
Beyond publication
What the work leaves in place.
The work did not end when the pages went live. It delivered a unified platform, data checks, verified recovery and a documented procedure for returning to the previous code. These are considerations to address together when updating a service that people already use.