CI/CD explained through one small deployment

CI and CD answer different questions

This is an evergreen CI/CD exercise, not an announcement of a new platform feature. Continuous integration asks whether a change can be combined with the shared code safely enough to review: does it install, build, test or satisfy another agreed check? Continuous delivery asks whether an accepted version can move through a repeatable release process. Some teams deploy automatically; others require approval before production.

GitHub Actions defines a workflow as an automated process containing one or more jobs. A repository event, manual action or schedule can trigger it, and each job runs steps on a runner. That structure can support both integration checks and deployment, but calling a YAML file “CI/CD” does not prove the checks are useful or the release succeeded.

Source: GitHub Docs: WorkflowsGitHub Docs: Quickstart for GitHub Actions

Prepare one change with an observable result

Use a disposable repository containing a single index.html page. Put a heading, a short sentence and a deployment marker such as Release: practice-1 in the page. Do not use a customer site, production credentials or private data. Your planned change is deliberately small: replace the sentence and update the marker to practice-2.

Before editing, write four acceptance checks: the HTML file exists, it contains exactly one title heading, the new marker is present, and the old marker is absent. These checks are simple, but they connect the pipeline to a visible requirement. A green workflow that checks only whether a command started would provide much weaker evidence.

• Use a separate branch for the practice-2 change.
• Keep the commit limited to the page and the intentional check configuration.
• Record the expected marker before opening a pull request.

Make continuous integration repeat the checks

Add a GitHub Actions workflow in the repository’s .github/workflows directory. Configure it for pull requests and make its job check out the repository, run a small HTML validation or project test, and search for the expected practice-2 marker. Use a maintained action version and review any third-party action before granting it access. The exact commands should match your repository rather than being copied blindly.

Open a pull request and inspect the workflow run. First introduce a controlled failure by leaving the old marker in the page while the check expects the new one. Save the failed job and its message, then correct the page and push another commit. The passing rerun now demonstrates that this particular requirement was checked; it does not establish that the page is accessible, secure or visually correct.

Source: GitHub Docs: WorkflowsGitHub Docs: Quickstart for GitHub Actions

Use a preview before production

Connect the disposable repository to a deployment provider only after checking its account, visibility and billing settings. Vercel documents that branch pushes can create preview deployments while changes merged into the configured production branch create production deployments. Open the preview URL from the pull request and confirm that it displays practice-2 without changing the public production URL.

Treat preview and production as different environments. A preview can reveal a missing file, wrong route or broken layout, but it may use different environment variables, domains or external services. Never place a secret in the HTML or workflow log. If the exercise does not need a credential, do not create one.

Source: Vercel Docs: Deploying Git repositories

Merge, deploy and verify the exact version

After the integration check passes and the preview matches the acceptance list, merge the pull request. Observe the production deployment rather than assuming that a successful push is a release. Vercel describes production deployments as changes from the configured production branch, which is often main but can be changed in project settings.

Open the production URL in a fresh browser request and verify the practice-2 marker. Also compare the deployment’s commit identifier with the merged commit and review the build log for warnings. Record the URL, commit, deployment time and verification result. This creates a small evidence chain from requirement to commit, check, preview and production.

Source: Vercel Docs: Deploying Git repositoriesVercel Docs: Deploying to Vercel

Practise one failure and one recovery

Repeat the exercise on a new branch with an intentionally invalid file path or failing marker check. Confirm that CI fails and that the failed branch does not replace production. Then repair the change normally. Do not bypass the check merely to make the workflow green, and do not experiment with destructive commands or a shared production account.

A real rollback may mean reverting the responsible commit, redeploying a known version or using a provider rollback feature. The right method depends on the application, database changes and team procedure, so this static-page exercise cannot model every production risk. For a portfolio, explain the controlled failure and the evidence that recovery worked. Learners in Chennai or online can extend this pattern in SPOTHUB’s Cloud & DevOps path; training and a successful lab do not guarantee employment or production readiness.

Source: Vercel Docs: Deploying to Vercel

Sources and further reading

• GitHub Docs: Workflows · checked 2026-09-29
• GitHub Docs: Quickstart for GitHub Actions · checked 2026-09-29
• Vercel Docs: Deploying Git repositories · checked 2026-09-29
• Vercel Docs: Deploying to Vercel · checked 2026-09-29

Spot an error? Email info@spothub.in with the article link and correction.