Development Workflow

This SOP describes the day-to-day development workflow, including branching strategy, code standards, and collaboration practices. It is part of the Inkblot SOP Library — a reference set of SOPs that are activated selectively as needed.

Overview

The development cycle at Inkblot follows a feature-branch workflow built on GitHub, with deployments handled through Vercel. Projects are built with Astro (frontend) and Sanity (CMS), deployed to Vercel. Development work is tracked in ClickUp, and tasks move through defined statuses from In Development through to In Review.

Branching Strategy

Inkblot uses a feature branch workflow:

• main — Production branch. Deployed automatically to the live site via Vercel. Only merged into via pull request.
• develop (when applicable) — Integration branch for staging. Used on larger projects to collect features before a production release.
• feature/<description> — Feature branches for individual tasks or features. Branched from main (or develop). Named descriptively, e.g., feature/hero-section, feature/contact-form.
• fix/<description> — Bug fix branches. Named descriptively, e.g., fix/mobile-nav-overlap.

Guidelines:

• Always branch from the latest version of the base branch
• Keep branches focused — one feature or fix per branch
• Delete branches after merging
• Never commit directly to main

Code Standards

• Framework: Astro with component-based architecture
• Styling: Follow project-specific conventions (Tailwind CSS, scoped styles, or CSS modules as defined per project)
• TypeScript: Preferred where supported; use strict typing for Sanity schema definitions
• Naming: Use kebab-case for file names, PascalCase for component names, camelCase for variables and functions
• File structure: Follow the established project structure — keep components, layouts, pages, and utilities in their designated directories
• Formatting: Use Prettier for consistent formatting; ESLint for code quality
• Comments: Write meaningful comments for complex logic; avoid obvious comments

Pull Requests

All code changes go through a pull request (PR) process:

1. Create a PR — Push your feature branch to GitHub and open a PR against the target branch
2. PR description — Include a summary of changes, screenshots (for visual changes), and any testing notes
3. Request review — Assign Jonathan (Web Dev Lead) as reviewer; tag additional reviewers if relevant
4. Code review — Reviewer checks for code quality, adherence to standards, performance, and correctness
5. Address feedback — Make requested changes and push updates to the same branch
6. Approval & merge — Once approved, the PR is merged (squash merge preferred for clean history)
7. Vercel preview — Each PR automatically gets a Vercel preview deployment for visual testing

Communication

• Daily check-ins — The development team stays in sync through regular updates, either via standup meetings or async Slack updates
• Blockers — If you are blocked, raise it immediately in Slack or ClickUp rather than waiting for the next meeting
• ClickUp updates — Keep your task statuses current. Move tasks through statuses as work progresses so the team has visibility
• Time tracking — Log time against tasks in ClickUp for project tracking and billing

Owner

Jonathan de Kock (Founder & CEO / Web Dev Lead) owns the development workflow, including code standards, branching strategy, and the pull request process.