Pesquisar

[Nesta série de artigos](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-índice), quero apresentar e discutir várias abordagens possíveis para o desenvolvimento de software com tecnologias da InterSystems e do GitLab. Vou cobrir tópicos como: * Git básico * Fluxo Git (processo de desenvolvimento) * Instalação do GitLab * Fluxo de trabalho do GitLab * Entrega contínua * Instalação e configuração do GitLab * CI/CD do GitLab * Por que contêineres? * Infraestrutura dos contêineres * CD usando contêineres * **CD usando ICM** Neste artigo, vamos desenvolver a entrega contínua com o InterSystems Cloud Manager. O ICM é uma solução de provisionamento e implantação na nuvem para aplicativos baseados no InterSystems IRIS. Ele permite definir a configuração de implantação desejada e o ICM provisiona de maneira automática. Para mais informações, consulte [First Look: ICM](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=AFL_icm). Fluxo de trabalho Na nossa configuração de entrega contínua: * Enviamos código para o repositório do GitLab * Criamos a imagem docker * Publicamos a imagem no registro docker * Testamos em um servidor de teste * Se os testes forem aprovados, implantamos em um servidor de produção Ou em formato gráfico: Como você pode ver, é praticamente igual, exceto que usaríamos o ICM em vez de gerenciar os contêineres do Docker manualmente. ## Configuração do ICM Antes de atualizar os contêineres, eles devem ser provisionados. Para isso precisamos definir defaults.json e definitions.json, descrevendo nossa arquitetura. Vou fornecer esses 2 arquivos para um servidor LIVE, as definições para um servidor TEST são as mesmas, e os padrões são os mesmos, exceto para os valores Tag e SystemMode. #### defaults.json: { "Provider": "GCP", "Label": "gsdemo2", "Tag": "LIVE", "SystemMode": "LIVE", "DataVolumeSize": "10", "SSHUser": "sample", "SSHPublicKey": "/icmdata/ssh/insecure.pub", "SSHPrivateKey": "/icmdata/ssh/insecure", "DockerImage": "eduard93/icmdemo:master", "DockerUsername": "eduard93", "DockerPassword": "...", "TLSKeyDir": "/icmdata/tls", "Credentials": "/icmdata/gcp.json", "Project": "elebedyu-test", "MachineType": "n1-standard-1", "Region": "us-east1", "Zone": "us-east1-b", "Image": "rhel-cloud/rhel-7-v20170719", "ISCPassword": "SYS", "Mirror": "false" } #### definitions.json [ { "Role": "DM", "Count": "1", "ISCLicense": "/icmdata/iris.key" } ] Dentro do contêiner ICM, a pasta /icmdata é montada a partir do host e: * As definições do servidor TEST são colocadas na pasta /icmdata/test * As definições do servidor LIVE são colocadas na pasta /icmdata/live Depois de obter todas as chaves necessárias: keygenSSH.sh /icmdata/ssh keygenTLS.sh /icmdata/tls E colocar os arquivos necessários em /icmdata: * iris.key * gcp.json (para a implantação no Google Cloud Platform) Chame o ICM para provisionar suas instâncias: cd /icmdata/test icm provision icm run cd /icmdata/live icm provision icm run Um servidor TEST e um servidor LIVE seriam provisionados com uma instância do InterSystems IRIS independente em cada um. Consulte [ICM First Look](http://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=AFL_icm) para ver um guia mais detalhado. Criação Primeiro, precisamos criar nossa imagem. Nosso código seria, como sempre, armazenado no repositório, a configuração de CD em gitlab-ci.yml. No entanto, além disso (para aumentar a segurança), armazenaríamos vários arquivos específicos do servidor em um servidor de compilação. #### iris.key Chave de licença. Como alternativa, ela pode ser baixada durante a compilação do contêiner em vez de armazenada em um servidor. É bastante arriscado armazenar no repositório. pwd.txt Arquivo contendo a senha padrão. Novamente, é bastante arriscado armazená-lo no repositório. Além disso, se você estiver hospedando um ambiente de produção em um servidor separado, ele poderá ter uma senha padrão diferente. load_ci_icm.script O script inicial: * Carrega o instalador * O instalador inicializa o aplicativo * Carrega o código set dir = ##class(%File).NormalizeDirectory($system.Util.GetEnviron("CI_PROJECT_DIR")) do ##class(%SYSTEM.OBJ).Load(dir _ "Installer/Global.cls","cdk") do ##class(Installer.Global).init() halt Observe que a primeira linha é deixada em branco de maneira intencional. Várias coisas diferem dos exemplos anteriores. Em primeiro lugar, não habilitamos a autenticação do SO, pois o ICM interagiria com o contêiner em vez do GitLab diretamente. Segundo, estou usando o manifesto do instalador para inicializar nosso aplicativo para mostrar diferentes abordagens de inicialização. Leia mais sobre o Instalador [neste artigo](https://community.intersystems.com/post/deploying-applications-intersystems-cache-installer). Por fim, publicaremos nossa imagem em um Docher Hub como um repositório privado. ####   #### Installer/Global.cls Nosso manifesto do instalador fica desta forma: E implementa as seguintes mudanças: 1. Cria o namespace do aplicativo. 2. Cria o banco de dados de código do aplicativo (os dados seriam armazenados no banco de dados USER). 3. carrega o código no banco de dados de código do aplicativo. 4. Mapeia o pacote MyApp para o namespace USER. 5. Cria dois aplicativos para a Web: para HTML e para REST. gitlab-ci.yml Agora, para a configuração da entrega contínua: build image: stage: build tags: - master script: - cp -r /InterSystems/mount ci - cd ci - echo 'SuperUser' | cat - pwd.txt load_ci_icm.script > temp.txt - mv temp.txt load_ci.script - cd .. - docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t eduard93/icmdemo:$CI_COMMIT_REF_NAME . O que está acontecendo aqui? Primeiro, como o [docker build](https://docs.docker.com/engine/reference/commandline/build/) pode acessar apenas subdiretórios de um diretório de compilação base — na raiz do repositório do nosso caso, precisamos copiar nosso diretório "secreto" (aquele com iris.key, pwd.txt e load_ci_icm.script) no repositório clonado. Em seguida, o primeiro acesso ao terminal requer um usuário/senha, então nós os adicionamos a load_ci.script (por isso a linha vazia no início de load_ci.script). Por fim, criamos a imagem do docker e a marcamos adequadamente:  eduard93/icmdemo:$CI_COMMIT_REF_NAME onde $CI_COMMIT_REF_NAME é o nome de um branch atual. Observe que a primeira parte da tag de imagem deve ter o mesmo nome do nome do projeto no GitLab, para que possa ser vista na guia GitLab Registry (instruções sobre a marcação estão disponíveis na guia Registry). Dockerfile A criação de uma imagem docker é feita usando o [Dockerfile](https://docs.docker.com/engine/reference/builder/): FROM intersystems/iris:2018.1.1-released ENV SRC_DIR=/tmp/src ENV CI_DIR=$SRC_DIR/ci ENV CI_PROJECT_DIR=$SRC_DIR COPY ./ $SRC_DIR RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \ && iris start $ISC_PACKAGE_INSTANCENAME \ && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \ && iris stop $ISC_PACKAGE_INSTANCENAME quietly Começamos a partir do contêiner básico iris. Primeiro, copiamos nosso repositório (e diretório "secreto") dentro do contêiner. Em seguida, copiamos a chave de licença para o diretório mgr. Em seguida, alteramos a senha para o valor de pwd.txt. Observe que pwd.txt é excluído nessa operação. Depois disso, a instância é iniciada e load_ci.script é executado. Por fim, a instância iris é interrompida. Estou usando o [executor GitLab Shell](https://docs.gitlab.com/runner/executors/), e não o executor Docker. O executor Docker é usado quando você precisa de algo de dentro da imagem, por exemplo, você está criando um aplicativo Android em um contêiner java e precisa apenas de um apk. No nosso caso, precisamos de um contêiner inteiro e, para isso, precisamos do executor Shell. Então, estamos executando comandos do Docker pelo executor GitLab Shell. ## Publicar Agora, vamos publicar nossa imagem em um Docker Hub publish image: stage: publish tags: - master script: - docker login -u eduard93 -p ${DOCKERPASSWORD} - docker push eduard93/icmdemo:$CI_COMMIT_REF_NAME Observe a variável ${DOCKERPASSWORD}, é uma [variável secreta](https://docs.gitlab.com/ee/ci/variables/#protected-variables) do GitLab. Podemos adicioná-la em GitLab > Project > Settings > CI/CD > Variables:  Os logs de job também não contêm valor de senha: Running with gitlab-runner 10.6.0 (a3543a27) on icm 82634fd1 Using Shell executor... Running on docker... Fetching changes... Removing ci/ HEAD is now at 8e24591 Add deploy to LIVE Checking out 8e245910 as master... Skipping Git submodules setup $ docker login -u eduard93 -p ${DOCKERPASSWORD} WARNING! Using --password via the CLI is insecure. Use --password-stdin. Login Succeeded $ docker push eduard93/icmdemo:$CI_COMMIT_REF_NAME The push refers to repository [docker.io/eduard93/icmdemo] master: digest: sha256:d1612811c11154e77c84f0c08a564a3edeb7ddbbd9b7acb80754fda97f95d101 size: 2620 Job succeeded e no Docker Hub podemos ver nossa nova imagem:    Executar Temos nossa imagem, agora vamos executá-la em nosso servidor de teste. Aqui está o script. run image: stage: run environment: name: $CI_COMMIT_REF_NAME tags: - master script: - docker exec icm sh -c "cd /icmdata/test && icm upgrade -image eduard93/icmdemo:$CI_COMMIT_REF_NAME" Com o ICM, precisamos executar apenas um comando ([icm upgrade](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GICM_using#GICM_using_deploy_manage_icmupgrade)) para fazer upgrade da implantação existente. Estamos chamando-a executando "docker exec icm sh -c ", que executa um comando especificado dentro do contêiner icm.  Primeiro, entramos no modo /icmdata/test, onde a definição da implantação do ICM é configurada para um servidor TEST. Depois disso, chamamos icm upgrade para substituir o contêiner existente por um novo contêiner. ## Teste Vamos fazer alguns testes. test image: stage: test tags: - master script: - docker exec icm sh -c "cd /icmdata/test && icm session -namespace USER -command 'do \$classmethod(\"%UnitTest.Manager\",\"RunTest\",\"MyApp/Tests\",\"/nodelete\")' | tee /dev/stderr | grep 'All PASSED' && exit 0 || exit 1" Novamente, estamos executando um comando dentro do nosso contêiner icm. A sessão icm executa um comando em um nó implantado. O comando executa testes de unidade. Depois disso, ele canaliza todos os resultados para a tela e também para o grep para encontrar os resultados dos testes de unidade e sair do processo com sucesso ou com um erro. ## Implantar A implantação em um servidor de produção é absolutamente igual à implantação em teste, exceto por outro diretório para a definição da implantação LIVE. Se os testes falhassem, essa etapa não seria executada. deploy image: stage: deploy environment: name: $CI_COMMIT_REF_NAME tags: - master script: - docker exec icm sh -c "cd /icmdata/live && icm upgrade -image eduard93/icmdemo:$CI_COMMIT_REF_NAME" Conclusão O ICM oferece uma maneira simples e intuitiva de provisionar uma infraestrutura na nuvem e implantar serviços nela, ajudando você a entrar na nuvem<nobr>agora</nobr> sem grande desenvolvimento ou reorganização. Os benefícios da infraestrutura como código (IaC) e da implantação em contêiner facilitam a implantação de aplicativos baseados no InterSystems IRIS em plataformas de nuvem públicas, como Google, Amazon e Azure, ou na sua nuvem privada VMware vSphere. Defina o que você quer, emita alguns comandos e o ICM faz o resto. Mesmo se você já estiver usando infraestrutura de nuvem, contêineres ou ambos, o ICM reduz drasticamente o tempo e o esforço necessários para provisionar e implantar seu aplicativo automatizando várias etapas manuais. Links * [Código do artigo](https://github.com/intersystems-ru/GitLab/tree/master/icm) * [Projeto de teste](http://gitlab.eduard.win/test/docker) * [Documentação do ICM](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GICM) * [First Look: ICM](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GICM_using)

