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: Cópia de todos os arquivos necessários ao pacote para o destino (ex: relatórios, scripts de banco, etc); Compilação do server; Compilação do cliente; Geração do pacote opkg; Geração do pacote entregável contendo o opkg; [Opcional - pode ser feito em etapa sepada ao build] Cópia do pacote de entrega para o diretório na rede: \\srp1vp1\Publico\Pacotes\. [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 Chamar o openapi-generator para gerar o codigo do pacote npm que está sendo criado Instalar e buildar o pacote (npi i + npm run build) 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.