O presente artigo apresenta fluxo para o desenvolvimento, detalhando as fases que o processo de inovação, manutenção e SQA deverão seguir, e o responsável de cada ação da etapa. Além de alguns pontos de atenção, como a especificação do Release Notes, e em qual momento atualizar os ambientes de desenvolvimento, de produção e do SQA.

Inovação

Os seguintes passos devem ser seguidos pelo analista de inovação/manutenção que irá adicionar novas funcionalidades ao projeto do TOTVS Smart Analytics:

1. O analista de inovação/manutenção deve gerar a especificação referente à sua tarefa, se esta for necessária, e ao finalizar, enviá-la para homologação.

   Em uma tarefa da Inovação, durante a etapa de especificação, no Release Notes, o analista deverá enumerar todos os datasets e graphs que alterará ou adicionará.

2. Ao obter o retorno da homologação, se esta foi negativa, realize as alterações necessárias e envie novamente para homologação. Ao obter uma resposta positiva, dê continuidade aos próximos passos.
3. Antes de iniciar a codificação, o analista deverá primeiro realizar o check out do pacote com o projeto do TOTVS Smart Analytics mais atual no TFS, e copiá-lo como um projeto local.

4. Abra o projeto local com a ferramenta Cloud Connect, e dê início à etapa de codificação.

   Em uma tarefa da Manutenção, durante a etapa de codificação, no Release Notes, o analista deverá enumerar todos os datasets e graphs que alterará ou adicionará. Tanto para a Inovação, quanto para a Manutenção, o analista deverá, irrefutavelmente, manter nota de todos datasets e graphs que foram alterados ou adicionados, para manter o Release Notes atualizado. Dessa forma, o cliente customizado terá a informação necessária para realizar a atualização de seu projeto.

5. A codificação inicia-se com a modelagem, quando necessário, e é preciso publicá-la na nuvem do GoodData ao finalizá-la, antes de dar continuidade às alterações no ETL. 

   A modelagem é codificada em um único arquivo, o que pode gerar problemas no desenvolvimento em paralelo. Para evitar erros e substituições indevidas, converse com os outros desenvolvedores do produto, se não há outra pessoa em posse do arquivo, antes de iniciar as alterações. É possível que antes de um analista finalizar toda a codificação necessária (modelagem, ETL e dashboards), ele precise incluir o arquivo de modelagem em outro servidor de versionamento (como por exemplo, o SVN, que é usado atualmente), para que outro analista possa baixá-lo e iniciar outra codificação em paralelo. Pode ocorrer o mesmo, se mais de um analista precisar realizar alterações em um mesmo graph. Portanto, o TFS deverá ser utilizado para realizar check in do projeto completo, somente ao finalizar toda a codificação. E outro servidor de versionamento, poderá ser utilizado para facilitar o desenvolvimento em paralelo.

   No momento de realizar a publicação da modelagem, é possível verificar as alterações que serão adicionadas ao modelo que se encontra na nuvem. Além disso, é possível visualizar e copiar os script MAQL destas atualizações. Como boa prática, este script MAQL deve ser anotado e salvo pelo analista de inovação/manutenção, pois este script será enviado no pacote de atualização do TOTVS Smart Analytics, no Portal do Cliente, para que dessa forma os clientes que possuem customizações, possam atualizar sem perder suas alterações.       Durante esta etapa, o analista de inovação/manutenção deve-se atentar para editar o versionamento de modelagem devidamente.

6. A seguir, as alterações de ETL poderão ser realizadas, e ao finalizar, o analista de inovação/manutenção deverá, então, efetuar o deploy/re-deploy no ambiente de desenvolvimento.

   Durante esta etapa, o analista de inovação/manutenção deve-se atentar para editar o versionamento de ETL devidamente.

7. Para concluir a etapa de codificação, só resta ao analista realizar a criação de métricas, relatórios e/ou dashboards no analytics.totvs.com.br, no ambiente de desenvolvimento.
8. Ao finalizar esses passos, o analista de inovação/manutenção deverá realizar o check in do projeto atualizado no TFS. E então, sinalizará para o analista responsável pelo teste unitário, de que o projeto já está disponível.
9. O analista responsável pelo teste unitário, por sua vez, deverá atualizar o projeto baixando o projeto, a partir do get latest version do TOTVS Smart Analytics no TFS.
10. A partir de então, este analista deverá realizar o teste executando o Agent, ou rodando localmente no Cloud Connect, no ambiente de desenvolvimento (dependendo do que foi codificado, outro tipo de teste pode ser mais cabível). E se necessário, também deverá checar se os dados foram carregados na nuvem, por meio de criação de relatórios em analytics.totvs.com.br.
    1. Se for encontrado algum erro, o analista que realizou o teste deverá alinhar com o analista desenvolvedor o próximo passo de correção (por exemplo, abrir tarefa de defeito ou rejeitar a ficha). Após corrigir os erros, o projeto no TFS e no outro servidor de versionamento, deve ser atualizado.
    2. Se os testes forem executados com sucesso, também deve-se sinalizar ao analista de inovação/manutenção que o projeto está funcionando corretamente. 
