A plataforma Embrapa I/O permite que sejam estruturados projetos de software de ativos digitais para a agropecuária, guiando os desenvolvedores em padrões e métodos bem definidos. Antes de utilizá-la, é necessário compreender alguns conceitos inerentes à plataforma.

Primeiramente, assume-se que cada ativo digital será formado por diversos softwares desacoplados, além de outros artefatos de apoio. Este conceito reflete o padrão atual de desenvolvimento de software, onde uma solução tem um backend integrado ao banco de dados, um frontend na Web, um aplicativo mobile, dentre outros (ou pode ainda ainda ser baseada em microservices ou micro-frontends), com diversos módulos, plugins, packages e componentes que seguem ciclos de vida independentes.

Para consolidar estes conceitos, a seguir são apresentadas as principais entidades que você encontrará na plataforma e sua terminologia.

Ativo Digital

A Embrapa tem por missão viabilizar soluções de pesquisa, desenvolvimento e inovação para a sustentabilidade da agricultura, em benefício da sociedade brasileira. Como uma empresa de inovação voltada para o agronegócio brasileiro, atualmente desenvolve tecnologias de 14 tipos diferentes: prática agropecuária; cultivar; reprodutor, matriz ou linhagem animal; processo para produção, fabricação ou extração; produto agropecuário ou industrial; máquina, implemento ou equipamento; metodologia técnico-científica; metodologia com fins organizacionais e gerenciais; software institucional; procedimento informatizado; ativo cartográfico; tecnologias interdependentes; sistema agropecuário, agroalimentar e florestal; e, com especial ênfase, ativo digital agropecuário.

Neste contexto, um ativo digital é um conjunto de softwares com código-fonte original (e outros artefatos relacionados) que são desenvolvidos para serem utilizados no agronegócio e agricultura familiar. Mais especificamente, em cinco ecossistemas digitais: agricultura; pecuária; florestas e silvicultura; aquicultura e pesca; e, indústria de processamento. Para diferenciar “ativos digitais” de outras tecnologias também digitais formalmente conceituadas dentro da Empresa (tal como “processo informatizado” e “banco de dados”), é utilizada como base a definição do INPI para “programa de computador”, que por sua vez é baseada na a Lei nº 9.609, de 19 de fevereiro de 1998.

Em resumo, portanto, para ser considerada um “ativo digital”, a tecnologia digital desenvolvida deve possuir código-fonte próprio, com originalidade, e passível de depósito e registro junto ao INPI.

Desta forma, aplicativos móveis, aplicações web, softwares embarcados, utilitários de linha de comando, softwares desktop, APIs e outros tipos de soluções computacionais para o agronegócio, que possuam código-fonte original, são exemplos de ativos digitais.

Contrariamente, o uso exclusivo de linguagens de marcação e códigos-fonte autogerados, bem como soluções que não possuam código-fonte original, tal como aquelas construídas por meio de plataformas No-Code ou Codeless que não tenham código-fonte disponível para registro ou que tenham mas necessitem destas ferramentas proprietárias para serem executados (a exemplo do Google AppSheet), não são consideradas formalmente um ativo digital.

Projeto

Um projeto de ativo digital no Embrapa I/O corresponde a um grupo de repositórios no GitLab (similar a uma organization do GitHub). É, portanto, composto por diversos repositórios que, por sua vez, podem ser de 3 (três) tipos distintos:

  • repositório de código-fonte de aplicação: que contém o código-fonte de um dos softwares que compõe o ativo digital, sendo gerado automaticamente pela plataforma a partir do código-fonte de um boilerplate escolhido pelo usuário;
  • repositório de suporte: que são gerados automaticamente pela plataforma, seguindo padrões bem definidos, para prover o site técnico de divulgação pública do projeto, a documentação online da API, o empacotamente para disponibilização em lojas virtuais, o diretório privado de documentação, os artefatos de identidade visual e/ou binários de compilações; e
  • repositório de arquivos de apoio: que nada mais são do que repositórios criados pelos mantenedores do projeto para armazenar e versionar outros arquivos que não se enquadrem nos tipos anteriores.

Para criar um projeto, acesse a dashboard e siga os passos na própria interface.

Aplicação

