CI/CD
DevOps
How-to
All categories
May 27, 2025

How To Build CI/CD Pipeline: A Simple Guide

Cloud-native applications have made development faster, more scalable, and more modular. But managing these distributed systems also introduces complexity. That’s where CI/CD pipelines come in. They allow teams to automate repetitive steps like code building, testing, and deployment.

In this guide, we’ll show you how to build a CI CD pipeline . You’ll learn what a pipeline is, the difference between scripted and declarative syntaxes, and how to automate Docker image deployment.

What is a CI/CD Pipeline?

A CI/CD (Continuous Integration/Continuous Deployment) pipeline automates the entire software delivery process. When you push code, the pipeline kicks in: it builds the app, runs tests, and deploys to a staging or production environment.

The main benefits of CI/CD pipelines include:

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

To build a CI CD pipeline effectively, you need a CI/CD tool that lets you define your process in a structured, repeatable way—preferably as code.

Choosing Between Scripted and Declarative Pipelines

Before setting up a pipeline, you need to decide between two pipeline syntaxes: Scripted and Declarative. Both are used to define what steps should happen and in what order, but they differ in complexity and structure.

Scripted CI/CD Pipeline

The scripted syntax is based on Groovy and is less restrictive. It allows you to write logic directly in the pipeline script, which gives more flexibility. But with that freedom comes complexity—scripts can become hard to read and maintain over time, especially in large projects.

Use scripted pipelines if your automation process is complex and needs full programmatic control.

Declarative CI/CD Pipelines

For the pipeline process to work, each component/microservice should have a file named microtica.yaml on the root level in its source code. This file contains the specification of the build process.

During the build process, Microtica extracts the specification from the code. Then, it creates a state machine to drive the defined process.

In order to ensure a single source of truth for pipeline specification, Microtica does NOT allow changes in the Build pipelines from the UI. Changes will only take effect from the YAML file provided in each source code repository. We find this very helpful in avoiding possible confusion of definition, maintenance, and, most importantly, debugging problems in the process. 

Extending the Pipeline: Build and Push a Docker Image

To take things further, let’s add Docker image creation and pushing to the CI/CD process. This pipeline builds and tests your code, creates a Docker image, and pushes it to Amazon ECR.

Pipeline:

 StartAt: Build  
 States:    Build:      
 Type: Task      
    Resource: microtica.actions.cmd      
    Parameters:        
    	environmentVariables:          
        pipelineId: "$.pipeline.id"          
        version: "$.commit.version"        
       commands:        
       - echo Starting build procedure...        
       - npm install        
       - npm test

 	echo Logging in to Amazon ECR...        
	 - $(aws ecr get-login --region $AWS_REGION --no-include-email) 
 
 	- echo Checking if repository exists in ECR. If not, create one        
 	- repoExists=`aws ecr describe-repositories --query "repositories[?repositoryName=='$pipelineId']" --output text`        
	 - if [ -z "$repoExists" ]; then aws ecr create-repository --repository-name $pipelineId; fi        
	 
     - awsAccountId=$(echo $CODEBUILD_BUILD_ARN | cut -d':' -f 5)
 	- artifactLocation=$awsAccountId.dkr.ecr.$AWS_REGION.amazonaws.com/$pipelineId        
	
    - echo Build Docker image...        
 	- docker build -t $pipelineId .        
	- docker tag $pipelineId $artifactLocation:$version        
	- docker tag $pipelineId $artifactLocation:latest
    
 	- echo Push Docker image        
 	- docker push $artifactLocation        
 	sourceLocation: "$.source.location"        
 	artifacts: false      
 End: true

This configuration uses environment variables and bash commands to automate Docker tasks. After a successful build and test, the image is tagged and pushed to ECR.

How to Build a CI/CD Pipeline with Microtica

To build a CI CD pipeline in Microtica, start by creating a Git repository for your project. Add a microtica.yaml file to define the pipeline logic. Once your project is connected to Microtica, use the portal’s wizard to create a component and set up automatic build triggers. Microtica adds a webhook to your repo, so every time you push new code, the build starts automatically.

automate-build-trigger-ci/cd-pipeline
Automate build trigger

Building the docker image gave us an artifact so we can deploy it in a Kubernetes cluster. You can do this from Microservice details — Add to Cluster, or in the Kubernetes Dashboard — Microservices — Deploy.

Deploy microservice configuration

When you deploy your microservice in a Kubernetes Cluster you can select the scaling options. Moreover, you can also set up continuous delivery for your microservice.

Monitor Pipeline Logs and Status

Every time your pipeline runs—either manually or via webhook—you can follow its progress in the Microtica portal. Real-time logs show each command and its output. If something fails, you’ll see a red error marker and can inspect the logs to debug the issue quickly.

Following CI/CD best practices, it’s important to monitor every build, catch failures early, and keep logs accessible for all developers on the team. Microtica makes this easy by providing centralized access to build history and logs through the Pipelines Overview page.

details-logs-cicd-pipeline
Build details and logs

You can check build health, review past logs, and rerun any build from the interface when needed. It’s good practice to regularly review these logs and use them to improve pipeline reliability over time.

Microtica also flags unhealthy pipelines that repeatedly fail, allowing teams to take quick corrective action. This aligns with best practices such as failing fast, fixing broken pipelines immediately, and avoiding manual patchwork that hides underlying issues.

Conclusion

If you want faster releases and fewer deployment headaches, it’s time to build a CI CD pipeline. Using tools like Microtica and the declarative syntax, you can automate the entire process—from code commit to Docker image deployment.

You’ll spend less time on manual tasks and more time improving your software. So start by writing a microtica.yaml file and connect your repository. Once you see how smoothly it works, you’ll wonder why you didn’t build a CI CD pipeline sooner.

Subscribe to newsletter

Subscribe to receive the latest blog posts to your inbox every week.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

*By subscribing you agree to with our Privacy Policy.

Relevant Posts

Cloud cost optimization
All categories
Top 10 Heroku Alternatives for Your Next Project
October 12, 2022