Steps

A step is a core building block of the Microtica pipeline. By chaining multiple steps, you can build complex pipelines to automate your entire software delivery process.

In Microtica, there are two types of pipeline steps:

  • Generic steps
  • Build-in steps

#Generic steps

Generic steps provide a flexible way to precisely define your step instructions and have a full control over what that step does.

microtica.yaml

steps:
  MyGenericStep:
    image: node:latest
    title: Build my NodeJS app
    commands:
      - npm install
      - npm test

In this step definition we have:

  • image – the Docker image that defines the runtime environment
  • title (optional) – a step description
  • commands – a list of commands to be executed in this step

In this example, we use the latest version of NodeJS as our runtime environment and execute a set of npm commands.

In the same way, we can define a runtime environment for Go language and compile the code.

microtica.yaml

steps:
  MyGoStep:
    image: golang:latest
    commands:
      - go build

#Built-in steps

Built-in steps are steps provided by Microtica for certain actions that are common when defining CI/CD pipelines.

Some typical actions would be build/push Docker images, executing Terraform scripts or sending Slack messages.

Below is an example of using a built-in step of type docker-push that builds and pushes Docker image on a specified Docker registry.

microtica.yaml

steps:
  PushDockerImage:
    type: docker-push
    image_name: microtica/my-app
    tag: v0.1.0
    registry: my-registry

In this step definition we have:

  • type – the step type
  • image_name – the name of the image to be pushed
  • tag – the tag identifier for the image
  • registry – the name of the registry, created within Microtica, to be used

You can notice that we haven’t specified a runtime for our step or any custom commands to be executed. Everything happens automatically behind the scenes.

Step parameters

Each built-in step would have a different set of parameters which are specific for that step type.

Under Steps you can find more information about individual built-in steps.

#Input parameters

Input parameters allow the step to accept the input data that can be used inside the step execution. Using generic steps you can define an arbitrary number input parameters for your step.

Use parameters when you want to:

  • parametrize the way you pipeline works
  • avoid hard-coding within the step execution logic
  • avoid storing sensitive information within the pipeline yaml using Pipeline Variables

Here is an example of providing a custom parameter to a step:

microtica.yaml

steps:
  BuildApp:
    image: node:latest
    commands:
      - echo "Build my service: ${service_name}"
    parameters:
      service_name: "User Service"

Parameters service_name can be referenced in the commands section using a standard Unix syntax ${service_name}.

Security consideration

Never hard-code sensitive data in pipeline yaml.

For security reasons, always use Pipeline Variables with sensitive flag enabled when specifying parameters like passwords, secret tokens or any other data which is considered as sensitive.

#Sharing state between steps

To enable seamless integration between steps, Microtica provides automated state sharing between steps. Having this, you don’t have to worry about managing and maintaining the state manually.

Each step within the pipeline shares the same directory state with the other steps allowing files generated in the current step to be automatically available in all following steps in the execution order.

Sharing state between steps comes handy when you want to design your pipeline with multiple steps that need to share the same state. A good example of this would be when you compile your code in one step and execute tests against previously compiled code in another step.

#Artifacts

Sharing state between steps is beneficial when you want to have the state persisted between steps. However, in cases when you want the output of a certain step to be available outside of the pipeline, Microtica allows you to do that by using artifacts.

Here’s an example of producing an output artifact my_artifact:

microtica.yaml

steps:
  BuildNodeApp:
    image: node:latest
    commands:
      - npm install
      - npm run build
    artifacts:
      files:
        # wildcard are also supported in the path (e.g. /build/*.js)
        my_artifact: /build/

In this case, the entire content within the build folder will be packaged, zipped and stored on a secure blob storage.

Artifacts can be downloaded from the GUI for each pipeline execution. If more then one artifact is being declared, you can choose which one to download.

Microtica also provides built-in support for Docker and JSON artifacts. To learn more about all supported artifact types jump to Artifacts spec.