How To Build CI/CD Pipeline: A Simple Guide

Cloud-native applications have made development faster, more scalable and more modular. They have also made delivery more complex: more services, more environments, more steps between a commit and production. CI/CD pipelines take those repetitive steps over, building, testing and deploying your code the same way every time.

This guide explains what a CI/CD pipeline is, compares scripted and declarative pipeline syntax, and shows how to build a pipeline in Microtica that tests your code, builds a Docker image and deploys it.

What Is a CI/CD Pipeline?

A CI/CD (continuous integration and continuous deployment) pipeline automates software delivery. When you push code, the pipeline builds the app, runs the tests and deploys the result to a staging or production environment.

The main benefits:

• Consistent, automated testing
• Faster time to production
• Fewer manual errors
• Easier rollbacks and debugging

To build a pipeline you can rely on, you need a CI/CD tool that defines the process in a structured, repeatable way, preferably as code that lives next to your application.

Choosing Between Scripted and Declarative Pipelines

Pipelines come in two styles. Both define which steps run and in what order, but they differ in structure and in how much freedom they give you.

Scripted CI/CD Pipelines

A scripted pipeline, such as a Groovy-based Jenkinsfile, is a program. You can write any logic into it, which gives you full control. That freedom has a cost: scripts grow hard to read and maintain, especially in large projects.

Choose scripted pipelines when your process really needs programmatic control.

Declarative CI/CD Pipelines

A declarative pipeline describes the steps and their settings, and the CI/CD tool works out how to run them. It’s easier to read, review and keep consistent across services.

Microtica pipelines are declarative. The spec is a YAML file, microtica.yaml, kept in your repository. Because it lives with the code, every change to the pipeline is versioned, reviewed and rolled back like any other change.

Build, Test and Push a Docker Image

Here is a pipeline in Microtica’s format. It installs dependencies and runs the tests, builds a Docker image from the repository’s Dockerfile, pushes it to your container registry, and deploys it to a Kubernetes cluster:

steps:
  BuildApplication:
    type: build
    commands:
      - npm ci
      - npm test
    docker:
      image_name: "{{MIC_PIPELINE_NAME}}"
      registry: "{{CONTAINER_REGISTRY_ID}}"
      tag: "{{MIC_PIPELINE_EXECUTION_ID}}"
      dockerfile: ./.microtica/Dockerfile

  DeployApplication:
    type: deploy
    target: kubernetes
    cluster: "{{CLUSTER_ID}}"
    service: "{{SERVICE_NAME}}"
    namespace: "{{CLUSTER_NAMESPACE}}"
    branch_filter: "{{MIC_BRANCH_FILTER}}"
    tag: "{{MIC_PIPELINE_EXECUTION_ID}}"

A build step runs its commands, then builds and pushes the image if it has a docker section. A deploy step rolls a built version out to its target. Values in double braces are variables Microtica fills in when the pipeline runs: the pipeline’s name, the registry, the run’s ID as the image tag, and the cluster, service and namespace it deploys to. If a command fails, the step fails and nothing is deployed.

This is the same structure the Kubernetes starter templates put in .microtica/microtica.yaml, with a test command added.

How to Build a CI/CD Pipeline with Microtica

You rarely write the pipeline from scratch. Microtica creates it when you add a service:

• An app on Amazon ECS from your repository gets a pipeline Microtica generates: it builds the image, with your Dockerfile or Railpack, and deploys every push to your branch. If you add a microtica.yaml at the repository root, your spec runs instead.
• A service on Kubernetes gets the pipeline files in a .microtica folder: microtica.yaml and a Dockerfile. If the repository doesn’t have them yet, Microtica commits them to your branch, and you edit them from there.

Either way, Microtica adds a webhook to the repository, so every push to the branch starts the pipeline. The review step of the add flow lists all of this before anything happens. Here it is for a new React app on a Kubernetes cluster:

To change what the pipeline does, edit microtica.yaml in the repository and push. A test step, a linter or a migration is a few lines of YAML.

Monitor Pipeline Runs and Logs

Every run, whether a push or a manual run, has its own page. It shows the commit, the branch, how long the run took and the outcome, then each step grouped by stage with its live log.

When a step fails, the run page leads with it: which step, the error and the steps that didn’t run. You can ask Mica to investigate the failure, then fix the cause and run the pipeline again.

Following CI/CD best practices, watch every build, fix failures as soon as they appear, and keep logs accessible to everyone on the team. Pipelines in Microtica lists every pipeline in the project with its latest runs, so a pipeline that keeps failing stands out.

Conclusion

A CI/CD pipeline turns every push into a tested, repeatable release. With Microtica, the pipeline is a declarative microtica.yaml in your repository, created for you when you add a service and extended with a few lines of YAML when you need more. Push your code, and the pipeline takes it from commit to a running deployment.