MicroticaMicrotica

Pipelines

Automate your software delivery in Microtica with pipelines that run each step in its own Docker container, so you can mix frameworks and tools in one flow.

Pipelines define how your source code travels from your machine to production. You compose a pipeline from steps that run in sequence, in parallel, or both, and each step performs one part of the delivery process.

A typical pipeline does some combination of:

  • Compile and package the code
  • Run unit and integration tests
  • Run code quality checks
  • Build and push Docker images
  • Deploy services on Kubernetes

How Microtica pipelines work

Traditional CI/CD makes you spin up and maintain dedicated VMs to run pipeline actions. Microtica takes a cloud-native approach instead: every pipeline step runs inside a Docker container, so there's no build infrastructure for you to manage.

Running each step in its own container also keeps your pipelines flexible. One step can use the node image to compile a Node.js application; the next can use the hashicorp/terraform image, which ships with the Terraform CLI, to run Terraform operations.

Diagram of Microtica running each pipeline step in a separate Docker container

Each step spins up a new Docker container from the image you specify for that step. The container lives until every action in the step finishes, then it's killed and deleted. Anything held in the container's memory is gone with it.

To carry data across that boundary, Microtica gives you a pipeline shared state that persists between steps for the whole execution.

Pipeline shared state

Microtica preserves state between steps using Docker volumes. This is useful when one step clones the source code from Git and a later step compiles and tests it.

Any step in the pipeline can read and write the shared state at /microtica/shared. Anything written there by one step is available to every other step in that pipeline.

Diagram showing a file written to the shared volume in one step being read in the next step

So if the first step stores a file named index.js, the second step finds it at /microtica/shared/index.js.

Pipeline artifacts

Artifacts persist a step's output even after the step completes. They're typically used to store deployment packages.

Diagram of a pipeline step producing an artifact stored outside the pipeline

microtica.yaml
steps:
  Clone:
    title: Clone my source code from Git
    type: git-clone
  BuildNodeApp:
    image: node:12-alpine
    commands:
      - npm install
      - npm run build
    artifacts:
      files:
        primary: /dst

This spec tells Microtica to package everything in the /dst folder into an artifact named primary. You can then use the stored artifact for deployment or download it from the Microtica console.

Next steps

On this page