Info
Content

Arquivo de configuração do CI para nossos projetos

Introdução

Hoje temos o build automático de algumas peças de software:

  • server curio
  • server + cliente curio
  • server java
  • api (geração de pacote npm através de arquivo api specs)
  • web em react
  • ios em react native
  • ios nativo
  • android em react native
  • android nativo

Precisamos que, sempre que um projeto for criado, independente que qual tecnologia o projeto use, o CI venha devidamente configurado.

Idealmente, pelo menos 2 etapas devem ser sempre realizadas pelo CI:

  • A cada commit é desejado que seja realizado o build de cada peça do software.
  • Quando uma tag é inserida no git, é desejado que seja realizado o build + delivery + deploy daaa peça de software cuja tag foi inserida.

Exemplo: Em um projeto de app react native com server curio, a cada commit ambos apps iOS e Android seriam buildados e o server curio também seria buildado. Se a tag srv/1.0.0.0 for inserida, apenas o server curio seria buildado com a versão 1.0.0.0, e entregue pelo orquestra (por exemplo). Se a tag ios/1.0.0 for inserida, o CI faria o build e upload para a app store da versão 1.0.0 do app iOS.

Nota: Na prática não realizamos o build dos apps a cada build por problemas de performance.

Projeto Curio

Pré-requisitos

  • Windows
  • Python 3
  • Ter baixado o repositório ambiente-de-build do git

Repositório ambiente-de-build

Este repositório foi criado no intuito de armazenar todos os arquivos e dependências necessárias para o build de um projeto Curiò.

Nele estão armazenados: arquivos do delphi para compilação via linha de comando sem precisar instalar o delphi na máquina, dcu's do Curiò, arquivos exe utilizados no build, scripts que podem ser utilizados pelo CI, entre outros.

Processo de Build

Para o build e geração do pacote entregável de projetos Curiò, criamos um script em python para realizar todo o processo, que normalmente consiste nas etapas:

  1. Cópia de todos os arquivos necessários ao pacote para o destino (ex: relatórios, scripts de banco, etc);
  2. Compilação do server;
  3. Compilação do cliente;
  4. Geração do pacote opkg;
  5. Geração do pacote entregável contendo o opkg;
  6. [Opcional - pode ser feito em etapa sepada ao build] Cópia do pacote de entrega para o diretório na rede: \\srp1vp1\Publico\Pacotes\.
  7. [Opcional - pode ser feito em etapa sepada ao build] Envio do opkg ao orquestra.

Porém, antes de realizar o build, geramos o arquivo de configuração do sistema (integração com o SiSCON) e testamos (através desse arquivo) se todas as mensagens de erro foram cadastradas no SISCON e se todos os itens de menu estão presentes no sistema.

Diretrizes para Script GitLab CI

Gerar o arquivo .xml do SISCON:
Executar o script python generate_system_xml_config.py que está no ambiente-de-build.

Verificar mensagens cadastradas:
Executar o comando verificadorMsg no terminal, que deve estar previamente instalado na máquina (ver projeto no git).

Verificar itens de menu:
Executar o programa VerificadorMenu.exe que está no ambiente-de-build (ver projeto no git)..

Realizar o Build e gerar pacote entregável:
Executar o script python de build do projeto.

Copiar pacote entregável para pasta na rede:
Executar o script python compress_file.py que está no ambiente-de-build.

Enviar o opkg para o Orquestra:
Executar o script python de build do projeto.

Server Java

...

API

Utilizamos o openapi-generator para, a partir do specs da API, gerar um pacote npm que será utilizado pelo front-end para chamar a API. O build da api, usa essa ferramenta para gerar o pacote. O deploy da API se faz publicando o pacote npm gerado no repositório interno nexus da empresa.

Pré-requisitos

  • node / npm
  • npx
  • openapi-generator
  • json (utilizamos esse utilitário npm para modificar um arquivo json por linha de comando)

Processo de Build

  1. Chamar o openapi-generator para gerar o codigo do pacote npm que está sendo criado
  2. Instalar e buildar o pacote (npi i + npm run build)
  3. publicar o pacote no nexus

Diretrizes para Script GitLab CI

