Deployment

This SOP covers how code and content are deployed to staging and production environments. It is part of the Inkblot SOP Library — a reference set of SOPs that are activated selectively as needed.

Overview

Inkblot uses Vercel for hosting and deployment, connected to GitHub repositories. Deployments are largely automated through Git-based workflows — merging to the correct branch triggers a build and deploy. The process is designed to be safe, repeatable, and easy to roll back if needed.

Environments

Environment	Branch	Purpose	URL Pattern
Local	Any	Development and testing on individual machines	localhost:4321 (Astro default)
Preview	PR branches	Automatic Vercel preview for each pull request; used for QA and client review	project-branch.vercel.app
Staging	develop (if used)	Integration testing for larger projects before production release	Project-specific staging URL
Production	main	Live client-facing site	Client’s custom domain

Steps

1. Pre-Deploy Checklist

Before deploying to production, confirm:

• All pull requests for the release are merged
• Code review has been completed and approved
• QA testing has passed on the preview or staging environment (see QA & Review SOP)
• Client has signed off on the work
• Environment variables are set correctly in Vercel for the production environment
• Sanity dataset is configured and content is ready (if applicable)
• DNS is configured correctly (for new site launches)
• Analytics and tracking codes are in place (if required)

2. Deploy to Staging

• For projects using a develop branch: merge feature branches into develop via PR
• Vercel automatically builds and deploys the staging environment
• Share the staging URL with the team for integration testing
• For smaller projects without a staging branch: use the Vercel preview deployment from the PR as the staging step

3. Staging Verification

• The developer verifies the staging deployment works correctly
• Adriana or the project lead confirms with the client if needed
• Check that:
  • All pages load correctly
  • CMS content from Sanity renders properly
  • Forms and interactive features work
  • No broken links or missing assets
  • Performance is acceptable

4. Deploy to Production

• Merge the approved PR (or develop branch) into main
• Vercel automatically triggers a production build and deploy
• Monitor the Vercel dashboard for build success
• Once deployed, verify the live URL is serving the new version

5. Post-Deploy Verification

After production deployment:

• Smoke test — Visit the live site and check critical pages and functionality
• Check forms — Submit test entries to verify forms are working and sending to the correct destination
• Verify CMS — Confirm content can be edited and published in Sanity Studio and appears correctly on the live site
• Check analytics — Verify tracking is firing correctly
• Monitor for errors — Watch the Vercel deployment logs and browser console for any issues in the first hour
• Update ClickUp — Move the project status (e.g., from “In Review” to “Live” or “Live - Pending Changes”)

Rollback Procedure

If something goes wrong after a production deployment:

1. Immediate rollback — Use Vercel’s instant rollback feature to revert to the previous deployment. This can be done from the Vercel dashboard without needing to touch code.
2. Git revert — If a code-level fix is needed, create a revert commit on main and push. Vercel will automatically deploy the reverted code.
3. Communicate — Notify the team in Slack about the rollback and the issue that caused it.
4. Post-mortem — For significant incidents, document what went wrong and how to prevent it in the future.

Owner

Jonathan de Kock (Web Dev Lead) owns the deployment process and is responsible for production releases. Vercel dashboard access is managed by Jonathan.