Definir e implementar a melhor forma de subir projetos Node.js, que seguem a estrutura de monorepo, na esteira de automação do Openshift

2.1. Introdução

Automatizar a atualização das aplicações Node.js que seguem o padrão monorepo, evitando possíveis erros humanos. Além de diminuir, significativamente, o tempo para atualizar as aplicações que seguem esse padrão.

É esperado que os projetos Node.js, ****no padrão monorepo, possam ser atualizados utilizando a esteira de automação do Openshift.

3.2. Desenvolvimento

Para a execução dos projetos na esteira de automação, é necessário configurar um Dockerfile. Para atender a necessidade dos projetos, criaremos na raiz do projeto o arquivo Dockerfile, com o seguinte conteúdo:

Além do Dockerfile, também será necessário realizar as configurações relativas ao GitLab. Para isso iremos criar o arquivo .gitlab-ci.yml na raiz do projeto, e configurar conforme abaixo.

.job-common:
  stage: deploy
  only:
    refs:
      - development
      - staging
      - production
  trigger:
    include:
      - project: ci-cd/templates
        ref: production
        file:
          - "deploy.openshift.yml"
          - "variables.yml"
    strategy: depend

stages:
  - deploy

variables:
  PROJECT_DISPLAY_NAME: "${PROJECT_NAME}"

  DOCKERFILE_PATH: "Dockerfile"
  DOCKERFILE_CONTEXT: "/"

  ROUTER_PORT: "3000"
  ROUTER_TERMINATION: "edge"

  DEPLOY_ENVIRONMENT: >
    "TZ=America/Porto_Velho"

  BUILD_ENVIRONMENT_FILE: "packages/${APP_PATH}/.env.${CI_COMMIT_REF_NAME}"

Para cada projeto do monorepo, um novo job deverá ser adicionado com configurações específicas de cada projeto. Os jobs terão a seguinte estrutura:

nome-job:
  extends: .job-common
  only:
    changes:
      - "packages/caminho/relativo/**/*"
      - "packages/common/**/*"
      - ".gitlab-ci.yml"
      - "Dockerfile"
      - "package.json"
      - "yarn.lock"
  variables:
    APP_PATH: caminho/relativo
    PROJECT_NAME: nome-projeto

Exemplo de um .gitlab-ci.yml com todas as configurações necessárias:

.job-common:
  stage: deploy
  only:
    refs:
      - development
      - staging
      - production
  trigger:
    include:
      - project: ci-cd/templates
        ref: production
        file:
          - "deploy.openshift.yml"
          - "variables.yml"
    strategy: depend

stages:
  - deploy

variables:
  PROJECT_DISPLAY_NAME: "${PROJECT_NAME}"

  DOCKERFILE_PATH: "Dockerfile"
  DOCKERFILE_CONTEXT: "/"

  ROUTER_PORT: "3000"
  ROUTER_TERMINATION: "edge"

  DEPLOY_ENVIRONMENT: >
    "TZ=America/Porto_Velho"

  BUILD_ENVIRONMENT_FILE: "packages/${APP_PATH}/.env.${CI_COMMIT_REF_NAME}"

almoxarifado-estoque:
  extends: .job-common
  only:
    changes:
      - "packages/almoxarifado/estoque/**/*"
      - "packages/common/**/*"
      - ".gitlab-ci.yml"
      - "Dockerfile"
      - "package.json"
      - "yarn.lock"
  variables:
    APP_PATH: almoxarifado/estoque
    PROJECT_NAME: eestado-almoxarifado-estoque

Após isso, sempre que houver alterações nas branches development, staging e production, os projetos dentro do monorepo que sofreram alguma alteração que afete o funcionamento da aplicação serão atualizados.

4.3. Conclusão

A partir do estudo realizado foi possível identificar e implementar a melhor forma de se configurar projetos Node.js, que seguem o padrão monorepo, na esteira de automação do Openshift.

5.4. Referências

[1] Product Direction - Monorepos. Disponível em: https://about.gitlab.com/direction/monorepos. 
[2] Parent-child pipelines. Disponível em: https://docs.gitlab.com/ee/ci/pipelines/parent_child_pipelines.html. 
[3] Keyword reference for the .gitlab-ci.yml file. Disponível em: https://docs.gitlab.com/ee/ci/yaml. 
[4] How to set up monorepo build in GitLab CI. Disponível em: https://how-to.dev/how-to-set-up-monorepo-build-in-gitlab-ci. 
[5] Dockerfile reference. Disponível em: https://docs.docker.com/engine/reference/builder.