Skip to content
A·ALMOUSAWebsites & software systems
English
Let’s talk
Explore the website
Discuss your project

contact@almousa.dev

DELIVERY PRACTICE / FROM CODE TO OPERATIONS

Engineering and operations

Our work includes review by another person and a GitHub Actions approach to tests and builds. This page describes our delivery and operations policy. Each control is implemented and verified within the project’s agreed scope; its inclusion here does not establish that every setting is enabled for every project.

From Code Change to Production

  1. Git

    Track changes, give each change a clear purpose, and manage it through a reviewable pull request.

  2. Code Review

    Have another person review the change. Merging requires approval, and subsequent modifications require renewed review.

  3. CI

    Run automated checks through GitHub Actions and require mandatory checks to pass before merging.

  4. Tests

    Verify the behavior affected by the change and add tests appropriate to its risks and scope.

  5. Build

    Produce an identifiable, traceable release after the required checks pass.

  6. Staging

    Test the release in an environment separate from production, using test data and separate secrets.

  7. Acceptance

    The team’s technical lead approves technical readiness, and the client or their representative approves conformity with requirements, according to the size of the change. Document acceptance.

  8. Production

    Deploy the approved release using defined permissions, and block deployment if a mandatory gate fails.

  9. Monitoring

    Check service health after deployment and monitor availability, performance, and errors internally.

These are logical stages; tests and builds may run within CI. Acceptance gates and permissions are defined for each project before deployment.

The following controls are approved policy to implement and verify within the project agreement. Actual operating responsibilities are those assigned in the operations or support contract.

Logging

Logs are limited to information needed to diagnose failures and support operations. Sensitive data is redacted, and access is restricted to authorized people. Retention periods are defined according to operational needs, with automatic deletion when those periods expire. Passwords and access keys must not be logged, and sensitive request contents must not be logged wholesale.

Error Tracking

Errors are collected and prioritized according to their impact on the service, with alerts that help the designated person investigate and follow up. Data is redacted before it is sent to the tracking tool, and diagnostics must not become unnecessary collection of visitor data.

Monitoring

The approved policy calls for automated monitoring of availability, performance, and errors, with a designated person responsible for receiving and following up on alerts. The operations or support agreement defines coverage hours, response times, and responsibilities. This policy does not promise around-the-clock human monitoring or a specific availability percentage.

Backups

The approved policy calls for automated, encrypted backups isolated from the primary system, with a defined retention period and periodic restoration tests. The contract identifies who is responsible for backups, follow-up, and restoration; responsibility does not automatically pass to the developer simply because they built the website.

Backup scope is based on the data that actually exists: website files, assets, configuration needed for recovery, and changing data, if any. A successful backup job alone is insufficient; restorability must be verified. Backup frequency, acceptable data loss, and recovery time are determined by service needs and the agreement, without unapproved numerical commitments.

Rollback

Retain a stable release and prepare a tested rollback procedure, with service health checks after deployment and after rollback. Database changes, if any, require a separate plan to protect data and verify compatibility. Restoring application files must not be assumed to restore data automatically.

Secrets Management

Service passwords and API keys are stored in a dedicated secrets manager. Test and production secrets are separated, and access is restricted according to need. Secrets must not appear in source code, public frontend files, or logs. They are revoked and replaced when exposure is suspected, and access permissions are reviewed.

CONTINUE EXPLORING

Security within software developmentProject process and handoverOur team and delivery approachPrivacy and data