11. Ao obter o retorno de que o teste unitário foi realizado com sucesso, o processo poderá continuar. O analista de teste deverá realizar os mesmo procedimentos anteriores: Baixe o projeto atual do TFS, clicando em get latest version, publique a modelagem e efetua o re-deploy do projeto no ambiente do SQA.

12. Quando o analista de testes finalizar estes passos iniciais, ele deve sinalizar o analista de inovação, que por sua vez irá realizar a exportação das métricas, relatórios e dashboards desenvolvidos no front-end, para obter um token (este token é válido somente por 24 horas), por meio da extensão do Chrome para o GoodData. 

    Para maiores informações sobre a extensão do Chrome, acesse: Como acesso o GoodData Extension Tool para o Analytics.TOTVS.com.br ?

    
    

    
    

13. O analista de inovação enviará o token para o analista de testes, para que este realize a importação, também utilizando a mesma extensão do Chrome.
14. A partir deste momento, o analista de testes ficará encarregado de testar o projeto TOTVS Smart Analytics.
    1. Se um ou mais erros forem encontrados, o analista de testes deverá alinhar com o analista de Inovação, e abrir tarefa de defeito para devida correção do(s) erro(s).
    2. No caso da Manutenção, o analista de testes deverá rejeitar a ficha, para retornar a codificação para o analista desenvolvedor.

15. Quando os testes forem finalizados com sucesso, o analista de testes deverá dar o sinal de sucesso para o analista de inovação/manutenção, para que este mantenha o ambiente de Produção atualizado, conforme fechamento de releases.

    É necessário exportar as métricas, os relatórios e os dashboards que foram criados ou alterados para o ambiente de Produção. Isso poderá ser executado em 2 momentos: - No final deste processo, se o que foi alterado no front-end não depende de alterações no projeto (por exemplo, uma manutenção na fórmula de uma métrica). - Somente no fechamento de release, se o que foi alterado, depende do projeto mais atual (por exemplo, na criação de uma área nova).

fluxo_interno.bpm

Manutenção

Os seguintes passos devem ser seguidos pelo analista de inovação/manutenção que irá alterar ao projeto do TOTVS Smart Analytics:

1. O analista responsável pela abertura da FNC de Erro/Melhoria criará a FNC após notificação do solicitante que alerta sobre algum erro ou deseja uma melhoria.
2. O analista de manutenção verificará se a FNC procede:
   1. Em caso negativo, a FNC será rejeitada, e o solicitante será informado das justificativas.
   2. Em caso positivo, os passos do cenário de Inovação, apresentados acima, deverão ser seguidos.

   No último passo, neste caso, o analista de testes deverá, além de sinalizar ao analista de inovação/manutenção, também informar ao solicitante que sua FNC foi concluída com êxito.

Check List para Inovação - Criando uma nova área:

Ao implementar uma nova área no projeto TOTVS Smart Analytics, deve-se englobar todos os itens abaixo, nesta sequência de desenvolvimento:

Desenvolvimento do projeto no Cloud Connect

1. Incluir novas fatos e dimensões na Modelagem.

   Ao finalizar a modelagem, é necessário publicá-la para a nuvem, antes de continuar o desenvolvimento do ETL.

2. Desenvolvimento do processo de ETL:
   • Cada Dataset da modelagem gera um Graph, divididos nas pastas fact e dimension.
   • A cada Graph são gerados, ao menos, dois Metadados.
   • A cada Graph de fato é criado, ao menos, um parâmetro, chamado FACT.
   • Cada Graph de fato é composto de duas partes: 
     • A primeira "Apagar Fato" executa a delação de registros, conforme o arquivo Purge.
     • A segunda "Prepara Fato para a Carga", realiza o carregamento de dados.
3. Incluir novos Graphs no Main Job.
4. Adicionar novas fatos no arquivo Purge.
5. Realizar deploy do projeto no ambiente desejado.
6. Inserir buscas das novas fatos e dimensões no arquivo my.properties.

Desenvolvimento do projeto no Smart Analytics

1. Criação das métricas, a partir das fatos presentes na modelagem.

2. Geração os relatórios:

   Relatórios referentes à experiência 4, crie uma pasta nova, com este nome: "#Fluig NOME_ÁREA". E então crie os relatórios dentro desta pasta. Relatórios que serão incluídos no dashboard da área, crie uma nova pasta, com o seguinte nome: "_Dashboard NOME_ÁREA". A partir de então, adicione os relatórios nesta pasta.

3. Elaboração dos Dashboards.

   Sempre que possível, utilize um dashboard já existente como base: Como copio uma aba de dashboard padrão do TOTVS Smart Analytics para outro dashboard criado pelo usuário?

4. Formulação dos relatórios de homologação de métricas.

   Crie estes relatórios na pasta "_Homologação métricas". Este relatório deverá ser criado de forma a ser comparado com a Fluig Smart Data, portanto coloque na descrição, a query utilizada para comparar os valores.