Nesta série de artigos, quero apresentar e discutir várias abordagens possíveis para o desenvolvimento de software com tecnologias da InterSystems e do GitLab. Vou cobrir tópicos como: * Git básico * Fluxo Git (processo de desenvolvimento) * Instalação do GitLab * Fluxo de trabalho do GitLab * Entrega contínua * Instalação e configuração do GitLab * CI/CD do GitLab * Por que contêineres? * Infraestrutura dos contêineres * **CD usando contêineres** No [primeiro artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-i-git), abordamos os fundamentos do Git, por que um entendimento de alto nível dos conceitos do Git é importante para o desenvolvimento de software moderno e como o Git pode ser usado para desenvolver software. No [segundo artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-ii-fluxo-de-trabalho-do), abordamos o fluxo de trabalho do GitLab: um processo inteiro do ciclo de vida do software e a entrega contínua. No [terceiro artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-iii-instalação-e), abordamos a instalação e configuração do GitLab e a conexão dos seus ambientes a ele No [quarto artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-iv-configuração-da-cd), escrevemos uma configuração de CD. No [quinto artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-v-por-que-contêineres), falamos sobre contêineres e como (e por que) eles podem ser usados. No [sexto artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-vi-infraestrutura-dos), vamos discutir os principais componentes necessários para executar um pipeline de entrega contínua com contêineres e como eles trabalham juntos. Neste artigo, criaremos a configuração de entrega contínua discutida nos artigos anteriores. ## ## Fluxo de trabalho Na nossa configuração de entrega contínua: * Enviamos código para o repositório do GitLab * Criamos a imagem docker * Testamos * Publicamos a imagem no nosso registro docker * Trocamos o contêiner antigo pela nova versão do registro Ou em formato gráfico: Vamos começar. ## Criação Primeiro, precisamos criar nossa imagem. Nosso código seria, como sempre, armazenado no repositório, a configuração de CD em gitlab-ci.yml. No entanto, além disso (para aumentar a segurança), armazenaríamos vários arquivos específicos do servidor em um servidor de compilação. #### GitLab.xml Contém o código dos hooks de CD. Foi desenvolvido no [artigo anterior](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-iv-configuração-da-cd) e disponibilizado no [GitHub](https://github.com/intersystems-ru/GitLab/releases). É uma pequena biblioteca para carregar código, executar vários hooks e testar código. Como alternativa preferencial, você pode usar [submódulos git](https://git-scm.com/book/en/v2/Git-Tools-Submodules) para incluir este projeto ou algo semelhante no seu repositório. Os submódulos são melhores porque é mais fácil mantê-los atualizados. Uma outra alternativa seria marcar as versões no GitLab e carregá-las com o comando [ADD](https://docs.docker.com/engine/reference/builder/#add). #### iris.key Chave de licença. Como alternativa, ela pode ser baixada durante a compilação do contêiner em vez de armazenada em um servidor. É bastante arriscado armazenar no repositório. #### pwd.txt Arquivo contendo a senha padrão. Novamente, é bastante arriscado armazená-lo no repositório. Além disso, se você estiver hospedando um ambiente de produção em um servidor separado, ele poderá ter uma senha padrão diferente. #### load_ci.script O script inicial: * Ativa a autenticação do SO * Carrega GitLab.xml * Inicializa as configurações do utilitário GitLab * Carrega o código set sc = ##Class(Security.System).Get("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) set AutheEnabled = Properties("AutheEnabled") set AutheEnabled = $zb(+AutheEnabled,16,7) set Properties("AutheEnabled") = AutheEnabled set sc = ##Class(Security.System).Modify("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) zn "USER" do ##class(%SYSTEM.OBJ).Load(##class(%File).ManagerDirectory() _ "GitLab.xml","cdk") do ##class(isc.git.Settings).setSetting("hooks", "MyApp/Hooks/") do ##class(isc.git.Settings).setSetting("tests", "MyApp/Tests/") do ##class(isc.git.GitLab).load() halt Observe que a primeira linha é deixada em branco de maneira intencional. Como algumas configurações podem ser específicas do servidor, elas não são armazenadas no repositório, mas separadamente. Se o hook inicial for sempre o mesmo, você pode simplesmente armazená-lo no repositório. #### gitlab-ci.yml Agora, para a configuração da entrega contínua: build image: stage: build tags: - test script: - cp -r /InterSystems/mount ci - cd ci - echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt - mv temp.txt load_ci.script - cd .. - docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.domain.com/test/docker:$CI_COMMIT_REF_NAME . O que está acontecendo aqui? Primeiro, como o [docker build](https://docs.docker.com/engine/reference/commandline/build/) pode acessar apenas subdiretórios de um diretório de compilação base — na raiz do repositório do nosso caso, precisamos copiar nosso diretório "secreto" (aquele com GitLab.xml, iris.key, pwd.txt e load_ci.script) no repositório clonado. Em seguida, o primeiro acesso ao terminal requer um usuário/senha, então nós os adicionamos a load_ci.script (por isso a linha vazia no início de load_ci.script). Por fim, criamos a imagem do docker e a marcamos adequadamente: docker.domain.com/test/docker:$CI_COMMIT_REF_NAME onde $CI_COMMIT_REF_NAME é o nome de um branch atual. Observe que a primeira parte da tag de imagem deve ter o mesmo nome do nome do projeto no GitLab, para que possa ser vista na guia GitLab Registry (instruções sobre a marcação estão disponíveis na guia Registry). #### Dockerfile A criação da imagem docker é feita usando o [Dockerfile](https://docs.docker.com/engine/reference/builder/): FROM docker.intersystems.com/intersystems/iris:2018.1.1.611.0 ENV SRC_DIR=/tmp/src ENV CI_DIR=$SRC_DIR/ci ENV CI_PROJECT_DIR=$SRC_DIR COPY ./ $SRC_DIR RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \ && iris start $ISC_PACKAGE_INSTANCENAME \ && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \ && iris stop $ISC_PACKAGE_INSTANCENAME quietly Começamos a partir do contêiner básico iris. Primeiro, copiamos nosso repositório (e diretório "secreto") dentro do contêiner. Em seguida, copiamos a chave de licença e GitLab.xml para o diretório mgr. Em seguida, alteramos a senha para o valor de pwd.txt. Observe que pwd.txt é excluído nessa operação. Depois disso, a instância é iniciada e load_ci.script é executado. Por fim, a instância iris é interrompida. Veja o registro do job (parcial, os registros de carregamento/compilação foram ignorados): Running with gitlab-runner 10.6.0 (a3543a27) on docker 7b21e0c4 Using Shell executor... Running on docker... Fetching changes... Removing ci/ Removing temp.txt HEAD is now at 5ef9904 Build load_ci.script From http://gitlab.eduard.win/test/docker 5ef9904..9753a8d master -> origin/master Checking out 9753a8db as master... Skipping Git submodules setup $ cp -r /InterSystems/mount ci $ cd ci $ echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt $ mv temp.txt load_ci.script $ cd .. $ docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME . Sending build context to Docker daemon 401.4kB Step 1/6 : FROM docker.intersystems.com/intersystems/iris:2018.1.1.611.0 ---> cd2e53e7f850 Step 2/6 : ENV SRC_DIR=/tmp/src ---> Using cache ---> 68ba1cb00aff Step 3/6 : ENV CI_DIR=$SRC_DIR/ci ---> Using cache ---> 6784c34a9ee6 Step 4/6 : ENV CI_PROJECT_DIR=$SRC_DIR ---> Using cache ---> 3757fa88a28a Step 5/6 : COPY ./ $SRC_DIR ---> 5515e13741b0 Step 6/6 : RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt && iris start $ISC_PACKAGE_INSTANCENAME && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script && iris stop $ISC_PACKAGE_INSTANCENAME quietly ---> Running in 86526183cf7c . Waited 1 seconds for InterSystems IRIS to start This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement %SYS> 1 %SYS> Using 'iris.cpf' configuration file This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement 1 alert(s) during startup. See messages.log for details. Starting IRIS Node: 39702b122ab6, Instance: IRIS Username: Password: Load started on 04/06/2018 17:38:21 Loading file /usr/irissys/mgr/GitLab.xml as xml Load finished successfully. USER> USER> [2018-04-06 17:38:22.017] Running init hooks: before [2018-04-06 17:38:22.017] Importing hooks dir /tmp/src/MyApp/Hooks/ [2018-04-06 17:38:22.374] Executing hook class: MyApp.Hooks.Global [2018-04-06 17:38:22.375] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.375] Importing dir /tmp/src/ Loading file /tmp/src/MyApp/Tests/TestSuite.cls as udl Compilation started on 04/06/2018 17:38:22 with qualifiers 'c' Compilation finished successfully in 0.194s. Load finished successfully. [2018-04-06 17:38:22.876] Running init hooks: after [2018-04-06 17:38:22.878] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.921] Executing hook class: MyApp.Hooks.Global Removing intermediate container 39702b122ab6 ---> dea6b2123165 [Warning] One or more build-args [CI_PROJECT_DIR] were not consumed Successfully built dea6b2123165 Successfully tagged docker.domain.com/test/docker:master Job succeeded Estou usando o [executor GitLab Shell](https://docs.gitlab.com/runner/executors/), e não o executor Docker. O executor Docker é usado quando você precisa de algo de dentro da imagem, por exemplo, você está criando um aplicativo Android em um contêiner java e precisa apenas de um apk. No nosso caso, precisamos de um contêiner inteiro e, para isso, precisamos do executor Shell. Então, estamos executando comandos do Docker pelo executor GitLab Shell. ###   ### Executar Temos nossa imagem, agora vamos executá-la.  No caso de ramificações de recursos, podemos simplesmente destruir o contêiner antigo e iniciar o novo. No caso do ambiente, podemos executar um container temporário e substituir o contêiner do ambiente caso os testes tenham êxito (isso fica como um exercício para o leitor). Aqui está o script. destroy old: stage: destroy tags: - test script: - docker stop iris-$CI_COMMIT_REF_NAME || true - docker rm -f iris-$CI_COMMIT_REF_NAME || true Esse script destrói o contêiner em execução no momento e é sempre bem-sucedido (por padrão, o docker falha se tentar parar/remover um contêiner inexistente). Em seguida, iniciamos a nova imagem e a registramos como um ambiente. [Contêiner Nginx ](https://cloud.google.com/community/tutorials/nginx-reverse-proxy-docker) faz proxy automático de solicitações usando a variável de ambiente VIRTUAL_HOST e a diretiva de exposição (para saber em qual porta fazer o proxy). run image: stage: run environment: name: $CI_COMMIT_REF_NAME url: http://$CI_COMMIT_REF_SLUG. docker.domain.com/index.html tags: - test script: - docker run -d --expose 52773 --env VIRTUAL_HOST=$CI_COMMIT_REF_SLUG.docker.eduard.win --name iris-$CI_COMMIT_REF_NAME docker.domain.com/test/docker:$CI_COMMIT_REF_NAME --log $ISC_PACKAGE_INSTALLDIR/mgr/messages.log ###   ### Testes Vamos fazer alguns testes. test image: stage: test tags: - test script: - docker exec iris-$CI_COMMIT_REF_NAME irissession iris -U USER "##class(isc.git.GitLab).test()" ### Publicar Por fim, vamos publicar nossa imagem no registro publish image: stage: publish tags: - test script: - docker login docker.domain.com -u dev -p 123 - docker push docker.domain.com/test/docker:$CI_COMMIT_REF_NAME O usuário/código pode ser transmitido usando [variáveis secretas do GitLab](https://docs.gitlab.com/ee/ci/variables/#secret-variables). Agora, podemos ver a imagem no GitLab:  E outros desenvolvedores podem a extrair do registro. Na guia de ambientes, todos os ambientes estão disponíveis para a fácil navegação:    Conclusão Nessa série de artigos, discuti abordagens gerais de entrega contínua. É um tema extremamente vasto e essa série de artigos precisa ser vista mais como uma coleção de receitas do que algo definitivo. Se você deseja automatizar o desenvolvimento, os testes e a entrega do seu aplicativo, a entrega contínua em geral e o GitLab em particular é o melhor caminho. A entrega contínua e os contêineres permitem que você personalize seu fluxo de trabalho conforme necessário. ## Links * [Código do artigo](https://github.com/intersystems-ru/GitLab/tree/master/docker) * [Projeto de teste](http://gitlab.eduard.win/test/docker) * [Configuração de CD completa](https://github.com/intersystems-ru/GitLab/blob/master/docker/.gitlab-ci.yml) ## O que vem a seguir É isso. Espero que eu tenha abordado os conceitos básicos da entrega contínua e dos contêineres. Há vários tópicos sobre os quais não falei (talvez mais tarde), especialmente em relação a contêineres: * Os dados podem ser persistentes fora do contêiner. Veja a [documentação](http://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GICM_containers) relacionada. * Plataformas de orquestração como [kubernetes](https://kubernetes.io/) * [InterSystems Cloud Manager](http://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GICM_using) * Gerenciamento de ambiente - criando ambientes temporários para testes, removendo ambientes antigos após a mesclagem de ramificações de recursos * [Docker compose](https://docs.docker.com/compose/compose-file/) para implantações de vários contêineres * Diminuindo o tamanho da imagem docker e os tempos de construção * ...

