A successful deployment should mean more than a page returning successfully. When a change touches customers, licences or orders, we also need evidence that existing data remained intact. ParitLAB uses several checks to separate code delivery from data integrity.
Identify data that must remain unchanged
Before deployment we select relevant tables such as users, projects, licences, orders and permission assignments. Rows are read in a deterministic primary-key order, counted and serialised into a SHA-256 hash. Ordering matters because the same rows in a different sequence produce a different hash even when no value changed.
Back up code and data separately
Existing PHP, CSS and JavaScript files go into a timestamped backup directory. A database snapshot is stored separately outside the public web root. This preserves both the code that ran before deployment and the state of the data before migration.
Additive schema reduces the impact area
The manager feature adds tables and columns with safe defaults instead of replacing customer storage. Trial and download permissions begin at zero, so a deployment cannot expose a product automatically. Existing code can also continue reading core records during a staged transition.
Upload through a staging name
Each new file is uploaded under a temporary name. Its size and hash are verified before an atomic rename replaces the live file. Immediately before replacement, the deployer checks that the production file has not changed since the operation began.
Verify after migration and delivery
After the new code creates its schema, the original tables are queried again in the same way. An unexpected count or hash change stops the operation. New columns are checked separately for existence and safe default values. HTTP status, unauthenticated redirects and browser assets are then checked.
What a hash can and cannot prove
Matching hashes prove that the selected data has the same values and order. They do not prove that every new business rule works. Permission tests and direct page checks remain necessary. Likewise, a passing interface test cannot prove that every database row survived. The two forms of evidence answer different questions.
A compact deployment checklist
- Lint and test before connecting to production.
- Back up every file that will change.
- Record counts and hashes for important data.
- Use additive migrations with safe defaults.
- Upload to a staging name and rename.
- Recheck data and main routes after deployment.