Informações úteis

01. CODE REVIEW

Quando o analista finaliza a codificação de uma tarefa deve ser realizado o Code Review, que se trata de uma análise do código por outro membro da equipe, caso haja alguma melhoria ou correção a ser efetuada no código deve ser efetuado antes de avançar a tarefa para a etapa de teste. Ao se realizar o code review de uma tarefa é importante seguir o CheckList do link abaixo:

Orientações Code Review

02. CASO DE TESTE

Ao realizar uma codificação é aconselhável adicionar um comentário na tarefa correspondente, com as orientações de como deve ser realizado o teste.

É importante que esse caso de teste contenha:

O problema
A solução efetuada
As pré-condições (o que deve ser parametrizado no sistema antes de efetuar o teste) e o passo a passo de execução
Sempre que possível detalhar o máximo o caso incluindo até mesmo orientações de onde cada menu encontra-se no sistema, facilitando assim a execução do teste
Orientar se será necessário testar em mais versões. Atualmente o teste é realizado apenas na atual e na versão do cliente, porém se o código de outra versão estiver muito diferente deve ser testado nesta versão também
Orientar se deve efetuar o teste em Oracle
Orientar se é necessário testar com e sem token

Estas orientações também podem ser repassadas/complementadas para o Tester através do chat, ligação, entre outros.

03. TDN

O TDN é uma rede de documentação da TOTVS. O que for criado no TDN deve ser revisado por um membro da equipe antes de efetuar a publicação.

RM - TDN | TDN - Folha de Pagamento

Meu RH - TDN - Meu RH

Padrão de abertura de issue: Padrão de abertura de issue

04. INTEGRAÇÃO CONTÍNUA

É possível verificar o status de build das versões através do link abaixo:

Integração contínua

05. CHECKIN BACK-END

Sempre realizar Checkin na versão atual, somente após os testes realizar o Checkin nas versões de mercado. Deve abrir uma sub-tarefa de codificação na issue para realizar os merges nas versões de mercado.

Para o front realizar o Checkin da atual apenas no Azure na development e nas versões de mercado utilizar as branch de cada release.

As versões de mercado incluem as 3 versões anteriores a versão atual (para realizar Checkin em versões que já estejam expiradas é necessário alinhar com PO).

Checkins realizados até 8h do dia da expedição já saem na versão (esse horário pode variar de acordo com solicitações dos times). O patch é expedido ao 12h caso não haja nenhum atraso.

06. CHECKIN FRONT-END

Para checkins no front-end há algumas regras de boas práticas de programação que devem ser observadas. Segue link:
Guia de boas práticas

Orientações para o checkin

Criar o PR como de costume na branch development;
Realizar merge da branch development para a branch main;
Criar um PR na branch main com os mesmos ajustes do PR do criado na branch development;
Apenas quando os PRs criados executarem com sucesso, avançar a issue pra code review;
Durante o code review ambos os PRs devem ser aprovados, o PR da branch main irá completar e sairá no restore;
A pessoa responsável pela execução dos testes irá executar o restore e efetuar os testes a partir dele;
Após a finalização dos testes um QA deve aprovar o PR da development para que ele complete (caso seja um dev o responsável pelo teste, deve solicitar a um QA a aprovação);
Caso tenha algum defeito:

Realizar a criação de um PR na branch main com o ajuste, utilizando a sub-tarefa de defeito;
Replicar a correção do defeito para o PR da development que está em aberto. Este item precisa ser realizado com cautela para garantir que nada ficará fora do ajuste;
Durante o code review do defeito realizar a aprovação do PR da main, para que ele seja completado e esteja no restore para a realização dos testes.

Observações: As validações do sonnar, executam diariamente no build full que acontece todos os dias às 21:00h, desta forma, sempre verificar no dia seguinte das alterações, se algo foi quebrado no sonnar e já realizar o ajuste.

07. MERGE

Manutenção: Conforme acordado com o time em reunião de retrospectiva, fica acordado que o merge de correção das issues de manutenção ocorrerá para todas as versões de mercado. Quando a correção for extremamente complexa, em último dos casos, verificar antes com o PO.
Story (Inovação): Conforme acordado com o PO.

08. MERGE FRONT-END

Com a migração das soluções do TFS para o Azure, a partir de agora o processo de merge para as versões de mercado deverá ser realizado, conforme documentação abaixo:
Processo de Merge - Frontend Legado

09. TESTES

Sempre realizar teste na versão atual e na versão do cliente, exceto se o desenvolvedor orientar que o teste deve ser realizado em alguma outra versão.

Para a realização dos testes na versão do cliente, quando alterado o frontend é orientado como boa prática, sempre retestá-la pelo restore e jamais por dist. Isso porque nesses testes é possível pegar problemas na liberação da correção para o cliente.

Issues com status ‘Teste de aceitação concluído’ até as 12:00 do dia da expedição tem a notificação do cliente realizada de forma automática, desde que a release para notificação esteja preenchida.

10. AUTOMAÇÃO DE TESTES

