Your first CI/CD pipeline: a practical release checklist

A useful first CI/CD pipeline makes an existing release process easier to repeat and inspect. Start with one application, a small set of meaningful checks and a clearly defined deployment target. Add more stages when they answer a real release question.

This checklist is for small development teams and learners moving beyond manual uploads. The examples describe a workflow; they are not a ready-to-run configuration for an unknown production environment.

Write down how a release works today

Choose an application with a known start command and a way to check that it works. Record its runtime, dependencies, build steps, configuration, database changes and deployment destination. Give another team member those instructions and note every missing assumption they find.

For a practice project, use sample data and an isolated environment. A portfolio application with one database and one observable user journey is enough to expose useful questions about build consistency, access and recovery.

Make continuous integration answer a clear question

Continuous integration checks changes as they enter a shared repository. GitHub Actions can run build and test workflows on repository events and show their results on pull requests. The value comes from the checks you select and how the team uses their results. Read GitHub's introduction to continuous integration.

Begin with checks that catch a broken release: installation from declared dependencies, syntax or type validation where applicable, tests for an important behaviour and a successful build. A passing pipeline means those checks passed. It does not establish that every part of the application is correct.

Deliberately introduce a harmless failing test on a practice branch. Confirm that the pipeline reports the failure clearly and that the team's merge policy prevents an unchecked release where required. This tests whether the result can influence the workflow.

Keep the build traceable

Record which commit produced the release package or container image. Keep the build identifier with the deployment record so an operator can connect an observed issue to the change that introduced it.

When practical, promote the same tested artifact through staging and production. Rebuilding separately for each environment can make it harder to establish exactly what was tested. Document the configuration that changes between environments without placing secrets inside the artifact.

Separate test access from deployment access

A job that checks code should not automatically receive production credentials. Define the minimum access needed for each stage and keep deployment secrets out of the repository and logs.

GitHub supports secrets at repository, environment and organization levels. Its documentation also describes OpenID Connect for supported cloud providers, which can avoid storing long-lived cloud credentials in the workflow. The trust configuration still needs to restrict which workflows may authenticate. Review GitHub Actions secret handling.

Check what untrusted pull requests can execute before granting them any sensitive access. Keep an explicit boundary between validating contributed code and deploying an approved release.

Define the production decision and recovery route

Continuous delivery can leave the production release as a deliberate approval step. Continuous deployment automates that release after the required checks pass. Decide which approach fits the application and who owns that decision.

GitHub environments can apply deployment rules and restrict access to environment secrets. Available protection features depend on the repository and plan, so confirm the features in your setup before designing an approval process around them. Check GitHub's environment requirements.

Write down how to return to a working state. A previous application image may be insufficient if a database migration removed data or changed its structure. Rehearse the recovery approach in staging and identify any point that requires a separate data-restoration decision.

Use a short release acceptance checklist

• The commit, artifact and destination are recorded.
• Required checks pass and their output is understandable.
• Deployment access is limited to the intended stage.
• The release owner understands any database changes.
• A health check and a representative user journey work after deployment.
• The team knows when to stop, roll back or escalate.

For guided practice, connect this workflow to the one-application DevOps practice plan. For an existing business system, prepare the current release steps before discussing DevOps and automation with Hysec.