Testing CaseMark Apps

CaseMark operates and maintains a variety of apps with unique requirements and testing environments.

For our three main, core repositories - C3 (CaseMark for Legal Teams), Polaris (cm-cr-v2), and case.dev (casedotdev-mono) we have protections in place to make sure code is properly tested before merging anything into main branch (which is the default branch for all repos here).

For SOC2 compliance, we are required to put a human approval for all code merged into main branch for any repository that touches customer data.

This is not always the case. We have many internal repos that DO NOT NEED this requirement, so many repos are unprotected and we can branch off and directly make PRs into main.

All of these projects run on vercel - which automatically creates a preview branch deployment for any branch pushed up to github. This is invaluable for testing changes to things like UI and basic API changes.

*When a user wants to test a change to some UI/frontend stuff, they can test it directly on the preview branch deployment. This will get commented on in the github PR discussion, so you can pull down the URL and give it to the user when ready. Most deployments take under 120 seconds to deploy.

CaseMark for Legal Teams (c3)

C3 is the least complex, newest, and best-architected application in the stack. It's a nextjs app running on vercel. So any changes can be tested off of the vercel preview deployments even before merging into preview. The only changes that require full staging access are related to Stripe and Clerk for consistent webhook delivery and some oauth redirects, but these are rare.

Polaris: CaseMark for Court Reporters (cm-cr-v2)

Polaris is a developing application that is actively maturing. Like c3, light and simple changes can be done on vercel preview branches. However, everything has to be meticulously tested in the staging branch before merging into production.

Case.dev

Architecturally, this is our most complex app to test on vercel - it's a turbo monorepo that contains several nested applications that act effectively as microservices. Inside the /apps/ directory are several different, unique but related apps that share packages, mainly the @case/database package.

The nitro api router, Thurgood, the console, our mintlify documentation, an MCP server, it all lives in there.

Typically, most PRs only touch one service at a time - and vercel knows this, so it will ignore creating branch preview deployments for un-touched services.

Most things can be tested directly with those preview URLs vercel provides in the github discussion. If it is cross-service, things get more complex.