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 provide a flexible way to precisely define your step instructions and have a full control over what that step does.
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.
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.
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 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
Here is an example of providing a custom parameter to a step:
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.
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.
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:
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.