Dentre os tipos de repositórios listados, o do código-fonte de aplicação (ou app) é o mais importante, pois permitirá que os desenvolvedores codifiquem cada módulo desacoplado do ativo em si e, posteriormente, façam a entrega deste módulo (deploy). Na plataforma Embrapa I/O, uma aplicação é sempre criada a partir de um código-fonte modelo, que atua como um template de código ou boilerplate. Isto é fundamental para estruturar o códifo-fonte inicial da sua aplicação com padrões e diretrizes requeridos pela plataforma.

Para entender melhor este processo, siga os passos de criação de uma aplicação.

Boilerplate

Uma aplicação pode ser criada na plataforma utilizando qualquer linguagem de programação, entretanto é necessário que ela seja baseada sempre em um boilerplate. Estes templates de código irão fornecer a estrutura inicial de diretórios e arquivos da aplicação, bem como a sua conteinerização prévia respeitando os requisitos determinados pela plataforma.

Por exemplo, toda aplicação no Embrapa I/O precisa ter um diretório oculto na raiz denominado .embrapa. Neste diretório estão metadados que são utilizados pela plataforma durante a configuração dos builds e nas fases de CI/DI dos processos de DevOps.

Na conteinerização também existem padrões a serem seguidos. Por exemplo, a plataforma espera ter disponível nas aplicações alguns serviços que são utilizados no deploy e monitoramento das builds instanciadas, tal como:

  • backup: que executa o backup das instâncias e disponibiliza para os mantenedores do projeto;
  • restore: que possibilita restaurar um backup específico;
  • sanitize: que executa um processo de higienização e/ou otimização na instância; e
  • test: que executa testes unitários na instância.

Veja mais sobre como criar e manter boilerplates e seja assim um colaborador da plataforma.

Planejamento e Acompanhamento

O GitLab integrado à plataforma Embrapa I/O possui uma ferramenta embutida de gerencimento ágil de projetos (do inglês, tracking and agile project management). Esta ferramenta permite o planejamento das etapas de desenvolvimento por meio de marcos (milestones) e do registro de tarefas (issues) associadas. Para entender melhor como fazer o planejamento e acompanhamento do projeto, veja como utilizar a Kanban board integrada.

Rodadas Evolutivas

Durante o ciclo-de-vida da aplicação, seu código-fonte passará por diversas evoluções. Quando estas intervenções compreendem esforços que alteram significativamente o software, atribuindo-lhe novas funcionalidades, interfaces, refatorações e/ou integrações, dizemos que trata-se de uma nova rodada evolutiva e, portanto, uma nova macro-versão da aplicação. Toda vez que uma nova rodada evolutiva tem início, uma equipe (squad) será provisionada com especialistas e profissionais que viabilizem os requisitos funcionais de suas novas features.

Na plataforma Embrapa I/O uma app pode ser criada visando a entrega de uma prova de conceito (do inglês, Proof of Concept - PoC), um protótipo ou um produto viável mínimo (do inglês, Minimum Viable Product - MVP), ou seja, uma versão inicial da aplicação em Escala TRL/MRL 5, 6 ou 7, respectivamente. Nesta empreitada, o squad de desenvolvimento irá implementar a macro-versão “0” (zero) desta aplicação. Em uma nova rodada evolutiva, visando a evolução da aplicação para um produto pleno e em produção (TRLs 8 e 9), teríamos a macro-versão “1.0”. Havendo novas funcionalidades a serem implementadas, poderia-se provisionar novamente uma equipe e desenvolver a macro-versão “2.0”, e assim sucessivamente.

Assim, a cada nova rodada evolutiva, a macro-versão da aplicação é incrementada, prefixando o nome de versão do software desenvolvido. Leia o artigo completo sobre rodadas evolutivas para uma melhor compreensão.

Estágios

O desenvolvimento de novas funcionalidades e manutenções corretivas e evolutivas de uma aplicação no Embrapa I/O evolui por 4 (quatro) estágios:

  • development: Estágio de desenvolvimento, que roda apenas na estação de trabalho dos desenvolvedores;
  • alpha: Estágio de testes internos, apto ao deploy na plataforma;
  • beta: Estágio de testes externos, apto ao deploy na plataforma; e
  • release: Estágio de produção, apto ao deploy na plataforma.

Quando uma nova app é criada em um projeto a partir de um boilerplate, na prática o Embrapa I/O faz um fork do repositório do GitLab do boilerplate para dentro do projeto. Neste momento, o boilerplate é customizado com algumas informações do projeto e são criadas automaticamente 4 (quatro) branches: main, alpha, beta e release.

