Alterações no código-fonte

Antes de iniciar as alterações no código-fonte é importante verificar se está na branch correta. Por padrão, os projetos no DevOps são criados da seguinte maneira:

Ambiente de aceite: branch test;
Ambiente de qualidade (QA): branch develop;
Ambiente de produção: branch master;

Também é possível que tenham sido criadas novas branches manualmente pelos desenvolvedores, de acordo com os padrões adotados no projeto.

No nosso exemplo utilizaremos a branch test, então verificaremos se o Git já está apontando para a Branch test, através do comando “git branch”:

Caso não esteja na branch correta, faça a alteração através do comando “git checkout [nome da branch]”:

Editando o código-fonte

Robôs e Integrações

O projeto é criado com a estrutura básica de uma aplicação Spring Boot, que utiliza o maven como gerenciador de dependências.

São criadas automaticamente duas classes Java:

Uma com o nome dado ao projeto, contendo as anotações @RobotModule, caso seja um robô, ou @IntegrationModule, caso seja uma integração Java. Também contém a anotação @Version, para controle de versão, e a anotação @Component, que indica que a classe é um componente Spring. Esta é a classe principal para o desenvolvimento do robô ou integração Java, da mesma forma como já é feito sem o DevOps. No caso do exemplo Roboexecutaratividade fica da seguinte forma:

package br.com.lecom.RoboExecutarAtividade;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;
import br.com.lecom.atos.servicos.annotation.Execution;
import br.com.lecom.atos.servicos.annotation.RobotModule;
import br.com.lecom.atos.servicos.annotation.Version;

@Component
@RobotModule("Roboexecutaratividade")
@Version({1,0,0})

public class Roboexecutaratividade {

    private static final Logger LOGGER = LoggerFactory.getLogger(Roboexecutaratividade.class);

    @Execution
    public void execute() {
        LOGGER.debug("Running robot");
    }

}

A outra classe criada recebe o nome dado ao projeto + a palavra “Application”, que é a classe que executa o robô ou integração Java como uma aplicação Spring. No caso de exemplo RoboexecutaratividadeApplication fica da seguinte forma:

package br.com.lecom.RoboExecutarAtividade;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class RoboexecutaratividadeApplication implements CommandLineRunner {

    @Autowired
    private Roboexecutaratividade RoboExecutarAtividade;

    public static void main(String[] args) {
        SpringApplication.run(RoboexecutaratividadeApplication.class, "--spring.profiles.active=test");
    }

    @Override
    public void run(String...args) throws Exception {
        RoboExecutarAtividade.execute();
    }
}

Também é criado o arquivo pom.xml para gerenciamento de dependências através do maven, contendo a dependência da tag parent de acordo com o tipo de projeto: robot-parent para robôs e integration-parent para integrações java.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <artifactId>RoboExecutarAtividade</artifactId>
   <version>1.0.0</version>
   <parent>
      <groupId>br.com.lecom</groupId>
      <artifactId>robot-parent</artifactId>
      <version>1.0.1-RELEASE</version>
      <relativePath />
      <!-- lookup parent from repository -->
   </parent>
   <repositories>
      <repository>
         <id>lecom-nexus-snapshots</id>
         <name>Lecom Snapshots</name>
         <url>https://repo-store.lecom.com.br/repository/lecom-snapshots</url>
         <releases>
            <enabled>false</enabled>
         </releases>
         <snapshots>
            <enabled>true</enabled>
         </snapshots>
      </repository>
      <repository>
         <id>lecom-nexus-releases</id>
         <name>Lecom Releases</name>
         <url>https://repo-store.lecom.com.br/repository/lecom-releases</url>
         <releases>
            <enabled>true</enabled>
         </releases>
         <snapshots>
            <enabled>false</enabled>
         </snapshots>
      </repository>
   </repositories>
</project>

IMPORTANTE: A versão atual desta dependência é 1.0.1-RELEASE (utilizada no momento da escrita deste manual, em agosto/2023). A versão deve ser sempre observada, pois poderá evoluir ao longo do tempo.

