Cloud-native applications are on the rise thanks to the scalability and flexibility they provide. However, this type of architecture has its own challenges. Implementing a CI/CD pipeline will solve most of them, like defining delivery procedures, delivering applications independently, and gaining observability of the numerous building blocks in a system are some of them.

A CI/CD pipeline is the key to automating the steps of the software delivery process. This includes initiating code builds, running automated tests, and deploying to a testing or production environment.

One CI/CD pipeline consists of multiple steps executed one after another or in parallel. There are two known pipeline syntaxes — **Scripted **and Declarative. The key difference between them is their flexibility.

Although both syntaxes are based on Groovy DSL, the Scripted Pipeline Syntax is less restrictive. It also allows almost anything that can be done in Groovy. This means that the script can easily become hard to read and write.

On the other hand, the Declarative syntax is more restrictive and provides a well-defined structure, which is ideal for simpler CI/CD pipelines. This syntax supports the “pipeline as code” concept. Therefore, you can write in a file that can be checked into a source control management system like Git.

In order to make it more convenient for developers to set up a CI/CD pipeline, Microtica** supports the Declarative syntax to define build procedures along with the source code**.

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.

#ci/cd #nodejs