We manage all website and application source code via Git repositories, maintaining strict separation between development, staging, and production environments. Every change is tracked, reviewed, and deployed deterministically to prevent regressions and maintain an immutable technical audit log.
Branching structure and repository architecture
All digital build projects operate under a structured Git branching model managed directly by our Technology department. We do not edit live servers, nor do we run ad-hoc file transfers on production environments.
* Production branch (`main`): Reflects the exact, current state of your live website or application. Direct commits to this branch are blocked at the repository level. Updates enter production solely through peer-reviewed pull requests from staging. * Staging branch (`staging`): Powers your staging preview URL. New features, layout adjustments, and bug fixes are aggregated here for internal quality assurance and client sign-off. * Feature and hotfix branches: Isolated branches spun up for discrete tasks. Developers implement, test, and validate changes locally before opening a pull request into staging.
This structure ensures unstable code is never exposed to public traffic or search engine crawlers.
How revisions move to production
Moving an adjustment from request to release follows an exact operational pipeline:
1. Request logging: You log your adjustment, feature addition, or defect report via the Ask Xylo chat on this portal. Operations & Client Services categorises the request and logs it with the Technology department. 2. Branching and build: A developer branches from the current production codebase, writes the necessary code, and tests locally. 3. Staging deployment: The feature branch merges into staging. Automated continuous integration checks run to verify syntax, dependencies, and build integrity. The staging site rebuilds automatically. 4. Review and sign-off: You receive a notification to inspect the staging URL. Any visual, functional, or copy amends must be flagged at this stage. 5. Production release: Once written sign-off is logged, the pull request merges into `main`. The deployment pipeline pushes the build to the live server, executes any necessary cache purges, and verifies uptime.
Client access and repository ownership
For active bespoke development retainers and turnkey packages, repositories are hosted within the studio's managed infrastructure. This guarantees that our deployment webhooks, security audits, and continuous integration pipelines operate without external configuration drift.
If your agreement includes full code handover or external hosting on your own repository (such as GitHub, GitLab, or Bitbucket), the following rules apply:
* Read-only access during development: Clients may be granted read-only access to inspect commit histories, release tags, and documentation. * Transfer upon project completion: Repository ownership or mirror pushes to client infrastructure occur only after project sign-off and final payment settlement. Deposits are non-refundable once your production slot is held. Before work begins, sums not yet earned are refunded pro rata; after work begins, completed work and booked time are charged. Defects are fixed free of charge within the acceptance window. The full terms are on the Refund Policy page of the main site. * Third-party intervention: If an external party, internal developer, or client pushes code directly to a connected repository without coordination with our Technology department, deployment pipelines will be frozen until code review takes place.
Schedules, timings, and working hours
Deployments follow our studio operating schedule: Monday to Thursday, 09:00 to 17:00 GMT.
* Routine releases: Staging deployments occur throughout working days as tickets clear development. Live production releases are scheduled between 10:00 and 15:00 GMT, Monday to Thursday, ensuring our engineers are online to monitor post-deployment telemetry. * No Friday releases: We do not execute production deployments on Fridays or outside working hours, preventing unmonitored production incidents over the weekend. * Response windows: Routine support tickets receive a first reply within 24 hours. Scope changes or feature additions requiring new architecture receive a bespoke quote within 48 hours of a complete brief, unless the work is covered under our packages page.
Failure handling and rollbacks
Version control provides an immediate recovery mechanism should unexpected behaviour occur on the live site:
* Production rollbacks: If an uncaught critical bug appears after a release, our Technology department rolls back the live environment to the previous commit tag. This takes minutes and restores the known stable state. * Post-mortem triage: The faulty code is pulled back onto a diagnosis branch. The root cause is identified, rectified, and redeployed back through the standard staging pipeline before production is reattempted. * Data considerations: While version control protects application code, database migrations are handled separately. Schema migrations and database snapshots are taken prior to structural code merges to prevent data loss.
Version control checklist
Keep the following operational rules in mind when working with us on web and app builds:
* Log everything centrally: Submit all technical requests through Ask Xylo; never send ad-hoc code snippets across unstructured communication channels. * Verify on staging first: Inspect and approve changes exclusively on your staging environment before requesting a production merge. * Preserve the schedule: Plan release requests within our operational window (Monday to Thursday, 09:00–17:00 GMT) to allow proper testing and deployment buffer. * Protect repository permissions: Do not add third-party developers or integrations to live environments without prior written sign-off from the Technology department.