Aplicação externa

O projeto é criado com a estrutura básica de uma aplicação Spring Boot, que utiliza o maven como gerenciador de dependências.

Diferente dos robôs e integrações Java, o projeto de aplicações vem com:

Uma classe com o nome dado ao projeto + a palavra “Application”, que é a classe que executa a aplicação como uma aplicação Spring. No caso de exemploAppexternasimplesApplication fica da seguinte forma:

Um pacote de Controller, já contendo o HealthRestController, que é um controller com uma rota simples, que pode ser utilizado para verificar se a aplicação está no ar:

Também é criado o arquivo pom.xml para gerenciamento de dependências através do maven, contendo a dependência da tag parent, que para aplicações é external-application-parent.

IMPORTANTE: Conforme descrito no Manual do usuário, as aplicações que forem publicadas via DevOps, terão sua URL base definidas a partir da URL do ambiente. Exemplo: https://cliente.com.br/app-ext/minhaaplicacao .

Então no caso da Appexternasimples, para acessarmos a rota do controller HealthRestController no ambiente http://plataforma.lecom.com.br , por exemplo, a URL seria: https://plataforma.lecom.com.br/app-ext/appexternasimples/api/v1/health.

Adicionando uma biblioteca pelo Maven

Para adicionar uma biblioteca ao projeto, basta adicionar a dependência ao arquivo pom.xml. Isso é válido para qualquer tipo de projeto: Robôs, Integrações Java e Aplicações.

Como exemplo, iremos adicionar a dependência Stella Core para validação de CPF à aplicação do tópico anterior.

Primeiro acessaremos o site https://mvnrepository.com/ onde é possível buscar por várias bibliotecas, buscaremos por “stella core”.

Ao selecionar a biblioteca, será exibida uma tabela de informações das versões. Selecionaremos a mais recente disponível, que na data da escrita deste manual é a 2.1.6.

Ao selecionar a versão, será exibida uma página com informações de como adicionar à dependência via Maven.

Devemos copiar o conteúdo do quadro, colar no arquivo pom.xml, dentro da tag <dependencies>, e salvar a alteração.

Em seguida clicar o botão direito no projeto, selecionar o menu “Maven > Update Project”.

Feito isso a dependência está pronta para ser utilizada. Criaremos a classe CpfValidatorController para exemplificar o uso.

IMPORTANTE: No caso de integrações e robôs (criados antes do projeto de isolamento), as bibliotecas adicionadas no arquivo pom.xml também precisam ser incluídas na pasta custom quando as mesmas não são utilizadas pela plataforma.

Caso a biblioteca já seja utilizada pela plataforma, essas customizações irão utilizar a mesma versão já disponibilizada no tomcat.

Isso é necessário porque estas customizações são executadas no mesmo contexto do tomcat e por isso, precisa ter acesso a essas bibliotecas.

Também é necessário garantir a compatibilidade das bibliotecas externas com a plataforma.

No caso das aplicações externas e robôs criados pelo projeto de isolamento, não é necessário adicionar as bibliotecas à pasta custom, pois estas customizações rodam em um contexto separado do tomcat da plataforma

Publicando alterações

Para consolidar as alterações feitas, é necessário fazer o commit no repositório.

Através do comando “git status” é possível visualizar os arquivos que foram alterados.

Adicionar os arquivos modificados ao staging do git através do comando “git add [nome do arquivo]” ou “git add .” para adicionar todos os arquivos.

Em seguida, utilize o comando “git commit -m “[mensagem de commit]” para consolidar o commit.

E para finalizar utilizar o comando “git push” para enviar as alterações ao repositório remoto.

Feito isso, as alterações já poderão ser publicadas no Studio, acessando o cadastro do robô e clicando no botão “Publicar”, conforme descrito no manual do usuário.

O processo é o mesmo para robôs, integrações Java e aplicações.