script:
  # Gerar pacote npm
  - cd $API_PATH
  - npx openapi-generator generate -i microcredito.service.yaml -g typescript-fetch --additional-properties $API_ADDITIONAL_PROPERTIES -o $API_OUTPUT_DIR --model-name-suffix ApiModel
  # Alterar arquivos do pacote
  - cd $API_OUTPUT_DIR
  - ls
  - echo "init.author.name = admin" > .npmrc
  - echo "init.author.email = suporte@evologica.com.br" >> .npmrc
  - echo "email=suporte@evologica.com.br" >> .npmrc
  - echo "" >> .npmrc
  - echo "always-auth=true" >> .npmrc
  - echo "_auth=YWRtaW46amo1OFBkMDI=" >> .npmrc
  - json -I -f package.json -e "this.files=['dist']"
  # Instalar e publicar novo pacote
  - npm i
  - npm run build
  - npm publish

Web em React

Em alguns casos, o CI pode apenas fazer o build e disponibilizar o arquivo dist como artefato do build. Em outros casos, pode fazer o build, criar um docker e fazer o deploy do docker. Ou pode fazer o build, e subir um docker padrão com o dist dentro.

Pré-requisitos

  • node / npm / yarn

iOS em React Native

Pré-requisitos

  • Mac OS / XCode
  • Fastlane (utiliza ruby)
  • Node / npm / yarn
  • json (utilizamos esse utilitário npm para modificar um arquivo json por linha de comando)

Processo de Build

Para o build e envio do app para a App Store, utilizamos a ferramenta do google fastlane. O script CI deste app só precisa fazer a chamada ao fastlane. É no fastlane que fica a configuração de build do aplicativo.

Diretrizes para configuração do Fastlane

Criar o diretório fastlane dentro da pasta ios contendo os arquivos:

  • Pluginfile: contém os plugins utilizados no fastfile
  • Appfile: Contém dados do app + dados da loja (ex: app id, email utilizado no apple connect)
  • Fastfile: Contém o script de build

Como executar o fastlane:
No diretório ios, executar a linha de comando: bundle exec fastlane.

Diretrizes para Script GitLab CI

O script padrão no arquivo do GItLab CI ficaria:

script:
    - cd ${PATH_APPS}/
    - json -I -f package.json -e "this.version='$Version'"
    - yarn
    - cd ios
    - pod install
    - bundle install
    - bundle exec fastlane beta version_number:$MajorVersion build_number:$BuildNumber release_notes:"$TagMessage"
  after_script:
    - killall -9 node
    - rm -rf ${PATH_APPS}/node_modules
    - rm -rf ${PATH_APPS}/ios/Pods

Onde as variáveis PATH_APPS, MajorVersion, BuildNumber, TagMessage, devem estar previamente setadas.

iOS Nativo

Segue o mesmo padrão do iOS React Native, mas não precisa de yarn/npm.

Android em React Native

Pré-requisitos

  • Android Studio ou Android SDK
  • Fastlane (usa ruby)
  • node / yarn
  • json (utilizamos esse utilitário npm para modificar um arquivo json por linha de comando)

Processo de Build

Para o build e envio do app para a Play Store, utilizamos a ferramenta do google fastlane. O script CI deste app só precisa fazer a chamada ao fastlane. É no fastlane que fica a configuração de build do aplicativo.

Diretrizes para configuração do Fastlane

Criar o diretório fastlane dentro da pasta ios contendo os arquivos:

  • api.json: Contém dados da API Google para publicação do App
  • Pluginfile: Contém os plugins utilizados no fastfile
  • Appfile: Contém dados do app + dados da loja (ex: app id, email utilizado no apple connect)
  • Fastfile: Contém o script de build

Como executar o fastlane:
No diretório android, executar a linha de comando: bundle exec fastlane.

Diretrizes para Script GitLab CI

O script padrão no arquivo do GItLab CI ficaria:

script:
  - cd ${PATH_APPS}/
  - json -I -f package.json -e "this.version='$Version'"
  - yarn
  - cd android && chmod +x gradlew
  - bundle install
  - bundle exec fastlane android publish version_name:$Version track:"internal"
after_script:
  - rm -rf ${PATH_APPS}/node_modules
  - mv ${PATH_APPS}/android/app/build/outputs/bundle/release/app-release.aab app-${PACKAGE_APP_NAME}-$Version.aab

Onde as variáveis PATH_APPS, Version, PACKAGE_APP_NAME, devem estar previamente setadas.

Android Nativo

Segue o mesmo padrão do Android React Native, mas não precisa de yarn/npm.

Variáveis que podem ficar no gitlab

Levantamos algumas variáveis que são utilizadas nos builds que podem variar de projeto para projeto, e por isso, é recomendado que fiquem armazenadas no GitLab (Em projeto -> Settings -> CI/CD -> Environment variables). Mais variáveis podem aparecer dependendo do projeto.

No Comments
Back to top