Olá Comunidade, É hora de votar! Vote nos melhores aplicativos em nosso concurso de programação IRIS for Health, focado na criação de soluções FHIR para a saúde da mulher: 🔥 VOTE NOS MELHORES APPS 🔥 Como votar? Detalhes abaixo. Nominação de Especialistas: O júri experiente da InterSystems escolherá os melhores aplicativos para indicar os prêmios na Nomeação de Especialistas. Dê as boas-vindas aos nossos especialistas: ⭐️ @Alexander.Koblov, Especialista de Suporte⭐️ @Alexander.Woodhead, Especialista Técnico⭐️ @Guillaume.Rongier7183, Engenheiro de Vendas⭐️ @Alberto.Fuentes, Engenheiro de Vendas⭐️ @Dmitry.Zasypkin, Engenheiro de Vendas Sênior⭐️ @Daniel.Kutac, Engenheiro de Vendas Sênior⭐️ @Eduard.Lebedyuk, Senior Cloud Engineer⭐️ @Steve.Pisani, Arquiteto de Soluções Sênior⭐️ @Patrick.Jamieson3621, Gerente de Produto⭐️ @Nicholai.Mitchko, Gerente, Engenharia de Vendas de Parceiros de Soluções⭐️ @Timothy.Leavitt, Gerente de Desenvolvimento⭐️ @Benjamin.DeBoe, Gerente de Produto⭐️ @Robert.Kuszewski, Gerente de Produto⭐️ @Stefan.Wittmann, Gerente de Produto⭐️ @Raj.Singh5479, Gerente de Produto⭐️ @Jeffrey.Fried, Diretor de Gestão de Produtos⭐️ @Aya.Heshmat, Especialista de Produto⭐️ @Evgeny.Shvarov, Gestor do Ecossistema de Desenvolvedores⭐️ @Dean.Andrews2971, Chefe de Relações com Desenvolvedores Nominação da Comunidade: Para cada usuário, uma pontuação mais alta é selecionada nas duas categorias abaixo: Condições Posição 1º 2º 3º Se você tiver um artigo publicado no DC e um aplicativo carregado no Open Exchange (OEX) 9 6 3 Se você tiver um artigo publicado no DC ou um aplicativo carregado no Open Exchange (OEX) 6 4 2 Se você fizer qualquer contribuição válida para a DC (postar um comentário/pergunta, etc.) 3 2 1 Nível Posição 1º 2º 3º Nível VIP no Global Masters ou Gerentes de Produto ISC 15 10 5 Nível Ambassador no GM 12 8 4 Nível Expert no GM ou Moderadores da Comunidade 9 6 3 Nível Specialist no GM 6 4 2 Nível Advocate no GM ou funcionários ISC 3 2 1 Voto cego O número de votos para cada aplicativo será ocultado de todos. Uma vez por dia, publicaremos a tabela de classificação nos comentários desta postagem. A ordem dos projetos na página do concurso será a seguinte: quanto mais cedo uma inscrição for enviada para o concurso, mais alta ela estará na lista. PS Não se esqueça de se inscrever nesta postagem (clique no ícone do sino) para ser notificado sobre novos comentários Para participar da votação, você precisa Entrar no Open Exchange – as credenciais da Comunidade funcionam. Faça qualquer contribuição válida para a comunidade de desenvolvedores – responda ou faça perguntas, escreva um artigo, contribua com aplicativos no Open Exchange – e você poderá votar. Verifique esta postagem sobre as opções para fazer contribuições úteis para a Comunidade de Desenvolvedores. Se mudou de ideia, cancele a escolha e dê seu voto para outro aplicativo! Apoie o aplicativo que você gosta! Observação: os participantes do concurso podem corrigir os bugs e fazer melhorias em seus aplicativos durante a semana de votação, portanto, não perca e assine para acompanhar os lançamentos de aplicativos!

