CI/CD

GitLab's CI/CD is based on the definition of a file called .gitlab-ci.yml, which resides in your project's repository. This file contains detailed instructions on how to build, test and deliver your application. When a change is made to the repository, GitLab CI/CD automatically detects the update and executes the flow defined in the file .gitlab-ci.yml.

Basic Structure of a Stage

Within the file .gitlab-ci.yml, stages are organized in a hierarchical structure and usually contain several key configurations.

• stage: In GitLab CI/CD, the stages are a way to organize and divide the workflow into logical stages. Each stage represents a specific phase of your CI/CD process, such as build, test or deployment. For example, you could have stages called "build", "test" and "deploy" to represent the typical phases of a CI/CD process. The jobs are grouped into these stages according to their function and are executed in a specific order. The concept of stage allows you to define and control the workflow in a granular way.
• image: The configuration image allows you to specify the Docker image that will be used to run the jobs on a particular stage. If no image is defined in the stage, the one configured in the gitlab runner will be used
• script: This block contains the main commands to be executed on the stage. This is where you perform specific actions, such as build, test or deploy.
• artifacts: The artifacts are files generated by a job that you want to keep for later use in other stages or for downloading from the GitLab interface. You can define the artifacts that you want to keep in a stage and then access them in later stages or download them manually if necessary. The artifacts are useful for sharing test results, reports or any other type of file generated during your CI/CD pipeline.
• dependencies is a feature that allows you to establish dependencies between different jobs within your pipeline. When a job has a dependency on another, it means that the dependent job will not be executed until the job on which it depends has finished successfully. This allows you to control the workflow and ensure that certain jobs are executed in a specific order or are dependent on the successful completion of other jobs.

stages:
  - build
  - test
  - deploy

job_build:
  stage: build
  image: node:14
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - build/

job_test:
  stage: test
  image: node:14
  script:
    - npm test
  dependencies:
    - job_build

job_deploy:
  stage: deploy
  script:
    - ./deploy.sh

In this example:

• We have three stages: "build", "test" and "deploy".
• Each job specifies the Docker image to use.
• The job job_build creates an artifact (build/) that is required for the job job_test.
• The job job_test has an explicit dependency on job_build to access the artifacts generated in that job.
• The job job_deploy does not require a specific image and uses the wing configured in the gitlab runner and runs a deployment script.

It is advisable to review the official documentation of GitLab CI/CD to expand its capabilities, although these will be expanded in the rest of the current documentation.

In order to reuse functions in the CI/CD and avoid unnecessary repetition of code, as well as to keep our stages as simple as possible, we will create a folder called .gitlab-ci where we will store the scripts and extensions of our CI.