É importante sempre que possível realizar automações nas Issues de inovações. Seguem alguns documentos importantes para orientar na execução destes testes:

Automação com Protactor

Automação de Contrato (Postman)

Projeto de Testes de Contrato

Dashboard Automação

OBS: Solicitar acesso as planilhas.

11. GATED CHECK-IN

Ao se realizar um check-in é realizado uma verificação para prevenir a quebra de build, caso seja localizado algum problema este é interrompido. É possível verificar o status dos check-ins no link abaixo: É importante também efetuar Get e realizar o build antes de cada Checkin e/ou Merge.

Gated Checkin

12. PORTAL DA ENGENHARIA

É possível verificar a data de expedição dos Patchs e Releases:

Engenharia BH: http://engenhariabh/DashboardExpedicao ou http://bh-eng-websrv.sp01.local/DashboardExpedicao (Conectado a VPN)
Para mais dúvidas consultar FAQ: Expedição de Patches

Observações:

A antepenúltima release de mercado é expedida somente as sextas;
As outras releases de mercado são expedidos toda quarta e sexta;
Patchs expirados ou que precisem ser expedidos com urgência devem ser solicitados através de uma versão emergencial;
Checkins realizados até 8h do dia da expedição já saem na versão (esse horário pode variar de acordo com solicitações dos times);
Issues com status ‘Teste de aceitação concluído’ até as 12:00 do dia da expedição tem a notificação do cliente realizada de forma automática, desde que a release para notificação esteja preenchida.

13. SONNARQUBE

É uma ferramenta que demonstra algumas melhorias que devem ser efetuadas no código com base em regras pré-definidas pelas equipes. No link abaixo é possível verificar quais são estes itens:

Geral - Sonar

14. SOLICITAÇÃO DE SCRIPT

É efetuada a solicitação de script através da ferramenta 'AutoScript', onde a solicitação é encaminhada para a aprovação da equipe de banco de dados. Segue link abaixo:

Auto Script: http://engenhariabh/AutoScript

15. VALEU

É utilizado para reconhecer atitudes positivas dos participantes. Ao final de cada dois meses é realizada uma reunião para realizar a leitura de alguns destes reconhecimentos. O Valeu deve ser acessado através do performance e metas.

Performance e Metas: https://totvs.rac.totvs.app/totvs.rac

16. LICENÇAS ALURA

Para realizar algum curso do Alura é necessário reservar a licença por um determinado período. No momento é necessário utilizar o acesso de um dos People leads, presentes na planilha abaixo, devendo também marcar na planilha um horário vago para realizar o curso.

Link do Alura: Link Alura
Link da planilha para realizar a reserva: Planilha Alura

17. DASBOARD MEU RH

No Jira as Issues do Meu RH podem ser consultadas através dos links abaixo.

https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=7703

https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=71424

18. ISSUES PARA APONTAMENTO

Diversos: https://jiraproducao.totvs.com.br/browse/DRHMEURH-8259

Eventos ágeis: https://jiraproducao.totvs.com.br/browse/DRHMEURH-8258

Apoios que não possuem issue: https://jiraproducao.totvs.com.br/browse/DRHMEURH-8552

Investimentos no Time: https://jiraproducao.totvs.com.br/browse/DRHMEURH-8256

19. MANUTENÇÕES INTERNAS

Para defeitos internos encontrados deve ser alinhado com proxy e/ou PO para realizar a abertura de defeitos internos.

20. DOWNLOADS E ATUALIZAÇÕES

Portal do cliente, onde são realizados os downloads das versões pelos clientes.

Portal do Cliente

21. SERVIDORES

\\bhengfiles\Publicado: Os Patchs ficam disponíveis neste diretório.
\\bhengfiles\VersoesHomologacao: As bases de dados exemplo e vazias ficam neste diretório.
\\bhengfiles\rmflex$\Outros\Ferramentas: Algumas ferramentas como o Restore e RM-Específica ficam disponíveis neste diretório.

22. DRIVE COMPARTILHADO

Drive compartilhado da equipe e atendimento: Drive Meu RH

23. VPN

Configuração da VPN: Configuração VPN

24. CONFIGURAÇÕES MEU RH

Configurar Meu RH (Gerenciador de serviços da informação IIS): Configurar Meu RH

25. FERRAMENTAS APIDOG

Utilizada para a definição de contratos do Meu RH. Segue abaixo link:

ApiDog

Obs: As credenciais de acesso devem ser solicitadas ao time.

26. RESTORE

Utilizado para montar os ambientes do RM.

Documentação: https://tdn.totvs.com/pages/releaseview.action?pageId=607585039

Restore: https://totvsrestore.z15.web.core.windows.net/#/user-environments

27. JIRA

Jira: Utilizado movimentar as issue, algumas definições importantes:

Sempre que assumir uma issue preencher os campos;
Release para notificação: Sempre com a versão do cliente e sempre antes do Checkin (para notificar corretamente o cliente);
Fix Version/S: Preencher com a versão atual;
Se a issue for critica deverá preencher a 'Causa ocorrência ' que gerou o problema;
Para issues do tipo 'Defeito' necessário especificar o erro e também o que foi a correção.

