Building a good CI/CD pipeline with GitHub Actions It's no longer an extra "for when there's time": in modern teams, it's practically a requirement for rapid and reliable deployment. Even so, finding a complete, generic, and well-thought-out example that you can adapt to your company is often much more complicated than it seems.
In the following lines we will mix the classical theory of CI/CD with real-world implementation examples using GitHub Actions, reusable pipelines, Tasks, bash scripts, PowerShell PnP modulesDeployments to Kubernetes, Google Cloud, and Kinsta, along with best practices for security, monitoring, and scalability. The idea is that you can take these pieces, fit them into your context, and avoid many of the typical pitfalls.
Why you need a well-built CI/CD pipeline
In current professional development, CI/CD is the circulatory system of the codeIt integrates changes, runs tests, builds artifacts, and deploys new versions with minimal intervention. Without this workflow, every deployment becomes a slow, error-prone, manual ordeal.
Continuous integration (CI) focuses on validating changes As soon as they're uploaded to the repository, unit tests, linters, and static analyses are run to catch bugs as quickly as possible. The faster you get feedback, the sooner you can fix them, and the less painful any regression will be.
Continuous Deployment (CD in the sense of Continuous Deployment) or Continuous Delivery (depending on the level of automation) adds automation of the release part: building images, publishing packages, deploying to test, staging or production environments, and even changing traffic using blue-green or canary strategies.
In companies with a lot of legacy codeA good pipeline is one of the best levers for modernizing the ecosystem: it allows you to introduce tests into legacy services, automate tasks that were previously done manually, and reduce the cost of maintaining infrastructures like Jenkins or Nexus that have become outdated.
What is GitHub Actions and why does it fit so well with CI/CD?
GitHub Actions is the automation platform built into GitHub. It allows you to define workflows in YAML files within the repository itself. With it, you can compile, test, analyze, and deploy your software without setting up external CI servers.
A workflow is a set of jobs and steps which is triggered by events such as push, pull_request, schedule (CRON), workflow_dispatch (manual) or even actions on issues. Each job runs in a runner (for example, ubuntu-latest) and consists of steps that use reusable actions or commands run.
GitHub offers a huge marketplace for shares where you have ready-made integrations for almost everything: Docker, Kubernetes, AWS, Azure, Google Cloud, SonarCloud, Slack, Jira, security analysis, linters for a thousand languages, etc. This greatly reduces the time required to set up advanced pipelines.
Compared to solutions like Jenkins or ConcourseGitHub Actions has several clear advantages: it's a managed service (you don't manage servers), it's closely tied to the code, it uses a pay-as-you-go model, and it's supported by a massive community. Furthermore, many developers are already familiar with it from personal projects, which significantly reduces the learning curve.
Basic components of a GitHub Actions workflow
It all starts with a YAML file in .github/workflows/, for example ci.yml o build-test-deploy.ymlAlthough the syntax can grow considerably, the basic structure is relatively simple.
The key sections of YAML are: name (workflow name), on (events that trigger it), jobs (set of logical tasks), and within each job, runs-on (runner), steps (steps), env (global variables) and if (conditions for executing steps or jobs).
Jobs represent blocks of work that can be run in parallel or in a chain using needsWithin each job, the steps use actions (uses:) or commands (run:A typical example includes: code checkout, dependency installation, linter execution, tests, and build.
Secrets and environment variables They are managed at the repository, organization, or environment level. In workflows, they are referenced with ${{ secrets.MI_SECRET }} and allow working with API keys, deployment tokens, or cloud credentials without exposing them in the repository.
YAML also allows building execution arrays to strategy.matrix, very useful for testing your code on various versions of Node, Python or Java, or even on different operating systems without writing the same block multiple times.
Design a modern CI/CD pipeline using best practices
A healthy pipeline is usually divided into clear phases: quick checks (lint, unit tests), artifact build, release (version, labeling, changelog, publication in artifact repository) and deployment in one or more environments.
The continuous integration phase should be as fast as possible. This ensures that any push or pull request receives almost immediate feedback. A common practice is to run the various checks in parallel using separate arrays or jobs, assuming a slightly higher cost in exchange for reducing the overall waiting time.
To decouple the pipeline from the concrete languageYou can use a task tool like Task (similar to Make but with a more user-friendly syntax). This way, the GitHub Actions workflow only invokes generic tasks (task test, task lintetc.) and each repository defines how they are implemented internally depending on whether it is Node, Java, Python, etc.
Versioning and artifacts come into play during the release phase.Here you build a Docker image, a jar/war file, an npm package, or any other artifact, upload it to the corresponding registry (Docker registry, Maven, npm in Artifact Registry, etc.), tag commits, and generate GitHub Releases or changelogs with tools like git-cliff or release actions.
Finally, the deployment phase Move that artifact to the runtime environment: Kubernetes (GKE), Google App Engine, Cloud Functions, services on Kinsta, your own servers via SSH, etc. Here you can chain subsequent steps, such as functional tests after deployment or Slack notifications with release details.
Example: Complete pipeline with ESLint, tests, and deployment on Kinsta
A very illustrative example is using GitHub Actions To validate a React application with ESLint and unit tests, and then deploy it to Kinsta using its API. Everything is orchestrated in a single CI/CD workflow.
The first part of the YAML defines the trigger and the pipeline name. For example, that it runs on each push y pull_request to the branch main, and even scheduled with CRON jobs (for example, every day at midnight or every Monday at 8:00 UTC) using the event schedule.
The first job in the pipeline can be called eslint and it is responsible for checking the code syntax. It runs in ubuntu-latest and uses an array of Node versions (e.g., 18.x, 20.x), with steps to check out and configure Node with actions/setup-node, cache npm dependencies, install with npm ci and throw npm run lint.
The second job, testsIt depends on eslint through needs: eslintso it only runs if the syntax check is successful. Inside, the pattern is repeated: checkout, dependency installation, and execution of npm run test on a specific version of Node.
The third job, deployIt is chained after both jobs using needs: and uses a step with curl to call the Kinsta API. To do this, the API key and application ID are configured as secrets in GitHub (KINSTA_API_KEY y APP_ID) and are exposed in the job via env to build the POST request that triggers the deployment.
It's important to understand that this deployment job Kinsta considers the mere acceptance of the API a success; however, if the deployment subsequently fails internally within Kinsta, the GitHub workflow may still show a green status. This should be kept in mind to avoid complacency and to supplement the process with post-deployment monitoring.
Advanced cron management and workflow scheduling
The CRON syntax in GitHub Actions It is based on the UNIX five-field format: minute, hour, day of the month, month, and day of the week. Each field can use asterisks, ranges, lists, and steps (*, 1-5, 1,15,30, */5), which allows scheduling maintenance tasks, backups, cleanings or periodic checks.
For instance, 0 0 * * * execute the workflow every midnight (UTC), while 0 8 * * 1 It does this every Monday at 8:00. This combines seamlessly with the usual triggers of push y pull_requestso that the same YAML can react to both code changes and scheduled executions.
This capability is ideal for tasks that don't make sense to release in every commit: intensive security scans (e.g., with OWASP Dependency Check in Java), dependency audits, test coverage checks, or cleaning up old artifacts in the registry.
Workflow reuse: scaling CI/CD to hundreds of repositories
When your organization has dozens or hundreds of repositoriesCopying and pasting the same YAML everywhere is a recipe for chaos. Any change requires modifying half of GitHub Enterprise, making it nearly impossible to maintain consistency and best practices.
The solution lies in designing reusable workflows centralized in a CI/CD “template” repository. These workflows expose inputs and outputs, and each service only defines a small YAML that invokes them, passing parameters such as artifact type (Docker, Java library, npm package), deployment runtime (GKE, GAE, Cloud Function, etc.) or Task items that need to be executed.
A common pattern is to separate three large reusable workflows: one of build-check-task (continuous integration), another of build-release-dockerfile or other artifacts and a third deployment (deploy-gke, deploy-gaeetc.), so that each repository builds its pipeline by combining them.
To encapsulate shared logic, custom actions can also be defined. en .github/actionsFor example, to configure Gradle, Java, Node, or Task, to get build metadata, to publish Docker images, to tag versions in Git with a bash script, or to send notifications to Slack. The golden rule is that service repositories should only use reusable workflows, not these actions directly, so that backward compatibility is more manageable.
Fast continuous integration with Task, matrices, and static analysis
During the build or check phase, it's advisable to trigger many things in parallel.Unit tests, static analysis (PMD, Checkstyle, SpotBugs in Java; ESLint in JS/TS), scanning with SonarCloud, etc. This keeps the total pipeline time reasonable even in large codebases.
Task (Taskfile.yml) acts as an abstraction layer on specific commands, allowing the CI workflow to simply call task check, task test o task lintFor a Java project, these tasks can be delegated to Gradle with JUnit, PMD, Checkstyle, and SpotBugs; for a Node project, to Jest, ESLint, and security tools such as npm audit or similar.
GitHub Actions adds the array piece To run the same tasks on different versions of the runtime: for example, testing a Node library on 16, 18 and 20, or a Python project on 3.10 and 3.12. It's as simple as declaring an array of versions and using it in the job configuration.
This approach is especially useful in organizations that want to support multiple stacks. (Java, Node, TypeScript, Python, etc.) without having to rewrite the pipeline logic for each repository: Task adapts to each language and the reusable workflows remain virtually the same.
Release phase: versioning, tagging, and publishing artifacts
Once the checks are passed, it's time to build the artifact that will actually be deployed.Docker image, JAR file, npm package, whatever is appropriate. This involves both the language tools and the organization's registries and versioning policy.
Some Java projects use plugins like Gradle Axion. to manage versions based on Git tags. In mixed contexts (Java, Node, etc.) it may be simpler to use a custom bash script that calculates the next version (for example using SemVer), creates the tag, pushes it to the remote, and generates the corresponding release.
Tools like git-cliff They help generate changelogs Based on commit messages, changes are classified by type (feature, fix, breaking, etc.). Integrating them into the pipeline ensures that each release comes with a clear changelog without anyone having to write it manually.
To publish artifacts, appropriate actions and credentials are combined.Docker registries (Docker Hub, GitHub Container Registry, Artifact Registry), Maven repositories, npm registries, etc. Again, credentials are stored as secrets and injected into jobs only when needed.
Continuous deployment to Kubernetes, GCP, Kinsta, and other environments
Deployment is where CI/CD interacts with the infrastructureHere, GitHub Actions integrates seamlessly with almost any platform: Kubernetes, App Engine, Cloud Functions, traditional servers, platforms like Kinsta, etc.
For Kubernetes (for example in GKE) the usual pattern It is: authenticate with Google Cloud (using official actions), configure kubectl Within the cluster context, apply the Helm manifests or charts and, if necessary, perform a controlled rollout (e.g., with canary or blue-green) and verify status with commands from kubectl rollout status.
In the case of App Engine or Cloud FunctionsThe pipeline builds the image or artifact, publishes it to the Artifact Registry, and then invokes the deployment commands. gcloud appropriate, again using managed credentials such as secrets and ephemeral runners.
When the deployment is performed against external APIs such as Kinsta'susually a step is enough curl or a specialized action that sends the request with the authentication token and the necessary parameters (app ID, branch, etc.). The job is considered successful if the API responds correctly to the new release request.
The deployment is almost always accompanied by a notification. to Slack, Teams, or other communication tools, indicating which service was deployed, in which environment, with which version, who triggered it, and links to the workflow logs. In production, this also serves for auditing and traceability.
Quality control: security, monitoring and logs
Automating build and deployment is great, but without visibility Regarding what's happening, the pipeline can become a black box. GitHub Actions offers detailed logs by execution, by job, and by step, allowing you to diagnose compilation, test, or deployment failures.
For more advanced needs, external observability services are integrated. such as Datadog, New Relic or Splunk, which collect metrics on workflows, execution times, failure rates, etc., helping to detect bottlenecks and prioritize pipeline optimizations.
In parallel, security plays a key role: management of encrypted secrets, minimum necessary access policies, review of action permissions, incorporation of code vulnerability scanners and dependencies (code scanning, secret scanning, OWASP, etc.) within the workflows themselves.
Many teams also add post-deployment testing in the newly updated environment: end-to-end functional tests, performance checks, basic smoke tests and, if something breaks, automated rollback mechanisms that restore the previous stable version.
Workflow governance: protected branches and pull requests
The way of working with branches and pull requests must align with CI/CD so that everything makes sense. The most common thing is to protect the main branch (main o master) and require that any change goes through PR and passes pipeline checks.
GitHub allows you to define branch protection rules These policies force the use of pull requests, block direct commits, and require that certain status checks (specific Action workflows) be green before allowing the merge. They may also require minimum revisions, approval rules, etc.
This model ensures that the code that reaches production It has passed through human review and all automated pipeline checks, drastically reducing the risk of slipping through serious errors or vulnerabilities.
In companies with multiple environments (development, staging, production) deployment to production is usually reserved for merges into the main branch, while other branches may trigger deployments to previous environments for internal testing or demos.
Looking at the big picture, a well-designed CI/CD pipeline with GitHub Actions It becomes the backbone of development: integrating changes, running comprehensive test suites, building and publishing artifacts, deploying to multiple cloud platforms, monitoring with observability tools, and governing through clear branching and pull request rules. With reusable workflows, custom actions, auxiliary tools like Task, Rease Action, and Git Cliff, and robust secret and permission management, it's possible to support everything from simple Python apps to complex Kubernetes architectures, maintaining delivery speed, code quality, and security without overwhelming the team with manual tasks.
