Ir para o conteúdo principal

Impacto da nova API Calendário nos sitemas da CODE

OBJETIVO

Definir aestratégia configuraçde implementação maisda adequadanova paraapi quenos sejasistemas possíveldesenvolvidos executare/ou namantidos esteirapela Coordenadoria de automação do Openshift os projetos Node.js que seguem o padrão monorepo.Desenvolvimento.

JUSTIFICATIVA

AutomatizarEvitar afalha atualização dasnas aplicações Node.jsdevido quea seguemdescontinuidade oprogramada padrãoda monorepoAPI e-Estado1, evitando possíveis erros humanos. Além de diminuir, significativamente, o tempo para atualizar as aplicações que seguem esse padrão.. 

RESULTADOS ESPERADOS

É esperado que os projetos Node.js, ****no padrãExposição monorepo,dos possamriscos sere atualizados utilizando a esteiraestratégia de automaçimplementação dona troca da da OpenshiftAPI e-Estado pela API Calendário.

ENVOLVIDOS
  • Assessor:
    • Diego Gonçalves de Almeida.Almeida; e,
    • Igor Ramos de Oliveira.
  • Equipe Técnica:
    • Diego Barros de Oliveira;
    • Alef Carvalho da Silva;
    • Anderson Soares Cardoso; e,
    • Igor Ramos de Oliveira.Cardoso.
  • Gerente de Desenvolvimento:
    • Janderson de Castro Thomaz.
  • Product Owner:
    • Jônatas Justiniano Lima.
  • Scrum Master:
    • Wagner Moreira Melo.
GLOSSÁRIO
  • MonorepoAPI - É uma estrutura de projeto onde é possível ter várias aplicações no mesmo repositório.
  • Openshift - Ferramenta para gerenciamento containers.
  • ContainerResposta - Ambiente pré-configurado para atender a execução de um sistema específico.
  • Dockerfile - Arquivo que define como o container será construído.
  • Node.js - Ambiente para execução de aplicações desenvolvidas com JavaScript.
  • JavascriptEndpoint - Linguagem.
    • de
  • Objeto programaçJson - ,
  • Label Json - .
  • Desserialização para desenvolvimento de sistemas.
  • GitLab - Gerenciador de repositórios.
  • Job - Configuração do que será feito durante a execução da esteira de automação.
  • Branch - Ramificação dentro do repositório do código da aplicação..
DESENVOLVIMENTO

Para 

API e-Estado - a execuçantiga

Atualmente a API e-Estado tem um endpoint que retorna os feriados cadastrados no e-Estado.

O endpoint é GET ​/api​/feriados​/mes​/{mes}​/ano​/{ano} retornava uma lista de objetos como que se observa abaixo:

[
  {
    "id": 158,
    "municipioId": 5582,
    "data": "2022-05-24T00:00:00",
    "horaInicial": "",
    "horaFinal": "",
    "calendario": "Padroeira dos municípios Nossa Senhora Auxiliadora",
    "municipio": "Porto Velho"
  },
  {
    "id": 158,
    "municipioId": 5587,
    "data": "2022-05-24T00:00:00",
    "horaInicial": "",
    "horaFinal": "",
    "calendario": "Padroeira dos municípios Nossa Senhora Auxiliadora",
    "municipio": "Vilhena"
  },
  {
    "id": 158,
    "municipioId": 5592,
    "data": "2022-05-24T00:00:00",
    "horaInicial": "",
    "horaFinal": "",
    "calendario": "Padroeira dos municípios Nossa Senhora Auxiliadora",
    "municipio": "Alto Paraíso"
  },
  {
    "id": 154,
    "municipioId": 0,
    "data": "2022-05-01T00:00:00",
    "horaInicial": "",
    "horaFinal": "",
    "calendario": "Dia Mundial do Trabalho",
    "municipio": null
  }
]

Note que para eventos com abragência municipal é retornado um objeto de evento para cada município. Na lista acima, o evento ID = 158 é municipal e para cada município (Porto Velho, Vilhena, Alto Paraíso) é retornado um objeto com o mesmo ID.

Todavia, nos eventos estaduais, para cada evento será retornado um objeto, porém os rótulos "municipioId" terão valor 0 e os rótulos "municipio" terão valor null. Exemplo.

[
{
"id": 154,
"municipioId": 0,
"data": "2022-05-01T00:00:00",
"horaInicial": "",
"horaFinal": "",
"calendario": "Dia Mundial do Trabalho",
"municipio": null
}
]

Já nos demais rótulos do objeto tem os seguintes valores:

"id": o ID do evento,
"data": a data do evento em formato "yyyy-mm-ddT00:00:00",
"horaInicial": sempre vazio (""),
"horaFinal": sempre vazio (""),
"calendario": nome do evento, por exemplo, "Padroeira dos municípios Nossa Senhora Auxiliadora".

 

API Calendário - a nova

A API Calendário foi desenvolvida com tecnologias A B C, sendo portanto mais segura, estando no OpenShift o que faciltia mais sua manutenção.

Deste modo, ela será a substituta do endpoint de Feriados da API e-Estado que está programa para ser descontinuada por obsolecência.

Para evitar grandes ajustes nos sistemas que já consomem o endpoint da API e-Estado, um endpoint, com o mesmo padrão de resposta, na API foi criado; a desserialização dos projetosobjetos na esteira de automação, é necessário configurar um Dockerfile. Para atendercontinuará a necessidademesma.

dos

No projetos,entanto criaremosserá napreciso raizalterar doa projetourl que apontava para API e-Estado para a nova api, API Calendário; sendo este, basicamente, o arquivoúnico Dockerfile,trabalho com o seguinte conteúdo:

image-1645028812183.png

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 funcionamentodecorrente da aplicação serão atualizados.mudança;

CONCLUSÃO

A partir do estudo realizado foi possível identificar eque implementarnão haverá nenhum impacto na mundança da API e-Estado para a melhorAPI formaCalendário, desenão seaquele configurardecorrente projetosda Node.js,troca da URL, visto que seguema nova já traz um endpoint igual à antiga e com o mesmo padrão monorepo, na esteira de automação do Openshift.resposta.

REFERÊNCIAS

[1] ProductAPI Directione-Estado - Monorepos.Documentação. Disponívelvel, internamente à intranet da SETIC, em:  https://about.gitlab.com/direction/monorepos. Acesso em: 10 fev 2022.
[2] Parent-child pipelines. Disponível em: https://docs.gitlab.com/ee/ci/pipelines/parent_child_pipelines.e-estado-api.master.local/swagger/index.html. Acesso em: 10 fev 2022.
[3] Keyword reference for the .gitlab-ci.yml file. Disponível em: https://docs.gitlab.com/ee/ci/yaml. Acesso em: 10 fev 2022.
[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. Acesso em: 10 fev 2022.
[5] Dockerfile reference. Disponível em: https://docs.docker.com/engine/reference/builder. Acesso em: 1021 fev 2022.

Voltar ao topo