CI/CD for Go-to-Market: What It Means and How to Set It Up

CI/CD for go-to-market (GTM CI/CD) means every change to how you enrich, score, route and reach leads ships the way software ships: as a pull request that shows what will change and what it will send and spend, passes a check, gets approved, deploys automatically when it merges, is logged, and can be reverted. On Cargo, you declare the go-to-market engine as a TypeScript project in a git repository and connect that repository in Settings → States. From then on Cargo comments a plan on every pull request and holds large merges until a reviewer adds the cargo:approve-impact label. Every merge to the production branch runs cargo-ai project deploy --yes as a service user.

Why go-to-market needs it #

In most go-to-market stacks a change goes live the moment someone clicks save. A new lead score threshold, a routing rule, an extra enrichment step or a sequence edit takes effect on the next record, with nobody reviewing it first. Nothing tells you beforehand how many contacts the edit will email or how many credits it will burn, and undoing it depends on someone remembering what the old setting was.

Software teams solved the same problem decades ago. Code changes go through a pull request, an automated build checks them, a reviewer approves them, a pipeline deploys them, and every deploy is recorded so a bad one can be reverted. Building go-to-market now looks like building software, and the same discipline applies once the engine lives in files.

Each CI/CD step, for go-to-market #

The rest of this page walks through setting it up and shipping one change.

Set it up #

Put the project in git and push it to GitHub:

npm install -g @cargo-ai/cli
cargo-ai login --email you@company.com
cargo-ai project init acme-gtm      # scaffolds the project and creates its deploy state
cd acme-gtm && git push

Then connect the repository:

1. Settings → Connectors → GitHub: connect your GitHub account and install the Cargo GitHub app on the repository.
2. Settings → States: open the project’s state and pick the repository, the production branch and the directory that holds cargo.state.json. From a terminal, cargo-ai project state connect does the same for an existing project.
3. In GitHub branch protection, make the Cargo check required on the production branch, so a failed or waiting check actually blocks the merge.

There is no workflow file to write and no Cargo API token to store in GitHub. The GitHub page covers what the app does, and deploy go-to-market changes on merge covers every option of the connection.

One change, start to finish #

Take a play that enriches, scores and routes every new HubSpot contact:

// infra/plays/inbound.ts
import { definePlay } from "@cargo-ai/cdk";

import { contacts } from "../models/contacts";
import { enrichScoreAndRoute } from "../workflows/enrichScoreAndRoute";

export const inbound = definePlay("inbound", {
  model: contacts, // HubSpot contacts, synced by a connector-backed model
  changeKinds: ["added"],
  schedule: { type: "realtime" },
  workflow: enrichScoreAndRoute,
});

Someone on the team wants to post a Slack message to the account owner whenever a contact scores above the routing threshold. They add the step to enrichScoreAndRoute on a branch and open a pull request.

The plan. Cargo clones the commit into a sandbox, compiles it with your pinned @cargo-ai/cdk, and diffs it against the deploy state. The comment lists play:inbound as an update and leaves the other resources counted as unchanged. A plan never gets a Cargo credential, so opening a pull request changes nothing in the workspace.

The impact. Above the resource table, the “On merge” table counts the records the play runs on and the chat messages its steps can send for them, as upper bounds. That is the part a resource diff cannot tell you: preview what a change will send explains how each column is counted.

The approval. If the totals across the pull request go above 100 emails, 100 LinkedIn actions, 100 chat messages, 5,000 audience adds or 2,500 credits, the check shows Action required with the title Needs approval: add the cargo:approve-impact label. A reviewer reads the table and adds the label, Cargo plans again, and the check passes. Require approval before a high-impact change goes live covers who should hold that label.

The deploy. Merging pushes to the production branch, and Cargo runs cargo-ai project deploy --yes on that commit as the connection’s service user, with a credential minted for the run and revoked when it ends. Deploys of one project run one at a time, in order. While Deploy on push is on, Cargo refuses a deploy from anyone else, so the merge is the only way the change reaches production.

The log. The deploy appears on the project’s state in Settings → States as queued, running, success, error or cancelled, recorded with the commit it ran on. Git keeps the diff and the review, and the pull request’s timeline shows who added the approval label.

The undo. If routing goes wrong, git revert <sha> on a branch, open the pull request, and merge it. The plan shows the diff going back, and the deploy reconciles the workspace to the previous definitions. Roll back a go-to-market change covers stopping a play first and what a revert cannot recall.

Testing before production #

Continuous integration is more than a diff. For go-to-market, the most useful test is a pilot on a few records before a play runs on all of them. A dry run shows an action’s output and price before you wire it in, and an eval suite checks each agent’s prompt. Test a go-to-market change before it reaches production walks through each one, and evaluate an agent before production covers agent prompts in depth.

Limits worth knowing #

• Messages already sent stay sent. A revert stops future enrollments. Emails, LinkedIn actions and records written to your CRM are not recalled, which is why the preview and the approval come before the merge.
• Edits in the Cargo UI bypass the pipeline. Resources deployed from code stay editable in the app, and the project never reads those edits back. Pick one owner per resource, and run cargo-ai project refresh to see what drifted.
• Pull requests from forks are not planned.
• Anyone who can push to the production branch can deploy. Protect that branch the way you protect production.

Prefer your own CI? The connected repository runs the same two commands, cargo-ai project plan and cargo-ai project deploy, that your pipeline can run. To have a coding agent make the change for you on the pull request, see ask @cargo on a pull request. The full lifecycle, one page per step, is in GTM as code: the complete guide.

FAQ #