Meu RH

Atalhos

Árvore de páginas

Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 18 Próxima »

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. DASHBOARD 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. 


Para utilização do Meu RH é importante configurar os seguintes Instaladores:

  • Corpore.Net (páginas aspx e dlls da pasta Bin);
    • Possível caminho de instalação:
      • Versão Atual: C:\RM\Atual\Release\Corpore.Net;
      • Versão Legado: C:\RM\Legado\Versão\Corpore.Net;
  • Frame Html;
    • Possível caminho de instalação:
      • Versão Atual: C:\RM\Atual\Release\FrameHTML;
      • Versão Legado: C:\RM\Legado\Versão\FrameHTML;
  • RM.Net do RM:
    • Possível caminho de instalação:
      • Versão Atual: C:\RM\Atual\Release\Bin;
      • Versão Legado: C:\RM\Legado\Versão\Bin;
  • Portais RM (Push Notification ou ComunicaRH):
    • Possível caminho de instalação:
      • Versão Atual: C:\RM\Atual\Release\Bin\wwwroot;
      • Versão Legado: C:\RM\Legado\Versão\Bin\wwwroot;

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:


29. INTEGRAÇÃO AZURE AD


Seguem informações para testes utilizando configurações do Portal Azure do Meu RH da Linha RM.



  • Dados das configurações no Azure: 

    Alterar somente a URL de Autenticação, configurando Aplicativo de página única para o endereço de IP da máquina.


30. 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)

31. 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:


32. DEBUG DNSPY

Seguir as Orientações DnSpy

33. 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

34. 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:

35. 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


36. CAPACITAÇÕES

37. BASES ORACLE

Caminho das bases Oracle que utilizamos:

  • Versões:
    • 12.1.2410: BH-ENG-ORACLE.SP01.LOCAL/MEURH (validade 15/05/2024 - 13/08/2024)
    • 12.1.2406: BH-ENG-ORACLE.SP01.LOCAL/MEURH2406 (validade 26/09/2024 - 25/12/2024)

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

Observações:

  • Ao utilizar a base crie um usuário novo, não utilize o usuário mestre para testes que envolvam permissionamento.
  • Manter os registros atualizados sempre que possível (período de ponto, competência, entre outros);
  • Ao converter a base de dados ou realizar alguma alteração de estrutura sempre verificar com o time se alguém está utilizando a base.

38. TESTE UNITARIOS BACK-END

Execução de Testes Unitários de Backend no Visual Studio

Caso tenha sido instalado o Visual Studio corretamente e o componente de Ferramentas de Build (Build Tools for Visual Studio), citado no tópico de Ferramentas para instalar, porém os testes ainda não tenham sido executados e os testes sejam nas soluções Fop-Folha (Folha e Folha.WebForms), remover os arquivos abaixo localmente:


  • Sem rótulos