Projetos

Ao acessar a dashboard da plataforma, o usuário verá na barra superior um botão para criar um novo projeto.

Atenção! Somente empregados da Embrapa podem criar novos projetos.

Ao clicar neste botão abrirá um wizard para criação do projeto. O primeiro passo é um disclaimer, o qual o usuário deverá estar ciente.

No segundo passo o usuário poderá escolher um nome legível para o projeto, um nome unix (somente minúsculas, sem acentos, espaços ou caracteres especiais) e quais repositórios de suporte deverão ser gerados automaticamente.

Repositórios de Suporte

Os repositórios de suporte podem ser de 6 (seis) tipos distintos:

I. Site de informações públicas do projeto

Todo projeto Embrapa I/O pode instanciar um site público de documentação. Esta funcionalidade é baseada no GitHub Pages e funciona de forma muito similar. Na prática o desenvolvedor pode documentar as aplicações que compõem o projeto utilizando linguagem Markdown de forma bastante simplificada.

Quando esta opção é selecionada, o autômato de criação de entidades da plataforma irá criar um novo repositório (denominado io-web) no grupo do projeto no GitLab com o código-fonte inicial desta página. Ao mesmo tempo, o autômato de deploy da plataforma irá instanciar a página e disponibilizá-la publicamente no endereço:

https://docs.embrapa.io/[nome unix do projeto]

Toda alteração realizada neste repositório e versionada (commit e push) é automaticamente atualizada no site do projeto. O tema padrão do site é o mesmo utilizado neste site de documentação da própria plataforma Embrapa I/O.

II. Documentação pública da API

O desenvolvedor poderá instanciar a documentação em Swagger da(s) API(s) disponível(is) no projeto. Ao selecionar esta opção, o autômato de criação de entidades irá criar um novo repositório (denominado io-api) no grupo do projeto no GitLab com o código-fonte inicial desta documentação. Ao mesmo tempo, o autômato de deploy da plataforma irá instanciar a página de documentação da API e disponibilizá-la publicamente no endereço:

https://api.embrapa.io/[nome unix do projeto]

Da mesma forma que o site público, cada alteração e versionamento (pull) neste repositório atualiza automaticamente esta documentação pública.

III. Documentação técnica (não pública)

Ao ativar este repositório (denominado io-doc) será provisionada a estrutura básica de diretórios e arquivos para documentação do projeto de software. Desta forma, a equipe de desenvolvimento já terá acesso aos modelos dos arquivos de que necessita desde a concepção do ativo. Os diretórios inicialmente criados são:

1. Kickoff: Arquivos das tratativas iniciais do projeto que levaram a sua concepção;
2. About: Informações gerais sobre o projeto;
3. Team: Dados dos parceiros institucionais e membros do projeto;
4. Roadmap: Planejamento de entrega de resultados;
5. Development: Documentação do desenvolvimento dos softwares que integram o projeto, tal como diagramas UML, esquemas dos bancos de dados, arcabouço tecnológico, etc;
6. Support: Guias para publicação dos softwares, monitoramento e manutenção;
7. Meetings: Atas de reuniões;
8. Presentations: Apresentações diversas realizadas em eventos e reuniões;
9. Clipping: Notícias veiculadas e notas midiáticas sobre o projeto; e
10. Publications: Artigos e publicações relacionados ao projeto.

IV. Logos e e artefatos visuais

Este repositório (denominado io-art) é dedicado ao armazenamento de arquivos de mídia do projeto, tal como a arte da logo (e suas diversas variações), manual de uso da marca e paleta de cores, artefatos de identidade visual, etc.

V. Binários

Este repositório (denominado io-bin) é utilizado para o usuário inserir binários e chaves de distribuição nas lojas virtuais. Por exemplo, quando um aplicativo desenvolvido para Android é veiculado na Google Play, um dos requisitos é a criação de uma keystore, ou seja, uma chave criptográfica que é utilizada para assinar os arquivos APKs (binários de distribuição). Desta forma, esta chave (e sua senha) não pode ser perdida, pois neste caso não será possível enviar novas versões do aplicativo.

Este mesmo conceito é utilizado por outras lojas virtuais, como a Microsoft Store (passa assinar seus binários APPX). Assim, neste repositório podem ser armazenadas as keystores utilizadas pelo projeto para distribuição, bem como os próprios binários já assinados que serão publicados nestas lojas.

VI. Encapsulamento TWA

Este repositório (denominado io-twa), quando criado, disponibilizará no projeto o código-base para encapsular aplicações do tipo Progressive Web Applications - PWAs ou Single-Page Applications - SPA utilizando a técnica de Trusted Web Activity - TWA para distribuição na loja virtual da Google Play.

Esta é uma das formas de encapsular aplicações em JavaScript, mas existem outras como, por exemplo, utilizando o CapacitorJS ou o Apache Cordova.

Conferindo o GitLab

Quando o projeto é criado fica disponível como um card na dashboard do usuário. Por meio deste card os Architects (Arquitetos da Solução, como explicado na página de Squads) poderão gerenciá-lo. Por exemplo, é possível ativar e desativar os repositórios de suporte e acessar as páginas de documentação pública do projeto e da API.

Por meio do card podemos também acessar o GitLab da plataforma e vericar se as entidades configuradas já foram criadas pelo autômato Genesis (processo que pode demorar alguns minutos). Um ícone com angle brackets (< >) permite o acesso direto ao grupo do projeto.

Caso esteja acessando o GitLab pela primeira vez, atente-se ao seu tipo de usuário na tela de login. Empregados da Embrapa deverão utilizar a aba “Embrapa” na caixa de login com a combinação “m + matrícula” e senha corporativa, enquanto que usuários externos deverão utilizar a aba “Standard” com a combinação de e-mail e senha (configurada por meio do e-mail de boas vindas do GitLab).

Quando o usuário opta por todos os repositórios de suporte do projeto, o grupo inicial no GitLab irá ser inicializado de forma semelhante à imagem abaixo:

Equipe do Projeto

Outra funcionalidade disponível é a gestão da equipe do projeto, que possibilita inserir usuários ao projeto atribuindo-lhes papéis. Inicialmente o projeto terá um único membro na equipe (do tipo Architect), que é o próprio usuário que o criou. Este poderá então adicionar novos usuários, que podem ser de dois tipos:

• Arquiteto da Solução (Architect): Possuem diversas permissões especiais, tal como adicionar novos membros à equipe, relalizar o deploy em produção, o backup de uma build ou ‘derrubar’ uma instância; ou

• Outro (Engineer, Analyst, Manager, Specialist ou Programmer): Podem fazer pull para a branch main e o deploy em ambiente alpha e beta (testes internos e externos, respectivamente).

Atenção! Somente empregados da Embrapa podem ser Architects.

Podem ser incluídos na equipe do projeto usuários que já estejam cadastrados na plataforma ou não. Neste último caso, quando o usuário se cadastrar ele será automaticamente vinculado ao projeto.

Atenção! Empregados da Embrapa devem também acessar diretamente o GitLab pelo menos uma vez para que seu perfil seja importado do diretório de usuários corporativos. Somente após este acesso ele será vinculado ao grupo de repositórios no GitLab e à organização no Sentry.

Uma vez que o projeto tenha sido criado e esteja devidamente configurado, os usuários mantenedores poderão agora adicionar aplicações por meio do botão “Nova App” disponível no card.