Launch vs GitHub

A campaign is the durable object in Launch. It owns the assets, systems, requirements, approvals, and history attached to it. One object carries readiness, approval, go-live, and review.

GitHub organizes work around repositories. A pull request proposes a change to code. Its conversation tab holds the description, comments, and reviews. Its files tab shows the diff that reviewers use.

Preflight is an automated test a campaign must pass before it is allowed to go live. It covers twenty-one requirements in six groups. No person can mark a requirement complete. Requirements that do not apply leave the readiness count.

GitHub rulesets can require pull request reviews, signed commits, and linear history. They can restrict force pushes and control file paths. Actions workflows build and test changes when events such as pull requests occur.

Launch asks for two approvals, always in the same order: brand, then legal. People approve. Launch records who approved, against which version of the rules. A committed launch is read only for everyone but the current approver.

GitHub merge status shows blockers and missing approvals before a merge. Administrators can require reviews and code owner approval. For deployments, environments can require up to six reviewers, add wait timers, and limit deployment branches.

Launch rules cover brand, language, claims, legal, and accessibility. Rules are versioned. Every evaluation names the version that produced it. Exceptions are scoped, owned, tied to a rule version, and time bound.

GitHub rulesets apply to branches and tags. Several rulesets can apply to one branch at once, and the most restrictive rule wins. They govern reviews, commit metadata, and pushes.

Scan checks what is live across a company’s public web presence and connected systems. A domain scan needs no account and no credentials. A team can see what is live and how it differs from what was approved.

GitHub automation is event-driven. A workflow runs when something happens in a repository, on a schedule, or on a manual trigger.

Every Launch integration is read only, except Slack messaging, which the customer enables. Systems holds the connections. Scan and Preflight read from them. See the integrations page for what is connected today.

GitHub webhooks send event data to external servers when actions occur. Its APIs and Actions ecosystem connect it to developer tools and collaboration tools.

Every action is written to an append-only log with the actor and a timestamp. Minimum retention is two years. Exports are logged under the exporting user.

The GitHub organization audit log records who acted, what they did, and when. It keeps 180 days of records and exports to JSON or CSV. Only organization owners can open it. Enterprise Cloud organizations can use it through the GraphQL and REST APIs.

Approvals belong to named people. Launch records who acted and when. Read the Launch security page for current controls. This page states no certification.

Deployment environments can prevent a reviewer from approving their own deployment. Confirm current controls and certifications in GitHub’s own security documentation.

Scan checks and Preflight evaluates without anyone asking. People decide, and people fix content where it lives. Launch reports; it does not change your systems.

GitHub Actions is a CI/CD platform that automates build, test, and deployment. Workflows are YAML files. Events, schedules, or manual activation trigger them, and jobs run on runners.