Se quiser experimentar o novo processo de instalação do projeto NoPWS, você pode obter acesso ao Early Access Program (EAP) aqui. (https://evaluation.intersystems.com/Eval/) Depois de se registrar, envie à InterSystems o endereço de e-mail que você usou para se registrar no EAP para nopws@intersystems.com. Veja aqui: Post Original

Olá Comunidade! Estamos na reta final do nosso 🏆 2º Concurso de Artigos Técnicos em Português da InterSystems 🏆.Restam apenas 5 dias 👀 para o encerramento do prazo de participação do concurso, e em seguida inicia-se o período de votação. Para aqueles que ainda estão elaborando o seu artigo, atenção para não perderem o prazo de publicação que vai até o dia 12 de junho de 2023. Fiquem ligados no prazo e não percam a chance de participarem! 😉Estamos aguardando por seus artigos. Boa sorte a todos 🍀

Olá, desenvolvedores! Observando a avalanche de ferramentas para desenvolvedores movidas por IA e baseadas em vibe-coding que vêm surgindo quase todo mês, com recursos cada vez mais interessantes, eu fiquei me perguntando se seria possível aproveitá-las com o InterSystems IRIS. Pelo menos para construir um frontend. E a resposta é: sim! Pelo menos com a abordagem que eu segui. Aqui está minha receita para construir a interface via prompting conectada ao backend IRIS: Tenha uma REST API no lado do IRIS, que siga uma especificação Open API (swagger). Gere a interface com alguma ferramenta de vibe-coding (por exemplo, Lovable) e aponte essa interface para o endpoint da REST API. Pronto! Aqui está o resultado do meu próprio exercício — uma interface 100% criada via prompt conectada a uma REST API IRIS, que permite listar, criar, atualizar e excluir registros de uma classe persistente (Open Exchange, código do frontend, vídeo): Qual é a receita em detalhes? Como obter a especificação Open API (Swagger) a partir do backend IRIS Peguei o template com a classe persistente dc.Person, que contém alguns campos simples: Nome, Sobrenome, Empresa, Idade, etc. Achei que o ChatGPT poderia gerar a especificação Swagger, mas talvez fosse tímido para fazer isso com ObjectScript (embora talvez consiga agora). Então, gerei o DDL da classe pelo terminal do IRIS: Do $SYSTEM.SQL.Schema.ExportDDL("dc_Sample","*","/home/irisowner/dev/data/ddl.sql") E passei esse DDL para o ChatGPT junto com o seguinte prompt: Por favor, crie uma especificação Open API no formato JSON versão 2.0 a partir do seguinte DDL, que permita obter todos os registros e registros individuais, além de criar, atualizar e excluir entradas. Adicione também um endpoint _spec com OperationId GetSpec. Por favor, atribua nomes significativos para todos os operationId dos endpoints. O DDL: CREATE TABLE dc_Sample.Person( %PUBLICROWID, Company VARCHAR(50), DOB DATE, Name VARCHAR(-1), Phone VARCHAR(-1), Title VARCHAR(50) ) GO CREATE INDEX DOBIndex ON dc_Sample.Person(DOB) GO E funcionou muito bem — aqui está o resultado. Depois disso, usei a ferramenta de linha de comando %REST para gerar as classes backend. Em seguida, implementei a lógica da API REST no IRIS usando ObjectScript para os métodos GET, PUT, POST e DELETE. Na maior parte, manualmente 😉, com alguma ajuda do Co-pilot no VSCode. Testei a REST API manualmente com o swagger-ui e, depois que tudo estava funcionando, fui construir a interface: A interface foi criada usando a ferramenta Lovable.dev via prompt: Por favor, crie uma interface moderna e prática a partir da seguinte especificação Open API, que permita listar, criar, atualizar e excluir pessoas { "swagger":"2.0", "info":{ "title":"Person API," "version":"1.0.0" }, ....(passei a especificação completa) Depois que a interface foi construída e testada (manualmente), pedi para o Lovable direcioná-la para o endpoint da REST API no IRIS. Primeiro localmente via Docker, e depois de alguns testes e correções (também via prompts), o resultado foi publicado. Algumas observações e lições aprendidas A segurança da REST API no lado do IRIS não é muito clara de início (principalmente por questões relacionadas ao CORS). Por exemplo, precisei adicionar uma classe especial cors.cls e modificar manualmente a especificação do Swagger para que o CORS funcionasse. A documentação Swagger não funciona automaticamente em containers Docker no IRIS, mas isso pode ser resolvido adicionando um endpoint _spec e algumas linhas de código em ObjectScript. A especificação Swagger para IRIS deve ser na versão 2.0, e não na mais recente 3.1. Fora isso, essa abordagem se mostrou uma forma bastante eficiente para um desenvolvedor backend IRIS construir protótipos de aplicações full-stack completos em muito pouco tempo, mesmo sem conhecimento de frontend. Compartilhe sua opinião. Qual é a sua experiência com vibe-coding no desenvolvimento com IRIS? Aqui está o vídeo demonstrativo:

WEBCAST: PLATAFORMA DE DADOS INTERSYSTEMS: O DIFERENCIAL NOS PROJETOS DE DATA FABRIC DO SETOR FINANCEIRO 27 de Maio de 2021Das 11h ás 12h Inscreva-se agora! DESTAQUES

Durante a pandemia de Covid-19 tornou-se evidente a necessidade de transformação digital na área da saúde e muito foi questionado sobre como aperfeiçoar processos, melhorar gestão de recursos, modernizar e humanizar os atendimentos ao paciente. Neste tópico abordaremos especificamente a gestão de medicamentos e vacinas, mais especificamente, a perda desses materiais. De acordo com a Organização mundial de Saúde (OMS), no ano de 2020, pelo menos 25% de todas as vacinas chegaram degradadas aos cidadãos e 50% das vacinas distribuídas podem ser ineficazes, devido ao armazenamento incorreto e falha de refrigeração, entre outras questões de logística, que de modo geral estão relacionadas a baixa temperatura ideal para conservação. E essas perdas custam primordialmente a saúde da população e muito dinheiro. O cenário pandêmico escancarou nossas necessidades na área da saúde, impulsionando investimentos em tecnologia e inovação. Hoje nosso cenário é favorável para integração do monitoramento da cadeia fria da saúde com IoT (Internet of Things). OBJETIVO Este artigo visa abordar conceitos e discussões sobre IoT como apoio a métricas e monitoria de temperatura em refrigeradores de laboratórios da saúde, tais como: Laboratórios de análises clínicas e farmacêuticos. Abordando tecnologias InterSystems e frisando seus benefícios. DESENVOLVIMENTO A cadeia fria se trata de um sistema de conservação, manuseio e transporte de produtos com temperatura controlada, dentro da logística de medicamentos e vacinas. Esse modelo é fundamental para garantir qualidade e integridade para o paciente que irá recebê-los. A IoT abre um leque de possibilidades em nossas casas e cidades, a ideia é trazê-la para o laboratório, entregando uma monitoria IoT para aumentar o potencial de rastrear e restringir as temperaturas dentro desses ambientes controlados, contando com disparo de e-mails, SMS e push notifications. Podemos contar com a possibilidade de incorporar ferramentas de análise de dados a fim de auxiliar possíveis decisões sobre as alterações de temperatura ou identificar possíveis falhas no equipamento de refrigeração. Em resumo, estaríamos aplicando a tecnologia InterSystems IRIS Data Platform ao desenvolver, executar e manter nossa aplicação para informar através de vários canais, tanto para consumir quanto para enviar dados. Com recursos de integração e analíticos e possuindo um banco de dados multimodelo transacional incorporado, a InterSystems IRIS também será fundamental para armazenar os dados necessários de modo seguro e eficiente. A plataforma de integração de dados e sistemas, IRIS Interoperability, será nosso componente de mensageria usando o protocolo MQTT (Message Queuing Telemetry Transport) para os disparos de notificações citados anteriormente. O IntegratedML como recurso incorporado da plataforma IRIS InterSystems, escolhido para o gerenciamento dos dados coletados nos refrigeradores para possíveis tomadas de decisões para auxiliar a alteração de temperatura automaticamente quando necessário por meio de análise preditiva e para gerar insights para quando houver falhas nos equipamentos. Abaixo segue a explicação de cada escolha e o porquê. MQTT (Message Queuing Telemetry Transport) É um protocolo de comunicação M2M (Machine to Machine) com foco em IoT que funciona em cima do protocolo TCP. Sua comunicação se baseia entre o cliente que pode realizar tanto postagens quanto captação de informação e o broker que administra os dados a serem recebidos e enviados. Para essa comunicação, usa-se um paradigma chamado publish-subscribe. Por que MQTT e não outros protocolos? Criado em 1999 pela IBM para ser usado no setor de petróleo e gás, o MQTT surgiu a partir da necessidade de um protocolo para largura de banda mínima e perda de bateria mínima para monitorar oleodutos via satélite, sendo, dessa forma, um recurso simples, de baixo consumo de dados e que possibilita uma comunicação bilateral. Por que mensageria e não HTTP? Para abordar esta questão é preciso iniciar apontando suas diferenças na arquitetura. O HTTP funciona com um modelo cliente/servidor ou request-response, como exemplifica a figura abaixo, enquanto o MQTT funciona por meio de publicações e assinaturas de um tópico (publish-subscriber). No MQTT a conexão é mantida e pings podem ser compartilhados para mantê-la aberta, já o HTTP cria uma conexão apenas quando uma solicitação necessita ser enviada. E, por fim, é válido acrescentar que o HTTP mantém uma conexão TCP half-duplex (transmissões são realizadas nos dois sentidos da comunicação, mas alternadamente, nunca simultâneas) enquanto o MQTT mantém uma full-duplex (transmissões são simultâneas, um dispositivo pode transmitir informação ao mesmo tempo que a recebe), permitindo comunicações assíncronas entre os serviços para que os mesmos não esperem a resposta do serviço de recebimento, sendo um modelo necessário para mensageria. Além das diferenças apontadas acima, a mensageria torna a aplicação escalável, visto que o modelo publish-subscriber oferece suporte à mudança de números de serviços. Após essa breve explicação, podemos dizer que o MQTT é muito mais otimizado para esse cenário em comparação ao HTTP em taxa de transferência, consumo de bateria e largura de banda, tornando-se uma melhor opção para a maioria das aplicações IoT e sendo reconhecido como o padrão de mercado de mensageria nesse contexto. O IRIS Interoperability, uma plataforma de integração de dados e sistemas, desempenha um papel fundamental como broker para este protocolo e no cenário descrito deste artigo. Ele permite que os dispositivos IOT publiquem mensagens em tópicos específicos, neste caso o tópico de monitoria de temperatura, e também que a aplicação faça um subscribe para receber as mensagens. O IRIS fornece extensões integradas para usar o MQTT. InterSystems IntegratedML O AutoML (Automated Machine Learning) é um recurso que surge como opção para o uso do ML (Machine Learning) para desenvolvedores com conhecimento em SQL, mas pouco ou nenhum em ML. Com ele é possível automatizar a criação, treinamento e implementação do aprendizado de máquina, a organização que opta por sua utilização pode poupar tempo e esforço significativos de sua equipe de cientistas de dados, visto que o AutoML abstrai os detalhes e conhecimentos especializados exigidos. Certo! Mas onde entra o InterSystems IntegratedML? IntegratedML (Integrated Machine Learning) se trata de um recurso integrado da plataforma de dados InterSystems IRIS que simplifica e fornece recursos AutoML, permitindo o uso de funções automatizadas diretamente do SQL para gerar e manusear modelos preditivos. Sua inclusão ao IRIS permite uma execução dinâmica, atuando em tempo real diretamente nos dados, sem extrair ou mover quaisquer modelos ou bases. Para exemplificar sua funcionalidade, assume-se que, “no Brasil todo mês de janeiro é quente” e que teremos registros de aproximadamente três anos armazenados na base de dados, obtida por estações meteorológicas. É importante que para essa exemplificação tenhamos em mente que os dados foram preparados e estamos desconsiderando informações abrangentes como mudanças climáticas. A partir dessa premissa, é necessário treinar nosso modelo para que, ao iniciar cada mês de janeiro, as temperaturas tendem a ser mais elevadas, portanto deve reduzir em 1°C (grau Celsius) a temperatura. Se a temperatura externa aumentar, demanda-se que o sistema de refrigeração seja acionado, resfriando o ambiente interno, mantendo temperaturas indicadas pelos fabricantes e mantendo a integridade dos insumos ali armazenados. Junto ao IRIS, o IntegratedML “automatiza o trabalho básico, como identificar os modelos mais apropriados, definir parâmetros e construir e treinar modelos” e permite melhorias contínuas dos modelos de ML. O objetivo aqui é criar e implantar modelos de aprendizagem de máquina com um menor esforço, no sentido de não precisar de especialistas para começar aplicar as funcionalidades necessárias de ML, complementar o trabalho do time e dedicar tempo a melhorias e suporte à aplicação e análises. Após a preparação dos dados e criação do modelo, o IntegratedML será responsável por gerenciar os dados coletados dos refrigeradores para auxiliar às possíveis tomadas de decisões, assim como, após o treinamento do modelo, deve ser capaz de ajustar a temperatura de forma automática quando necessário, por meio de análise preditiva, além de gerar insights em caso de falhas nos equipamentos. A seguir, apresentamos uma imagem ilustrativa da nossa arquitetura e onde o IntegratedML, IRIS Interoperability e o MQTT estão sendo aplicados. CONCLUSÃO Mesmo tendo outras soluções disponíveis no mercado, há muitas razões pelas quais aplicar tecnologias InterSystems ao IoT podem ser benéficas. A InterSystems é reconhecida na área da saúde, principalmente pelos produtos InterSystems IRIS for Health e o InterSystems TrakCare, e oferece recursos robustos de integração, permitindo conexão e comunicação eficiente entre diferentes sistemas e dispositivos, flexibilidade, escalabilidade, conformidade. A sua interoperabilidade pode simplificar a implantação e gerenciamento de um sistema abrangente. É interessante ressaltar que a mesma lógica pode ser aplicada em outros segmentos além dos laboratórios de saúde, como os refrigeradores industriais. Porém, aplicando regras de ML específicas para o uso industrial. REFERÊNCIAS Aprendizagem e Análise de Máquina - Plataforma de Análise de Big Data. InterSystems. Disponível em <https://www.intersystems.com/br/sistema-de-gerenciamento-de-banco-de-dados/grande-analise-de-dados/> Acesso em 24 de maio de 2023. Desperdício de medicamentos: como evitar perdas. NEXXTO, 2022. Disponível em <https://www.linkedin.com/pulse/desperd%C3%ADcio-de-medicamentos-como-evitar-perdas-nexxto/?trk=organization-update-content_share-article> Acesso em 16 de maio de 2023. Gestão de Bases de Dados. InterSystems. Disponível em <https://www.intersystems.com/br/sistema-de-gerenciamento-de-banco-de-dados/gestao-de-bases-de-dados/> Acesso em 19 de maio de 2023. Introduction to IntegratedML. InterSystems. Disponível em <https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI.Page.cls?KEY=GIML_Intro> Acesso em 29 de maio de 2023. IoT with InterSystems IRIS. Marx Y., 2023. Disponível em <https://community.intersystems.com/post/iot-intersystems-iris> Acesso em 20 de maio de 2023. Implementation of IoT based Smart Laboratory. M. Poongothai, 2018. Disponível em <https://www.researchgate.net/publication/327723745_Implementation_of_IoT_based_Smart_Laboratory> Acesso em 20 de maio de 2023. Interoperabilidade - Integração Potente e Flexível com InterSystems IRIS. InterSystems. Disponível em <https://www.intersystems.com/br/sistema-de-gerenciamento-de-banco-de-dados/interoperabilidade/> Acesso em 19 de maio de 2023. InterSystems IntegratedML - Aprendizagem da máquina facilitada. Intersystems. Disponível em <https://www.intersystems.com/br/solucoes/integratedml/> Acesso em 20 de maio de 2023. IoT Sample. GOMES Y. , 2023. Disponível em <https://openexchange.intersystems.com/package/IoT-Sample> Acesso em 01 de junho de 2023. MQTT: Get started with IoT protocols. Sola R., 2016. Disponível em <https://www.opensourceforu.com/2016/11/mqtt-get-started-iot-protocols/> Acesso em 24 de maio de 2023. Machine Learning Made Easy: InterSystems IntegratedML. InterSystems. Disponível em <https://www.intersystems.com/resources/machine-learning-made-easy-intersystems-integratedml/> Acesso em 20 de maio de 2023. "MQTT vs HTTP: ¿qué protocolo es mejor para IoT?". H. Angel, 2020. Disponível em <https://borrowbits.com/2020/04/mqtt-vs-http-que-protocolo-es-mejor-para-iot/> Acesso em 24 de maio de 2023 "O que é MQTT?". Amazon. Disponível em <https://aws.amazon.com/pt/what-is/mqtt/> Acesso em 24 de maio de 2023. Talk2Lab: The Smart Lab of the Future. IEEE, 2020. Disponível em <https://ieeexplore.ieee.org/abstract/document/9094640> Acesso em 20 de maio de 2023. Parabéns pelo excelente artigo! Parabéns!!! Sucinto e objetivo. Parabéns!!! Excelente trabalho. Excelente artigo! Eu trabalho com arquitetura orientada a eventos, e foi muito interessante ver como os serviços de mensageria pode ser utilizado pra outras finalidades. Sem falar da grande integração com as ferramentas da InterSystems. Muito obrigada, Filipe! Muito obrigada! A ideia era ser mesmo objetivo, pois é uma comunidade de tecnologia, então descarta algumas introduções nos temas apresentado e vai direto ao ponto. Muito obrigada, fico feliz que tenha gostado da leitura. Muito obrigada pelas palavras, fico muito feliz em saber que estou entregando valor com este artigo e que tenha gostado de como abordei o tema e as ferramentas da InterSystems. Muito bom o artigo. Parabéns! Muito legal!!! Parabéns! Aliás, quando vc terminar a graduação, vamos participar do mestrado na FAMERP? Começa com a Disciplina Inovação e Empreendedorismo na Saúde. Topa??? Oi Thaís! Parabéns pelo seu artigo, ficou objetivo, técnico e interessante. Independente de prêmio, você realizou um excelente trabalho. Excelente…artigo muito bem elaborado Uau! Meus parabéns Thais! Este artigo ficou show de bola! Você pretende continuar este trabalho após a sua formatura? Parabéns Thais ótimo artigo. Oi Thaís ... parabéns pelo artigo.. Orgulho! Boa sorte! muito bom!! Parabéns @Thais.Pinheiro Excelente artigo Thais, muito bem elaborado e interessante! Excelente artigo Thais, acompanhei de perto o manuseio de vacinas e medicamentos que necessitam de refrigeração,é realmente muito falho esse controle. interessante demais conhecer esse a tecnologia... Sucesso 🙏 Parabéns pelo artigo @Thais.Pinheiro , excelente trabalho. Muito obrigada! Fico muito lisonjeada pelo convite e agradeço muitíssimo, é uma ótima oportunidade. Vou pensar com carinho e volto a falar com a senhora. Muito obrigada, Márcio! Admiro-o muito, então para mim é muito gratificante que tenha gostado. Obrigada, Mariangela! Muito obrigada, Lucimar! No momento tenho em mente trabalhar esse tema no meu TG para realizar a parte prática. Se tudo der certo acredito que eu dê continuidade, sim. Obrigada, Katia! Olá! Muito obrigada, Adriana. Fico honrada de ver a senhora por aqui. Uma professora que tenho um carinho enorme. Muito obrigada, Taciana! Fico feliz que tenha gostado. Muito obrigada, Laura! Agradeço pela leitura e fico feliz que tenha gostado. Muito obrigada, Cristiane! Conversei com algumas pessoas da área e elas comentaram sobre o gerenciamento de algumas vacinas, o que reforçou ainda mais para mim que foi um tema legal. Que bom que gostou e agradeço novamente. Muito obrigada, Marcio! Agradeço pela leitura e fico feliz que tenha gostado. Muito obrigada, Lucas! Parabéns pelo artigo, Thais! Parabéns pelo artigo!!! Great article Thais. Very complete and useful! Congratulations! Muito bom seu artigo, parabéns. Parabéns, excelente artigo! Bem claro e objeto! Muito obrigada, fico contente que tenha gostado. Muito obrigada, Reginaldo! Obrigada, Felicio! Muito obrigada, Daniele!

Olá Desenvolvedores, Nós lhes convidamos para pegar alguns minutinhos de seu dia e deixar uma avaliação de sua experiência com nossa plataforma de dados InterSystems IRIS no TrustRadius. Sabemos que enviar sua avaliação requer tempo e esforço e então ficaremos felizes em recompensá-lo com um cartão presente no valor de US$ 25,00 pela avaliação publicada. Para ganhar o cartão presente da InterSystems siga os seguintes passos: ✅ #1: Clique → neste link ← para submeter sua avaliação (selecione o botão "Start My Review"). ✅ #2: Sua avaliação terá um título. Copie o texto do título de sua avaliação e cole ele neste desafio no Global Masters. ✅ #3: Depois que sua avaliação for publicada você receberá o cartão presente VISA no valor de US$25,00 e 3000 pontos no Global Masters. Observações: O TrustRadius deve aprovar a avalição para que você esteja qualificado para receber o cartão presente. O TrustRadius não irá aprovar avaliações derevendedores, integradores de sistemas ou MSP / ISVs da InterSystems. O TrustRadius não aprovará as avaliações que estiverem sido previamente publicadas online. Feito? Excelente! Seu cartão presente estará a caminho!

Olá comunidade, Nesta 4ª parte vamos falar de uma funcionalidade do InterSystems IRIS Reports chamada de “Bursting”. Vamos primeiro relembrar o que já vimos até o momento. Entendemos o que é o InterSystems IRIS Reports, instalamos os ambientes: Designer e Server, verificamos os diversos tipos e formatos de relatórios que podemos desenvolver, e entendemos como distribuir um relatório em diversos formatos. Mas afinal o que é o “Bursting”? Antes de demonstrar está funcionalidade em ação, vamos primeiro refletir sobre a sua necessidade. Todos nós já nos deparamos com necessidade de processar relatórios com milhares de linhas, e este tipo de relatório normalmente tem um alto custo de processamento no banco de dados com milhares de linhas que não são destinadas a um único usuário, você precisa segregar as informações por região, por alguma categoria seja de produto ou um tipo de exame, ou por alguma hierarquia existente para o seu tipo de negócio. Sem o InterSystems IRIS Reports, você precisaria desenvolver uma ou mais queries aplicando técnicas para filtrar dados com as opções de “filtro” que usuário precisa ou pode ter acesso, e podem ocorrer mais de uma execução por diversos usuários ao longo do dia. Vamos pegar como exemplo a fonte de dados que estamos usando para esta nossa jornada de conhecimento do InterSystems IRIS Reports. Estamos usando uma base de dados disponível no Kaggle. A base é da Olist, são informações de e-commerce de diversos marketplaces. Neste exemplo determinamos que cada categoria de produto possui um vendedor responsável e precisamos enviar informações para os responsáveis segregando os dados por categoria. Agora você me pergunta? Então está funcionalidade “Bursting” serve para fazer uma “explosão”, “segregação” de um grande relatório para diversos destinatários? Sim você está certo! Eu particularmente adoro essa funcionalidade, porque acabamos reduzindo custo de desenvolvimento, reduzindo custo de processamento do banco de dados, nos proporciona a facilidade e a distribuição de relatórios de forma automatizada, ou seja, deixamos todos “stakeholders” dos processos satisfeitos! Então vamos automatizar o posicionamento de vendas para todas as regiões da sua empresa? Ou automatizar envio de bilhetagem? Qual a sua necessidade de segregação e automatização de relatórios? Bom vamos colocar então a mão na massa desta funcionalidade: “Bursting”! Vamos começar com alguns conceitos do “Bursting”: Bursting Schema É onde definimos como vamos fazer a divisão dos dados. Para fazer a divisão dos dados precisamos dentro do “bursting Schema” definir o “bursting key” e o “bursting recipientes”. Bursting key: É um ou mais campos onde o definimos uma chave para que possa ocorrer a segregação dos dados, como exemplo vamos usar a base de dados que estamos utilizando neste tutorial. Temos uma tabela chamada produto e nela temos o campo: product_category_name. Através deste campo definimos o time de vendas responsável em acompanhar o status dos pedidos com os valores sumarizados, portanto, este campo será o nosso “bursting key”. Bursting recipientes: É a tabela que contêm os campos com as informações dos destinatários que receberam os relatórios. É mandatório que exista o campo que será relacionado com o “bursting key”, no nosso caso é a product_category_name. Para nosso exemplo criamos uma tabela chamada comercial, onde nela contém os campos: productcategoryname / folderdestino / emaildestino Como podemos perceber temos o campo que será feito o relacionamento com a tabela produto e mais dois campos. O campo folderdestino contêm o caminho do servidor onde os arquivos do relatório serão distribuídos e o campo emaildestino contêm o e-mail do destinatário que receberá o e-mail. O Bursting também permite a distribuição dos relatórios via FTP. No nosso exemplo vamos distribuir os relatórios por e-mail e na pasta do servidor. Um passo importante para que possamos criar o “Bursting” é relembrar um passo que fizemos na 3ª parte deste. Precisamos criar uma query onde vamos ter o relacionamento entre a tabela que contém o bursting key e com a tabela Bursting recipientes. Vamos para o primeiro passo. Como base vamos utilizar o relatório que contém as todas as vendas sumarizadas por categoria: 1º - Dentro do designer, na barra superior clicar em Report, e em seguida clique na opção Bursting. 2º - Clique em: Enable Bursting Report. É possível mudar o nome do Bursting Schema, aqui vamos manter o padrão. 3º - Agora vamos fazer o Mapping do Bursting Key com o Bursting recipientes. 4º - No campo Dataset, carrega automaticamente o Query que está sendo utilizada no relatório, abaixo temo como escolher o campo do bursting key, aqui vamos selecionar o campo que estamos utilizando neste tutorial: product_category_name. 5º - Em Recipient, Data Source, é onde escolhemos a query criada onde possui a relação entre as tabelas do Bursting Key com o Bursting recipientes. 6º - No campo Recipient Mapping Identifier, é onde vamos selecionar o campo que fará o relacionamento com o Bursting Key. 7º - Em Recipient escolhemos os campos onde contém o conteúdo do destinatário do e-mail e da pasta destino. 8º - Opcionalmente pode clicar em E-mail Settings para colocar o assunto do e-mail, informar algum comentário, ou até mesmo selecionar o campo Cc ou Bcc. 9º Agora é só publicar o relatório para o servidor! Lembra deste passo? Fizemos isto na 3ª parte deste artigo, caso não lembre, dá uma passadinha lá! Agora que o relatório está publicado no servidor, vamos colocar o nosso “Bursting” para trabalhar. Para executar o relatório com está funcionalidade precisamos criar um agendamento no servidor para execução. Já fizemos este tipo de agendamento na 3ª parte deste artigo, mas nesta etapa teremos algumas parametrizações adicionais, segue: 1º Selecionar o relatório e clicar na opção de agendamento. 2º Em Schedule Name, é opcional dar um nome para o agendamento. 3º Em Select Report Tabs, aqui uma opção nova: Select bursting reports, vamos selecionar está opção. 4º Em Report Tab Name, selecionar o relatório onde foi parametrizado nossa funcionalidade. 5º Em Bursting Configuration, escolher o relatório e o Bursting Schema criado no passo anterior. 6º Na aba superior clicar em Publish. 7º Em Bursting Result temos duas opções: To Disk e To E-mail. Aqui uma observação importante parametrizamos o Bursting com duas possibilidades de publicação, para pasta e para e-mail, ou seja, podemos criar agendamentos distintos ou no mesmo agendamento fazer a explosão para os dois destinos. Aqui neste tutorial vamos criar um único agendamento com a explosão para os dois destinos. 8º Em ToDisk, clique em Publish to Disk, agora temos a opção de diversos formatos de geração do relatório, para disco, vamos criar no formato TXT, após clicar em TXT, vamos dar o nome para o relatório e podemos escolher opção o formato da delimitação do TXT. 9º Em ToEmail, clique em Publish to E-mail, e podemos escolher o formato do relatório, para a opção e-mail vamos gerar em PDF, e ao selecionar a opção PDF, vamos dar o nome do arquivo que será gerado. 10º Na aba Conditions podemos escolher o horário e a periodicidade que o relatório será executado, no nosso tutorial vamos usar a opção: Run this task immediately. 11º - Em Notification podemos selecionar um destinatário de e-mail para quando o agendamento executado com sucesso e outro e-mail em caso de falha. Agora é só clicar em Finish, e verificar resultado do relatório. Resultado em disco: podemos observar que para cada Bursting Key foi criada uma pasta com o respectivo nome com o relatório gerado: E aqui o resultado no e-mail: Obrigado e até a próxima parte!

Olá Desenvolvedores. Ainda não tirou um tempinho para escrever seu artigo para o 1º Concurso de Artigos Técnicos em Português da InterSystems ? Essa é a hora ! Além de concorrer aos prêmios já anunciados para o concurso, inscrevendo seu artigo no concurso você estará participando automaticamente do sorteio de um ingresso para o Global Summit 2022 da InterSystems que ocorrerá do dia 20 ao dia 23 de junho em Seattle !!! Esperamos ansiosamente seus artigos ! Boa sorte a todos !!! Olá Desenvolvedores. Corram que ainda dá tempo ! Já se imaginaram participando do Global Summit da InterSystems??Essa é a chance!

Olá Desenvolvedores, Este novo vídeo já se encontra no Canal YouTube dos Desenvolvedores InterSystems: ⏯ Solução Analítica InterSystems HealthShare: Crie e Entregue Análises em Tempo Real em Escala Muitas organizações orientadas a dados precisam construir fontes de informações confiáveis de alta qualidade, normalizadas e validadas. Aprenda como a Solução Analítica InterSystems HealthShare permite que sua organização consolide e harmonize seus dados em escala, a partir de fontes distintas, em tempo real, permitindo colaboração entre todas as áreas e com entidades externas, mantendo o controle de seus dados. 🗣 Apresentador: Fred Azar, Healthcare Analytics Executive, InterSystems Curta e compartilhe !

Nesta série de artigos, quero apresentar e discutir várias abordagens possíveis para o desenvolvimento de software com tecnologias da InterSystems e do GitLab. Vou cobrir tópicos como: * Git básico * Fluxo Git (processo de desenvolvimento) * Instalação do GitLab * Fluxo de trabalho do GitLab * Entrega contínua * **Instalação e configuração do GitLab** * CI/CD do GitLab No [primeiro artigo](https://community.intersystems.com/post/continuous-delivery-your-intersystems-solution-using-gitlab-part-i-git), abordamos os fundamentos do Git, por que um entendimento de alto nível dos conceitos do Git é importante para o desenvolvimento de software moderno e como o Git pode ser usado para desenvolver software. No [segundo artigo](https://community.intersystems.com/post/continuous-delivery-your-intersystems-solution-using-gitlab-part-ii-gitlab-workflow), abordamos o fluxo de trabalho do GitLab: um processo inteiro do ciclo de vida do software e a entrega contínua. Neste artigo, vamos discutir: * Instalação e configuração do GitLab * Conexão dos seus ambientes ao GitLab ## Instalação do GitLab Vamos instalar o GitLab no local. Há várias maneiras de instalar o GitLab — da fonte, pacote, em um contêiner. Não descreverei todos os passos aqui, há um [guia para isso](https://about.gitlab.com/installation/). Ainda assim, algumas observações. Pré-requisitos: * Servidor separado — como é um web application e um recurso bastante intensivo, é melhor executar em um servidor separado * Linux * (Opcional, mas altamente recomendável) Domínio — necessário para executar páginas e proteger a configuração inteira ### Configuração Primeiro de tudo, você provavelmente precisa enviar [e-mails com notificações](https://docs.gitlab.com/omnibus/settings/smtp.html). Em seguida, recomendo [instalar Páginas](https://docs.gitlab.com/ce/administration/pages/index.html). Como discutido no artigo anterior — artefatos do script podem ser enviados para o GitLab. O usuário pode fazer o download deles, mas é útil poder abri-los diretamente no navegador e, para isso, precisamos de páginas. Por que você precisa de páginas: * Para mostrar uma página wiki gerada ou estática para seu projeto * Para mostrar artefatos html * [Outras coisas que você pode fazer com páginas](https://docs.gitlab.com/ce/user/project/pages/#explore-gitlab-pages) Como as páginas html podem ter um redirecionamento onload, elas podem ser usadas para enviar o usuário para onde precisamos. Por exemplo, veja este código que gera uma página html que envia um usuário para o último teste de unidade executado (no momento da geração do html): ClassMethod writeTestHTML() { set text = ##class(%Dictionary.XDataDefinition).IDKEYOpen($classname(), "html").Data.Read() set text = $replace(text, "!!!", ..getURL()) set file = ##class(%Stream.FileCharacter).%New() set name = "tests.html" do file.LinkToFile(name) do file.Write(text) quit file.%Save() } ClassMethod getURL() { set url = "http://host:57772" set url = url _ $system.CSP.GetDefaultApp("%SYS") set url = url_"/%25UnitTest.Portal.Indices.cls?Index="_ $g(^UnitTest.Result, 1) _ "&$NAMESPACE=" _ $zconvert($namespace,"O","URL") quit url } XData html { If you are not redirected automatically, follow this link to tests. } Encontrei um bug usando as páginas (erro 502 ao procurar artefatos), [veja aqui a correção](https://gitlab.com/gitlab-com/infrastructure/issues/3064). ###   ## Conexão dos seus ambientes ao GitLab Para executar scripts de CD, você precisa de ambientes, servidores configurados para executar seu aplicativo. Presumindo que você tem um servidor Linux com o produto InterSystems instalado (digamos InterSystems IRIS, mas funciona também com o Caché e Ensemble), estas etapas conectam o ambiente ao GitLab: 1. [Instalar o runner do GitLab](docs.gitlab.com/runner/) 2. [Registrar o runner com o GitLab](https://docs.gitlab.com/runner/register/index.html) 3. Permitir que o runner chame o InterSystems IRIS **Observação importante** sobre a instalação do runner GitLab, NÃO clone servidores após instalar o runner do GitLab.  Os resultados são imprevisíveis e muito indesejados. ### Registrar o runner com o GitLab Após executar o inicial: sudo gitlab-runner register você verá vários prompts e, embora a maioria das etapas seja bastante direta, várias não são: **Insira o token gitlab-ci para este runner** Há vários tokens disponíveis: * Um para o sistema inteiro (disponível nas configurações de administração) * Um para cada projeto (disponível nas configurações do projeto) Conforme você conecta um runner para executar a CD para um projeto específico, você precisa especificar um token para este projeto. **Insira as tags gitlab-ci para este runner (separadas por vírgulas):** Na configuração de CD, você pode filtrar quais scripts vão ser executados em quais tags. Então, no caso mais simples, especifique uma tag, que seria o nome do ambiente. **Insira o executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell: docker** Se você estiver usando o servidor habitual sem docker, escolha shell.  O Docker será discutido nas partes posteriores. ### Permitir que o runner chame o InterSystems IRIS Depois de conectar o runner ao GitLab, precisamos permitir que ele interaja com o InterSystems IRIS, para isso: 1. O usuário **gitlab-runner** precisa conseguir chamar csession. Para fazer isso, adicione-o ao grupo cacheusr:  * usermod -a -G cacheusr gitlab-runner 2. [Crie](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSQL_privileges) o usuário **gitlab-runner** no InterSystems IRIS e dê a ele funções para realizar tarefas de CD (escreva para DB, etc.) 3. [Permitir a autenticação no nível do SO](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_intro_authe_os) Para 2 e 3, outras abordagens podem ser usadas, como a transmissão de usuário/código, mas acho que a autenticação de SO é preferível.  ## Conclusão Nesta parte: * GitLab instalado * Ambientes conectados ao GitLab Links * [Instruções de instalação](https://about.gitlab.com/installation/) * [Páginas](https://docs.gitlab.com/ce/administration/pages/index.html) * [Runner](docs.gitlab.com/runner/) * [Parte I: Git](https://pt.community.intersystems.com/post/entrega-cont%C3%ADnua-de-sua-solu%C3%A7%C3%A3o-intersystems-usando-gitlab-%E2%80%93-parte-i-git) * [Parte II: fluxo de trabalho do GitLab](https://pt.community.intersystems.com/post/entrega-cont%C3%ADnua-de-sua-solu%C3%A7%C3%A3o-intersystems-usando-gitlab-%E2%80%93-parte-ii-fluxo-de-trabalho-do) O que vem a seguir Na próxima parte, escrevemos nossa configuração de entrega contínua.

Nesta série de artigos, quero apresentar e discutir várias abordagens possíveis para o desenvolvimento de software com tecnologias da InterSystems e do GitLab. Vou cobrir tópicos como: * Git básico * Fluxo Git (processo de desenvolvimento) * Instalação do GitLab * **Fluxo de trabalho do GitLab** * **Entrega contínua** * Instalação e configuração do GitLab * CI/CD do GitLab No [artigo anterior](https://pt.community.intersystems.com/post/entrega-cont%C3%ADnua-de-sua-solu%C3%A7%C3%A3o-intersystems-usando-gitlab-%E2%80%93-parte-i-git), abordamos os fundamentos do Git, por que um entendimento de alto nível dos conceitos do Git é importante para o desenvolvimento de software moderno e como o Git pode ser usado para desenvolver software. Ainda assim, nosso foco foi na parte da implementação do desenvolvimento de software, mas esta parte apresenta: * **Fluxo de trabalho do GitLab** — um processo completo do ciclo de vida do software, desde a ideia até o feedback do usuário * **Entrega Contínua** — uma abordagem de engenharia de software em que as equipes produzem software em ciclos curtos, garantindo que o software possa ser lançado de forma confiável a qualquer momento. Seu objetivo é construir, testar e lançar software com mais rapidez e frequência. ## Fluxo de trabalho do GitLab O [fluxo de trabalho do GitLab](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/) é uma sequência lógica de possíveis ações a serem tomadas durante todo o ciclo de vida do processo de desenvolvimento de software. O fluxo de trabalho do GitLab leva em consideração o fluxo do GitLab, que discutimos em um artigo anterior. Veja como funciona: 1. Ideia: todas as novas propostas começam com uma ideia. 2. Problema: a maneira mais eficaz de discutir uma ideia é criar um problema para ela. Sua equipe e seus colaboradores podem ajudar você a aprimorar e melhorar a ideia no rastreador de problemas. 3. Plano: quando a discussão chega a um acordo, é hora de programar. Porém, primeiro, precisamos priorizar e organizar nosso fluxo de trabalho ao atribuir problemas a marcos e quadro de problemas. 4. Código: agora estamos prontos para escrever nosso código, já que está tudo organizado. 5. Commit: depois de satisfeitos com o rascunho, podemos enviar nosso código para um feature-branch com controle de versão. O fluxo do GitLab foi explicado em detalhes no artigo anterior. 6. Teste: executamos nossos scripts usando o CI GitLab, para construir e testar nosso aplicativo. 7. Revisão: assim que nosso script funcionar e nossos testes e compilações forem bem-sucedidos, estamos prontos para que nosso código seja revisado e aprovado. 8. Staging: agora é hora de implantar nosso código em um ambiente de staging para verificar se tudo funciona como esperado ou se ainda precisamos de ajustes. 9. Produção: quando tudo estiver funcionando como deve, é hora de implantar no nosso ambiente de produção! 10. Feedback: agora é hora de olhar para trás e verificar qual etapa do nosso trabalho precisa ser melhorada.  Novamente, o processo em si não é novo (ou exclusivo do GitLab) e pode ser alcançado com outras ferramentas da sua escolha. Vamos discutir várias dessas etapas e o que elas implicam. Também há [documentação](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/) disponível. ### Problema e plano As etapas iniciais do fluxo de trabalho do GitLab são centradas em um **problema**: um recurso, bug ou outro tipo de trabalho semanticamente separado. O problema tem várias finalidades, como: * Gerenciamento: um problema tem data de vencimento, pessoa designada, tempo gasto e estimativas, etc. para ajudar a monitorar a resolução do problema. * Administrativo: um problema faz parte de um marco, quadro kanban, que nos permite rastrear nosso software à medida que ele avança de versão para versão. * Desenvolvimento: um problema tem uma discussão e commits associados a ele. A etapa de planejamento nos permite agrupar os problemas por prioridade, marco, quadro kanban e ter uma visão geral disso.  O desenvolvimento foi discutido na parte anterior, basta seguir qualquer fluxo git que quiser. Depois que desenvolvemos nosso novo recurso e o mesclamos no master: o que vem depois? ### Entrega contínua A entrega contínua é uma abordagem de engenharia de software em que as equipes produzem software em ciclos curtos, garantindo que o software possa ser lançado de forma confiável a qualquer momento. Seu objetivo é construir, testar e lançar software com mais rapidez e frequência. A abordagem ajuda a reduzir o custo, o tempo e o risco da entrega de alterações, permitindo mais atualizações incrementais para aplicativos em produção. Um processo de implantação simples e repetível é importante para a entrega contínua. ### Entrega contínua no GitLab No GitLab, a configuração da entrega contínua é definida por repositório como um arquivo de configuração YAML. * A configuração de entrega contínua é uma série de **estágios** consecutivos. * Cada estágio tem um ou vários **scripts** que são executados em paralelo. O script define uma ação e quais condições devem ser atendidas para executá-la: * O que fazer (executar o comando do SO, executar um contêiner)? * Quando executar o script: * Quais são os gatilhos (commit de um branch específico)? * Nós o executamos se os estágios anteriores falharam? * Executar manualmente ou automaticamente? * Em que ambiente executar o script? * Quais artefatos salvar após a execução dos scripts (eles são carregados do ambiente para o GitLab para facilitar o acesso)? **Ambiente** - é um servidor ou contêiner configurado no qual você pode executar seus scripts. **Runners** executam scripts em ambientes específicos. Eles são conectados ao GitLab e executam scripts conforme necessário. O runner pode ser implantado em um servidor, contêiner ou até mesmo na sua máquina local. Como acontece a entrega contínua? 1. O novo commit é enviado para o repositório. 2. O GitLab verifica a configuração de entrega contínua. 3. A configuração de entrega contínua contém todos os scripts possíveis para todos os casos, para que sejam filtrados para um conjunto de scripts que devem ser executados para esse commit específico (por exemplo, um commit para o branch master aciona apenas ações relacionadas a um branch master). Esse conjunto é chamado de **pipeline**. 4. O pipeline é executado em um ambiente de destino e os resultados da execução são salvos e exibidos no GitLab. Por exemplo, aqui está um pipeline executado após um commit em um branch master: Ele consiste em quatro etapas, executadas consecutivamente 1. O estágio de carregamento carrega o código em um servidor 2. O estágio de teste executa testes de unidade 3. O estágio de pacote consiste em dois scripts executados em paralelo: * Compilação cliente * Código de exportação do servidor (principalmente para fins informativos) 4. O estágio de implantação move o cliente criado para o diretório do servidor web. Como podemos ver, todos os scripts foram executados com sucesso. Se um dos scripts falhar, por padrão, os scripts posteriores não são executados (mas podemos alterar esse comportamento):  Se abrirmos o script, podemos ver o log e determinar por que ele falhou: Running with gitlab-runner 10.4.0 (857480b6) on test runner (ab34a8c5) Using Shell executor... Running on gitlab-test... <span class="term-fg-l-green term-bold">Fetching changes...</span> Removing diff.xml Removing full.xml Removing index.html Removing tests.html HEAD is now at a5bf3e8 Merge branch '4-versiya-1-0' into 'master' From http://gitlab.eduard.win/test/testProject * [new branch] 5-versiya-1-1 -> origin/5-versiya-1-1 a5bf3e8..442a4db master -> origin/master d28295a..42a10aa preprod -> origin/preprod 3ac4b21..7edf7f4 prod -> origin/prod <span class="term-fg-l-green term-bold">Checking out 442a4db1 as master...</span> <span class="term-fg-l-green term-bold">Skipping Git submodules setup</span> <span class="term-fg-l-green term-bold">$ csession ensemble "##class(isc.git.GitLab).loadDiff()"</span> [2018-03-06 13:58:19.188] Importing dir /home/gitlab-runner/builds/ab34a8c5/0/test/testProject/ [2018-03-06 13:58:19.188] Loading diff between a5bf3e8596d842c5cc3da7819409ed81e62c31e3 and 442a4db170aa58f2129e5889a4bb79261aa0cad0 [2018-03-06 13:58:19.192] Variable modified var=$lb("MyApp/Info.cls") Load started on 03/06/2018 13:58:19 Loading file /home/gitlab-runner/builds/ab34a8c5/0/test/testProject/MyApp/Info.cls as udl Load finished successfully. [2018-03-06 13:58:19.241] Variable items var="MyApp.Info.cls" var("MyApp.Info.cls")="" Compilation started on 03/06/2018 13:58:19 with qualifiers 'cuk /checkuptodate=expandedonly' Compiling class MyApp.Info Compiling routine MyApp.Info.1 ERROR: MyApp.Info.cls(version+2) #1003: Expected space : '}' : Offset:14 [zversion+1^MyApp.Info.1] TEXT: quit, "1.0" } Detected 1 errors during compilation in 0.010s. [2018-03-06 13:58:19.252] ERROR #5475: Error compiling routine: MyApp.Info.1. Errors: ERROR: MyApp.Info.cls(version+2) #1003: Expected space : '}' : Offset:14 [zversion+1^MyApp.Info.1] > ERROR #5030: An error occurred while compiling class 'MyApp.Info' <span class="term-fg-l-red term-bold">ERROR: Job failed: exit status 1 </span> O erro de compilação causou a falha do nosso script. Conclusão * O GitLab é compatível com todos os principais estágios de desenvolvimento de software. * A entrega contínua pode ajudar você a automatizar tarefas de construção, teste e implantação do seu software. Links * [Parte I: Git](https://git-scm.com/book/en/v2) * [Introdução ao fluxo de trabalho do GitLab](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/) * [Documentação de CI/CD do GitLab](https://about.gitlab.com/features/gitlab-ci-cd/) * [Fluxo do GitLab](https://docs.gitlab.com/ce/workflow/gitlab_flow.html) * [Código deste artigo](https://github.com/eduard93/GitGraph-samples) ### O que vem a seguir? No próximo artigo, vamos: * Instalar o GitLab. * Conectá-lo a diversos ambientes com os produtos InterSystems instalados. * Escrever uma configuração de entrega contínua. Vamos discutir como a entrega contínua deve funcionar. Em primeiro lugar, precisamos de vários ambientes e branches que correspondam a eles. O código entra nesse branch e é entregue ao ambiente de destino: | Ambiente | Branch | Entrega | Quem pode fazer envios | Quem pode mesclar | | -------- | ------- | ----------------------------------------------- | ------------------------------ | ------------------------------ | | Teste | master | Automático | Desenvolvedores  Proprietários | Desenvolvedores  Proprietários | | Preprod | preprod | Automático | Ninguém | Proprietários | | Prod | prod | Semiautomático (pressionar botão para entregar) | Ninguém | Proprietários | E, como exemplo, desenvolveremos um novo recurso usando o fluxo do GitLab e o entregaremos usando a CD do GitLab. 1. O recurso é desenvolvido em um branch de recursos. 2. O branch de recurso é revisado e mesclado no master branch. 3. Depois de um tempo (vários recursos mesclados), o master é mesclado com o preprod 4. Depois de um tempo (teste do usuário, etc.), o preprod é mesclado com o prod Veja como ficaria: 1. Desenvolvimento e teste * O desenvolvedor envia o código para o novo recurso em um branch de recursos separado * Depois que o recurso se torna estável, o desenvolvedor mescla nosso branch de recursos no master branch * O código do branch master é entregue ao ambiente de teste, onde é carregado e testado 2. Entrega para o ambiente de pré-produção * O desenvolvedor cria a solicitação de mesclagem do branch master para o branch de pré-produção * Depois de algum tempo, o proprietário do repositório aprova a solicitação de mesclagem * O código do branch de pré-produção é entregue ao ambiente de pré-produção 3. Entrega para o ambiente de produção * O desenvolvedor cria a solicitação de mesclagem do branch de pré-produção para o branch de produção * Depois de algum tempo, o proprietário do repositório aprova a solicitação de mesclagem * O proprietário do repositório aperta o botão "Implantar" * O código do branch de produção é entregue ao ambiente de produção Ou o mesmo, mas em formato gráfico:   

Escrito por: @Luana.Machado e @Ana.Dascenzio Cenário No cenário da saúde, seja em um laboratório ou hospital, uma falha de equipamento pode custar muito caro. O custo pode vir pelo tempo de conserto e inutilização da máquina, ou pior, pelo dano a um paciente ou cliente. Portanto, pode ser muito benéfico encontrar sinais antecipados para potenciais problemas, obter essa informação em tempo real e adequar as manutenções em momentos fora do fluxo diário de uso. Para isso, podemos utilizar a tecnologia da InterSystems IRIS em um modelo de manutenção preditiva notificada de equipamentos médicos. Soluções: Manutenção preditiva A manutenção preditiva é um método de manutenção baseado em condição, capaz de monitorar a situação do equipamento e prever a vida útil de peças importantes com base na inspeção ou diagnóstico, analisando dados relacionados à sua deterioração e monitorando suas condições por meio de um sistema on-line. Ela permite visualizar sinais de aviso, reduzindo o número de falhas catastróficas. [1] Fonte: Upkeep O fluxo demonstra, em linhas gerais, como funciona a manutenção preditiva. Inicialmente, é monitorado e estabelecido as baselines (linhas de base), ou seja, o ponto de partida do equipamento. Depois, são instalados os sensores de monitoramento de condição. Em seguida, serão coletados os dados condicionais para comparar com as baselines definidas anteriormente. Quando o equipamento funcionar fora dos padrões, os sensores acionam o protocolo de manutenção preditiva que gera uma ordem de serviço. Por fim, será performada a manutenção, que se repetirá na próxima vez que houver violações nas baselines. Intersystems IRIS Data Platform Como solução, vamos utilizar da interoperabilidade da plataforma. Como demonstrado na figura acima, podemos conectar os sensores acoplados nos equipamentos ao sistema do IRIS para enviar os dados gerados. Dentro da plataforma, os dados serão armazenados no banco de dados multi-modelo de modo a disponibilizá-los para análise. Por fim, os dados analisados e armazenados são enviados para o Sistema de Monitoramento e Alerta que, em caso de anormalidade, acionará a manutenção preditiva para a equipe responsável. A IoT vem sendo muito usada na área da saúde para aprimorar a predição e a prevenção de falhas em equipamentos médicos, o que otimiza o processo de manutenção destes. A implementação de um protocolo de comunicação de máquinas em ambientes hospitalares é dependente das especificações e necessidades do hospital em questão. O protocolo de transporte de mensagem cliente/servidor MQTT(Message queuing telemetry transport) possibilita a comunicação entre máquinas, usado para a conectividade IoT, amplamente usado em equipamentos hospitalares. No contexto abordado, ele fornece comunicação assíncrona e bidirecional, possibilitando uma comunicação eficiente e confiável. O HL7 (Health Level 7) FHIR é um conjunto de padrões para a troca de informações de saúde, é amplamente utilizado no setor da saúde por vantagens como ter sido desenvolvido especialmente para a área da saúde, apresentando flexibilidade e facilidade de implementação. Ele auxilia na troca de grandes volumes de dados de forma confiável entre diversas aplicações. Seu uso relacionado ao IoT envolve outro protocolo anteriormente descrito, o MQTT. A forma como é realizado o acoplamento entre protocolos é complexa, e envolve a adição de camadas de comunicação entre os protocolos. Nesse caso, assegurar a integridade e segurança dos dados é essencial. IRIS Ademais, utilizaremos o InterSystems IRIS para ser a plataforma de integração e processamento de dados. Em tempo real, serão coletados e armazenados dados de sensores que monitoram os equipamentos a partir de parâmetros como temperatura, luz, vibração, tensão, corrente, umidade e consumo de energia [3]. Todos esses dados são transmitidos para o IRIS fazer a análise. Ele recebe esses dados através da integração com o dispositivo em si ou a partir do uso de protocolos, como o MQTT, abordado anteriormente. Ter um modelo de dados flexível e escalável facilita a construção e implementação de aprendizado de máquina, processamento em tempo real e análises mais avançadas, podendo ser algo mais abstrato ou então focado em uma parte mais específica, como análise de dados recebidos de um sensor de equipamento hospitalar. InterSystems IntegratedML Com Machine Learning, será possível detectar anomalias e identificar padrões que apontam possíveis falhas no equipamento. Por isso, contaremos com o IntegratedML, que oferece sintaxe SQL para definir e treinar modelos, para analisar os dados armazenados no IRIS. O tipo de modelo que será utilizado é o de classificação, que irá identificar de forma simples se o equipamento precisa ou não de manutenção com base em características abordadas de registros já salvos em um dataset ou modelo de dados. Com o IntegratedML, é possível a execução em tempo real da resposta dos eventos, facilitando a predição de manutenção em equipamentos baseados em sua classificação. System Alerting and Monitoring (SAM) SAM é um componente independente da Intersystems que coleta e armazena dados de performance e cria alertas definidos de acordo com a necessidade. Para o nosso caso, podemos configurar o sistema para alertar equipes responsáveis pelo conserto através de e-mail sempre que o equipamento chegar em um estado que requer a manutenção. De acordo com a documentação da Intersystems[4], as métricas de interoperabilidade no SAM vem desabilitadas por padrão, e precisam ser implementadas para o seu contexto de uso. Só o SAM em sí não oferece opções para monitoramento dos dados, e sim para monitoramento do banco de dados, questões como desempenho, uso de CPU e etc. As métricas, como o uso do SAM em um container docker junto com o Grafana, Prometheus, Alertmanager e Ngix fornecem ferramentas para o monitoramento de dados e alertas exclusivos de equipamentos hospitalares. Um exemplo de implementação da interoperabilidade no SAM está disponível na documentação Intersystems, System Alerting and Monitoring[5]. A imagem abaixo é uma captura de tela da tela inicial do SAM versão 1.1, onde podemos ver o funcionamento do monitoramento de instâncias. Fonte:https://pt.community.intersystems.com/post/lan%C3%A7ado-o-sam-system-alerting-monitoring-vers%C3%A3o-11 Exemplo: Como exemplo, vamos trazer um caso de uso com uma falha em um smartwatch. Smartwatches já são utilizados ao redor do mundo para monitoramento de pacientes. Um caso recente no Brasil foi a parceria da Samsung com a InCor, para a aferição e coleta de dados de pacientes cardiopatas em período pré e pós-operatório de cirurgia cardiovascular[6]. Dado a situação, é imprescindível o bom funcionamento do aparelho para que os dados transferidos ao hospital sejam precisos e o paciente permaneça seguro durante o processo. Nesse cenário fictício, mostramos como funciona o protocolo FHIR enviando as informações de falha do sistema para a análise. Após os sensores do smartwatch do Paciente 42 enviarem parâmetros atuais do relógio, o sistema IRIS analisou, a partir dos dados e modelos treinados por machine learning, que o smartwatch encontrava sinais de falha. Isso ativou a mudança do seu status para “damaged” (danificado), que será imediatamente enviado para o Sistema de Alerta e Monitoramento. A empresa responsável, a ABC Corporation, receberá o aviso e fará as devidas manutenções. { "resourceType": "Device", "id": "example-smartwatch", "identifier": [ { "system": "http://example.com/devices", "value": "SW12345" } ], "status": "entered-in-error", "availabilityStatus": { "coding": [ { "system": "http://example.com/availability-status", "code": "damaged", "display": "Damaged" } ], "text": "Damaged" }, "type": { "coding": [ { "system": "http://example.com/device-codes", "code": "smartwatch", "display": "Smartwatch" } ], "text": "Smartwatch" }, "manufacturer": "ABC Corporation", "model": "XYZ Smartwatch", "version": "1.0", "location": { "display": "Cardiology Department, Room 101" }, "contact": [ { "system": "phone", "value": "123-456-7890" }, { "system": "email", "value": "contact@example.com" } ], "patient": { "reference": "Patient/42" } } No contexto de manutenção preditiva dos equipamentos hospitalares, a situação é similar: quando encontrado sinais de falhas em equipamentos, o status é modificado e as mudanças são enviadas ao Sistema de Alerta e Monitoramento, que são recebidas pela empresa que fará a manutenção deste equipamento. Conclusão A implementação tem importância significativa na área em que foi abordada, pois a manutenção preditiva notificada não só reduz riscos de mal funcionamento ou parada repentina do equipamento, como apresenta uma constante avaliação da situação dos equipamentos hospitalares em questão, economizando recursos e diminuindo o custo para hospitais. Referências bibliográficas [1] Predictive Maintenance. Science Direct.Disponível em: <https://www.sciencedirect.com/topics/engineering/predictive-maintenance>. Acesso em maio de 2023. [2] Differences Between Predictive Maintenance and Condition Based Maintenance. Upkeep. Disponível em: <https://www.upkeep.com/learning/predictive-condition-based/#differences-between-predictive-maintenance-and-condition-based-maintenance>. Acesso em maio de 2023. [3] Maktoubian, J., Ansari, K. An IoT architecture for preventive maintenance of medical devices in healthcare organizations. Health Technol. 9, 233–243 (2019). Acesso em maio de 2023. [4] Deploy a System Alerting and Monitoring Image | InterSystems Components and Tools. Disponível em:https://docs.intersystems.com/components/csp/docbook/DocBook.UI.Page.cls?KEY=ASAM_deploy . Acesso em: 6 jun. 2023. [5] System Alerting and Monitoring | InterSystems Components and Tools. Disponível em: https://docs.intersystems.com/components/csp/docbook/DocBook.UI.Page.cls?KEY=ASAM. Acesso em: 6 jun. 2023. [6] Hospital da USP vai usar smartwatch para monitorar pacientes à distância. Tecmundo. Disponível em: https://www.tecmundo.com.br/ciencia/240873-hospital-usp-usar-smartwatch-monitorar-pacientes-distancia.htm>. Acesso em maio de 2023. Harun-Ar-Rashid, M.; Chowdhury, O.; Hossain, M.M.; Rahman, M.M.; Muhammad, G.; AlQahtani, S.A.; Alrashoud, M.; Yassine, A.; Hossain, M.S. IoT-Based Medical Image Monitoring System Using HL7 in a Hospital Database. Healthcare 2023, 11, 139. Disponível em: <https:// doi.org/10.3390/healthcare11010139>. Acesso em maio de 2023. Parabéns Ana!!! Muito obrigada Taciana! Parabéns Ana!!!! Inclusive, se acabar sendo seu TG, vamos conversar para voce dar continuidade em nossa disciplina do Mestrado na FAMERP!!! Muito obrigada @Liszeila.Martingo! Se formos dar continuidade ao projeto como TG ou iniciação científica, entraremos em contato com você, obrigada pela proposta 😊 Parabéns Ana e Luana, Deus as abençoe! Parabéns @Ana.Dascenzio e @Luana.Machado . Excelente trabalho. Muito obrigada @Marcio.Pereira! Parabéns pelo artigo, meninas! Parabéns Ana! Muito interessante esse artigo! Parabéns pelo artigo!!! Great article Ana!! Congrats 🙂 Parabéns gente, ficou muito legal! Achei bastante inovador esse assunto👏