A metodologia de controle de versões adotada pelo Embrapa I/O segue a diretriz de “Trunk Based Development”, onde há uma branch principal, neste caso denominada “main”, onde todas as revisions devem ser concentradas. Assim, qualquer ramificação deve ter sua origem no tronco (main) e retornar a ele. Quando uma nova versão precisa ser entregue (deploy), é feito um merge do tronco (main) para uma branch do estágio (alpha, beta ou release). A branch do estágio é então tagueada para a versão específica. Veremos mais sobre isso no passo de deploy de builds.

Build

A build é uma instância de determinada aplicação em um estágio específico. Seu nome é formado pelo padrão:

project / app @ stage

Quando uma nova app é criada, pode-se habilitar até 3 (três) builds para ela, cada uma relacionada a um estágio: alpha, beta e release. Para isso, será necessário configurar cada build separadamente. Para que uma build seja instanciada na plataforma Embrapa I/O e, desta forma, disponibilizada publicamente, ela precisará primeiramente ter sua configuração validada. A configuração de uma build envolve o cluster em que ela será instanciada, os volumes para armazenamento de dados, a definição das variáveis de ambiente da instância e a associação de URLs externas (aliases).

Versão

Para a entrega (deploy) de builds é necessário, além de efetuar o merge da branch “main” na branch de estágio (alpha, beta ou release), criar uma tag nesta última branch de forma a informar à plataforma Embrapa I/O que existe uma nova versão da build a ser instanciada no servidor remoto. Para nomear esta tag, a plataforma institui um padrão bem definido de nome de versão:

macro version . milestone year . milestone month - stage . patch

Desta forma, a versão de uma determinada build poderia ser, por exemplo, “2.23.4-beta.7”. Neste exemplo, a build em questão está na macro-versão “2”, correspondente ao milestone “23.4” (ou seja, com entrega planejada para abril de 2023), no estágio de “testes externos” (beta) e no “7º” patch.

Ao versionar a build de produção (release) há uma exceção: é omitido o qualificador de estágio. Assim, um nome de versão válido para uma build em produção seria “2.23.4-3” (versão final para produção, planejada para abril de 2023, da aplicação em sua 2ª macro-versão).

Este padrão de nomes de versão é aderente ao padrão SemVer 2.0.0. É importante frisar que a plataforma Embrapa I/O valida se as tags estão sendo criadas com nomes válidos e nas branches corretas, somente efetuando o deploy se tudo estiver conforme o padrão.

Veja como criar a tag na branch utilizando o cliente GIT e, desta forma, efetuar o deploy da build.

Instância

Uma vez que tenha sido realizado o deploy de uma build em determinado servidor remoto (cluster), teremos uma instância sendo executada e disponível para acesso pelos usuários. Os usuários poderão então acessar a instância por meio da URL do servidor e das portas alocadas (links permanentes) ou por meio de aliases configurados previamente. Os mantenedores do projeto poderão monitorar a instância e “disparar” determinados processos de gestão (tal como reiniciar os containers, agendar o higienizador/otimizador, suspender a instância e fazer backup dos dados da instância).

Cluster

Uma instância de uma build pode ser instanciada em servidores (ou clusters) remotos internos e externos à Embrapa e com diferentes orquestradores de containers. Para isto, a plataforma Embrapa I/O adota uma estratégia de deploy baseada em drivers. Assim, é possível ter um driver para Kubernetes (que fará o deploy em um host com este orquestrador), outro para deploy na Microsoft Azure (que fará o deploy interagindo com a API desta plataforma), outro para RedHat OpenShift, etc.

Da mesma forma, é necessário gerenciar os servidores do tipo storage onde serão montados os volumes para armazenamento de dados das aplicações. Neste caso também é adotado uma estratégia baseada em drivers, onde pode-se por exemplo ter para o orquestrador Kubernetes um driver para NFS v3 e outro para o NFS v4. Ou ainda, ter um driver para o orquestrador Amazon AWS integrado a um driver para storage que monta os volumes no Amazon EBS.

É possível configurar e disponibilizar novos clusters e storages para comporem a plataforma Embrapa I/O, ampliando assim sua capacidade de entrega de soluções.