An independent project · DevOps
A DevOps project. Automated testing and release.
Updating an application that people already use requires repeatable checks, from reproducing defects to verification after release. This article examines the same independent project covered in the Linux case study: a later revision, documented in September 2026, focused on testing and releasing fixes.
The context
An application to update
The platform was already in production. A review had identified problems with content previews, date handling and the visibility of pages associated with inactive accounts. Those behaviours needed to be corrected without breaking the rest of the application, including sign-in, existing data and older routes that were still supported.
Illustrative diagram
From regression tests to public release checks.
An illustration of a revision of the same independent project described in the Linux case study, not a second client. It shows a local procedure, not a topology or cloud pipeline. Email and network access were simulated in tests; HTTPS acceptance checks were separate and automatic recovery was prepared.
Open the full-resolution diagramThe constraint
Reproduce before fixing
The first step was to turn observed defects into repeatable checks. The problematic cases were reproduced on test databases before the fixes. The checks then needed to cover both the changed behaviour and related permissions and workflows, without creating test content in production.
The release, step by step
From regressions to release
Bring the checks into one command
A local procedure coordinated code analysis, migration checks, application tests and browser tests. It also checked dependencies, shell procedures and coverage. After the final fix, the full suite was rerun from the beginning and passed.
Verify database constraints
The regular suite used temporary databases. A PostgreSQL-specific check, skipped on SQLite, was verified alongside other tests on an isolated PostgreSQL 16 instance. The instance used a private socket; afterwards, the temporary service was stopped and the dummy data removed.
Prepare a separate release
The release used a versioned directory and a dedicated Python environment, with dependencies installed using lockfile hash verification. An encrypted backup preceded publication. The procedure retained previous versions and included a return to the previous code if startup or a health check failed.
Check after publication
Only the application service was restarted. Comparing aggregate data fingerprints before and after release confirmed that the checked data had been preserved. Public acceptance checks then verified HTTPS pages, layouts and browser behaviour. The releases needed for recovery remained available.
Project acceptance checks
Documented results
The following figures come from the acceptance checks recorded in September 2026.
- Documented coverage
- 92.7%
The suite reached all 355 application functions in the inventory. Coverage describes the paths checked; it does not guarantee the absence of bugs.
- On isolated PostgreSQL
- 54 tests
Passed on a temporary instance separate from production, which was then stopped and its dummy data removed.
- Before-and-after comparisons
- Verified release
Aggregate fingerprints of the existing data that was checked matched after the fixes were published.
Scope of the results
What the checks cover.
The documented automation is a local verification procedure. Email, external authentication and the public network were simulated in the deterministic suite; HTTPS acceptance checks were separate. Deployment and recovery procedures were checked for syntax and safeguards. The release is documented as completed; automatic rollback to the previous version was prepared.
Beyond publication
A verifiable update
The result is a repeatable path: reproduce the problem, verify the fix in isolation, publish an identifiable version and check the service. The documentation connects the changes to the tests performed and the recovery options.
The author
Eddy Boscolo.
For over 17 years, I have worked with IT infrastructure. My work covers AWS and Azure architecture, Linux administration and automation with Terraform, Ansible, Docker and Kubernetes, alongside technical teams and project managers.
Based in Vicenza, I work with businesses across Veneto and remotely throughout Italy.