28. INTEGRAÇÕES

O Meu RH e RM possui integrações. Abaixo você encontrará links para configuração e utilização das integrações.

Login:

Azure AD (OAuth):
- Criação do aplicativo do Azure AD
- Integração Azure AD utilizando OAUTH2
Auzre AD (SAML):
- Integração do RM com Azure AD via SAML
Fluig Identity (SAML):
- Autenticação utilizando TOTVS Identity

29. MÁQUINAS VIRTUAIS

Atualmente temos uma VM para testes com o Meu RH instalado nas versões 12.1.2306 (Atual) e 12.1.2209.

Nesta VM estão configuradas as bases de exemplo SQL Server.

Para testes em Oracle, alterar apenas para apontar para base BH-ENG-ORACLE.SP01.LOCAL/MEURH

10.80.129.35 - Com migração da VM para SP ela mudou de IP e DNS.

Dados da VM:

Endereço/Nome: 10.80.129.35 (Antigo e descontinuado)
Endereço IP: 10.171.81.38
DNS: JOISRVAPLDEV006.jv01.local

Usuário e Senha: Utilizar os de rede, com o domínio antes do usuário (sp01, bh01, jv01). Caso não tenha acesso, deverá ser aberto ticket no jira, conforme link a seguir: https://atendimento-totvs.atlassian.net/servicedesk/customer/portal/11/group/411/create/1355 e preencher com as informações solicitadas.

O RM está instalado no diretório padrão, ou seja, C:\RM\Atual\Release ou C:\RM\Legado\{Versão}.
Os sites estão como: http://localhost/{Versao}/web/app/RH/PortalMeuRH (Acesso interno do servidor) ou http://10.80.129.35/{Versao}/web/app/RH/PortalMeuRH (Acesso fora do servidor). A versão atual está como Atual, as demais estão com a versão, incluindo o ponto. Ex.: 12.1.2209.
Os backups das bases de dados estão na pasta C:\BASES_ORACLE.

40.79.251.95

Esta VM está sendo utilizada somente quando é necessário testar as integrações do Fluig (Identity) ou do Azure (OAuth) no aplicativo, pois requer um site com certificado SSL válido (HTTPS).

Dados da VM:

Endereço/Nome: 40.79.251.95 ou rm-vm

Usuário: rm-vm\goliveira
Senha: !@Meurh123@! (Caso não acesse conversar com Guilherme Oliveira (Guigui)

30. DEBUG TCLOUD

Verificar o TDN com as Orientações para debug;

Verificar se possui acesso ao TCLOUD, caso não possua acionar o PL para solicitar acesso;

Para conectar ao Portal TCloud siga o exemplo abaixo:

31. DEBUG DNSPY

Seguir as Orientações DnSpy

32. PLANILHA DE AUSÊNCIAS

As ausências relacionadas a férias, compensação de horas, abonos, etc devem ser inseridas na planilha abaixo para controle.

Planilha de Ausências

33. ACESSOS

JIRA
TFS
Azure
Universidade TOTVS
RM Específica (Solicitado pelo colaborador via e-mail)

Instruções: Enviar e-mail para: [email protected] solicitando o cadastro no RM específica
Assunto: Acesso ao RM Especifica
Texto deve conter:
CPF:
Nome completo:
Módulos que atua: RM Labore, Chronus, Vitae e SMT
E-mail:

VPN
Grupos de e-mail:
MeuRH.Todos
TribeRH.MeuRH.RM
TDN (Solicitado pelo colaborador ou gestor pelo link abaixo)
https://atendimento-totvs.atlassian.net/servicedesk/customer/portal/7/group/219
Alura
Apicurio (Solicitar ao AM)
Drive compartilhado
Chat/Discord
Planilhas de automação
Planilha de ausências
Para realizar desenvolvimento mobile: Orientações para Desenvolvimento Mobile

34. FERRAMENTAS

Visual Studio: Visual Studio
Build Tools for Visual Studio (Necessário a instalação caso os testes unitários de backend não sejam executados e não seja exibido erro na execução): Build Tools For Visual Studio;
Restore: \\bhengfiles\rmflex$\Outros\Ferramentas\RM Restore (Novo)
RM-Especifica: \\bhengfiles\rmflex$\Outros\Ferramentas\RM Especifica
Banco de dados: SQL
Visual Studio Code (Sugestão): Visual Studio Code
Git Hub Desktop (Sugestão): Git Hub
Check In Policies e Eng.Pack: Checkin Policies e Eng.VSPack

35. CAPACITAÇÕES

LIB
Repositório RH com vídeos de treinamentos: Diversos
Jira

36. BASES ORACLE

Caminho das bases Oracle que utilizamos:

Versões:
- 12.1.2406: BH-ENG-ORACLE.SP01.LOCAL/MEURH
- 12.1.2402: BH-ENG-ORACLE.SP01.LOCAL/EXRH2310

Caminho para verificar as bases: http://bh-eng-websrv.sp01.local/DashboardAmbientes/database