Datasul
Board: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=9517
Dashboard do analista: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=63019
Board kaizen: https://slice.wbrain.me/#/list/n3bKQCbnjXF6UAYwkV
Protheus
Board Scrum: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=8831
Board Kanban: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=9520
Pontuação/velocidade: https://docs.google.com/spreadsheets/d/1dGu7vTsiMlPqpzenbX3F_BDy11Mbd3RR6JsfLkMT4hI/
Dashboard do analista: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=63020
Board retro: https://slice.wbrain.me/#/list/rHjgDDyo9O66c5Uav5
RM
Board: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=10707
Dashboard do analista: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=62912
Board retro: https://slice.wbrain.me/#/list/ddq0T0K4BHRhs02Xx7
Todas
OKR: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=69615
Ações de melhoria: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=5213
Dashboard do analista: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=63020
Alguns números de entrega: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=64500
Dashboard Meu RH: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa
Daily Geral: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=10885
Acordos:
- Apresentar somente as issues fechadas (exceto quando o PO solicite que apresente tarefas incompletas);
- Mostrar a issue no jira e explicar o contexto e a regra do negócio (rapidamente);
- Foco na demonstração do produto que foi entregue e preferencialmente no mobile;
- Todas as sugestões de melhorias e comentários podem ser ditas para que o PO anote;
- Apresentação é mensal dividida em 3 agendas seguidas;
- O tempo da apresentação médio é de 20min, quando for variar é necessário ajustar o invite;
- Para facilitar a organização é gerado um TDN de cada Review DRHMEURH.
Última revisão em
Acordos:
- Compartilhar o board;
- Foco no que falta para entregar as tarefas;
- Os impedimentos e necessidades de ajuda já saem mapeados com responsável por resolver/ajudar;
- Não é status report (muito menos pro AM);
- Revisão da estratégia de entrega.
Última revisão em
Boards:
Datasul: https://slice.wbrain.me/#/board/yFpJECboWweDlG91Lo
Protheus: https://slice.wbrain.me/#/list/axSPfnqABzKEq3Uitz
RM: https://slice.wbrain.me/#/list/dpobba5mvdoChRmrMj
Todos os materiais utilizados estão no drive: RH ->Novo RH -> Meu RH
AM transcreve as ações de melhoria para o Jira e adiciona no board dos times.
Board só de ações de melhoria: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=5213
DoR - Definição de Pronto do Refinamento de negócio/funcional
- Quando tiver legado fazer a leitura e análise das documentações do produto para escrever as stories
- Analisar os parâmetros/parametrizador relacionado a funcionalidade e especificar o que deve ser levado em consideração (quando houver necessidade abrir spike para o time apoiar)
- Detalhamento do fluxo e necessidade do usuário (issuetype Story), esperada pelo PO e time de UX
- Critérios de aceite devidamente descritos e apresentados, e que não apresentem riscos/dúvidas
- Especificar em quais linhas de produto deve ser feito desenvolvimento e teste (separar os epic por linha de produto)
- Quando for nova funcionalidade especificar em qual Versão/Release ela será disponibilizada
- Descrever como devem ser os Permissionamentos e se deve considerar no Mais acessados
- Adicionar o Link Issues quando uma issue for dependente de outra
- Quando já houver o front-end pronto, verificar como funciona na linha que desenvolveu. Descrever as diferenças para a linha que irá desenvolver em comparação com a outra linha e protótipo
- Ter documentação de UX completa
- (Responsabilidade UX) ter prototipado pensando em como funciona nas 3 linhas (tamanho e tipo do campo)
- (Responsabilidade UX) Ao final de cada prototipo fazer a validação com as 3 linhas (uma pessoa de cada linha) - Design Critique
Refinamento negócio:
Datasul: quinzenal, normalmente, sexta-feira às 16:00, mas caso o fluxo esteja bem abastecido reagendamos
Protheus: quinzenal, quinta-feira, 09:00 - 10:00
RM: quinzenal, normalmente, segunda-feira às 09:00, mas caso o fluxo esteja bem abastecido reagendamos
Refinamento técnico:
Datasul: acontece após o refinamento de negócio
Protheus: acontece após o refinamento de negócio
RM: acontece após o refinamento de negócio
Acordos:
- Cumprir o DoR
- O refinamento de negócio é apresentado pelo PO, com foco no entendimento da demanda e explicação do valor
- No refinamento técnico, a squad define a estratégia para cada item, quando necessário participa todo o junto
- Toda discussão deve ser registrada na issue
- O teste integrado, casos de uso e automação devem ser considerados
- Após refinado o status da issue deve ser "Grooming concluído"
Última revisão:
Acordos:
- Agenda separada para revisão de PR todos os dias às 9hrs e às 14hrs onde todos os analistas devem praticar a revisão
- Cada analista só pode ter um PR em aberto
- Grupo de tester como required em todos os PRs, ou seja, os PRs só irão pra dev/master quando o tester aprovar
- Será feito merge da dev pra master toda sexta-feira, em sistema de rodízio por squad
- 07/01: Datasul
- 14/01: Protheus
- 21/01: RM
- 28/01: Datasul
- No canal #pull-requests sempre será enviado quando um novo PR for aberto
Acordos para definição de contrato:
- Seguir o padrão de API da TOTVS https://api.totvs.com.br/guia
- A primeira linha que pegar a tarefa fica encarregada de fazer o Modelo rascunho de contrato (não esquecer de duplicar o doc e não editar o original);
- As outras linhas devem analisar o rascunho, fazer as anotações e comentários;
- Na discussão ter uma pessoa de cada linha e um especialista de front (não ter muitas pessoas pra evitar o prolongamento da agenda)
- Alterar versão sempre que tiver modificação (versão 1.3.2 | 1-> alterações de API incompatíveis | 3-> adiciona funcionalidade de maneira compatível com versões anteriores | 2-> correções de bugs compatíveis com versões anteriores)
- Deixar APIs preparadas para paginação (page, pageSize)
- Permissions para determinar quais menus/botões de função que serão exibidos
- fieldProperties para determinar quais campos serão exibidos para cada linha
- Formato de data: String as Date-Time
- Utilizar padrão lowerCamelCase
- Após atualizar o Apicurio subir o PR para o DocsMeuRH
Acordos para desenvolvimento de API:
- Sempre devolver todos os campos do contrato (quando a linha não utilizar devolver como null)
- Atentar aos fieldProperties que precisem ser enviados
- Só liberar a funcionalidade no permissions quando estiver concluída
Falta definir:
- Padrão para contratos
- Padão de nomenclaturas de rotas
- Documentação de fieldProperties
Última revisão em
Acordos:
- Deve ser criada e atribuída a subtarefa de Design em todas as tarefas que precisem de validação;
- A etapa de validação de UX deve ser feita no status em Codificação;
- O tempo média de resposta é de 1 dia, caso precise de prioridade avisar o analista de UX (AM Ronize Junkes Schmitz);
- As telas de aprovações do datasul não fazem parte das revisões e protótipos do Ux, quando necessário solicitar apoio pontual;
- Quando a issue for de back-end, normalmente, significa que o front-end já foi feito e validado, com isso as tarefas de back-end dispensam nova validação com protótipo;
- No Design critique ter um dev de cada linha de produto:
- Protheus: Henrique, Jose Marcelo, Alberto, Fabio
- RM: Zaira, Bianca, Valdemar, Flavio, Robson, Raniel
- Datasul: Eslin, Marcia
- Usar link do fluxo completo ao invés do link da tela (porque estes mudam a cada versão);
- Sempre que tiver um link de protótipo verificar se está no versionamento mais atual;
- Ajustes de protótipo devem ser solicitados antes do comprometimento com a issue, assim teremos tempo hábil para o UX alterar posteriormente (esse é o processo padrão, devemos abusar do design critique pra antecipar esses erros);
- Quando esses ajustes aparecem no decorrer da execução da tarefa o UX dará um entendimento e rascunho de como deve ser feito para o time não ficar parado e o UX faz o mapeamento para voltar com essas alterações no momento em que for planejado;
- O time de dev fica sabendo das alterações através do canal #UX ;
- Combinamos de sempre usar os componentes do PO-UI e quando houver exceções e precisar criar componentes que não estão no PO-UI, o ideal é criar um novo componente, não ficar sobrescrevendo os componentes do PO-UI, porque quando o time do PO-UI ajusta o componente gera a possibilidade de quebrar;
- Convencionar o uso de ícones do https://po-ui.io/guides/icons;
- Quando houver necessidade de um diferente alinhar com o time de dev no discord, design critique ou notion e deixar salvo em SVG;
Pendentes:
- Repasse para o time sobre a percepção dos usuários após a entrega de novos requisitos;
- Sistema muito diferente do protótipo;
- Onboarding com conceitos de UX para novos analistas;
- Analisar itens que o UX tem encontrado nas demandas para fazer análise de causa raiz;
- UX possuir o tamanho e tipo dos campos em cada linha para montar o protótipo que atenda.
Guia de Padronização conforme pauta do dia com a Helen.Almeida
Última revisão em
Acordo entre Atendimento, Consultoria e Desenvolvimento RH RM para abertura de tarefas no Jira
Padrão de abertura de issues para Meu RH RM
Padrão de abertura de issues para Meu RH Datasul (Atualizado)
- Qual é a quantidade diária esperada de horas apontadas por dev?
Apontar no Jira conforme o espelho do ponto, distribuindo os apontamentos nas atividades que realizou ao longo do dia.
- As ausências de férias, compensações e afastamentos precisam ser apontadas?
Não, mas adicionar na planilha de ausências 2024, para 2025 utilizar planilha de ausências 2025
- Qual tipo de apontamento para o totver que preparou e ministrou repasse/treinamento ou participou/assistiu um treinamento?
Para quem preparou e ministrou apontar na DRHMEURH-8550 - Obtendo detalhes do item... STATUS
Para quem assistiu/participou de um treinamento ou capacitação, apontar na DRHMEURH-8549 - Obtendo detalhes do item... STATUS
- É preciso apontar as dailies e os eventos ágeis?
Sim,
A daily apontar na DRHMEURH-8547 - Obtendo detalhes do item... STATUS ou na própria tarefa que está atuando no momento.
Os refinamentos na DRHMEURH-8546 - Obtendo detalhes do item... STATUS
A review na DRHMEURH-8544 - Obtendo detalhes do item... STATUS
A Planning/Replenishment na DRHMEURH-8543 - Obtendo detalhes do item... STATUS
A Retrospective/Kaizen na DRHMEURH-8545 - Obtendo detalhes do item... STATUS
Os OKRs e seus acompanhamentos na DRHMEURH-11520 - Obtendo detalhes do item... STATUS
- Como apontar os apoios?
DevTeam: na issue que a pessoa está atuando.
Outro DevTeam: apontar na issue do projeto da pessoa.
Atendimento: na issue do atendimento.
Cliente: na issue do cliente.
Quando não houver issue: lançar na issue DRHMEURH-8552 - Obtendo detalhes do item... STATUS
Quando for um apoio pontual: lançar na issue DRHMEURH-8551 - Obtendo detalhes do item... STATUS
- Onde apontar as reuniões de feedback, OKR, alinhamentos?
Na tarefa DRHMEURH-8554 - Obtendo detalhes do item... STATUS
- Onde apontar problemas na VPN, ferramentas da totvs indisponíveis, falha do Notebook ou qualquer indisponibilidade ou ociosidade gerados por parte da TOTVS?
Esse é um exemplo de apontamento na issue de contingência DRHMEURH-8555 - Obtendo detalhes do item... STATUS .
- Preciso apontar as pausas/banheiro/café?
Não é necessário, entende-se que esse tempo estará agregado na issue que está atuando.
- Onde apontar problemas na minha energia/internet?
Não apontar.
- Sou novo na equipe, devo apontar?
Sim, com exceção da semana dos treinamentos iniciais, todas as atividades que a pessoa estiver atuando, devem ser apontadas.
O objetivo da atuação do Meu RH é Atuação na camada rest, front-end e app, mas em um período houve uma estratégia que o Meu RH assumiu as todas as partes das entregas para acelerar o crescimento do produto.
O cenário de Protheus é que muitas regras estão dentro dos fontes do Meu RH, inclusive com várias duplicidades.
No RM, a divisão é bem clara porque o portal antigo e o Meu RH utilizam os mesmos dataservers, onde o dataserver é de responsabilidade de produto.
No Datasul é mais complexo porque misturou regras nos fontes do Meu RH e API.
Para Datasul existe o seguinte acordo:
- A partir de 01/05/22 novas demandas de API (regra de negócio) serão tratadas pelos times de Datasul:
- DRHJORNDTS - Jornadas
- DRHROTDTS - Rotinas
- DRHCALCDTS - Cálculos
- DRHHCM - Capital humano
- Após a transferência, caso falte alguma evidência ou simulação deverão ser solicitadas diretamente ao atendimento ou rejeitadas;
- Quando houver a necessidade de atuação do Meu RH em algum teste ou apoio, deve ser gerada uma issue do tipo Apoio e solicitada prioridade ao PO para incluir no planejamento;
- As issues continuaram sendo abertas para o Meu RH (DRHMEURH):
- Quando se tratar de problemas nas APIs serão transferidas para o projeto correspondente;
- É importante ter o comentário da análise feita pelo Meu RH explicando porque foi transferida;
- Feito estudo na DRHMEURH-4951 (documento) para listar quais regras estão dentro dos fontes do Meu RH, será feito um planejamento para manter as regras somente nas APIs, após isso será necessário um novo alinhamento para as aberturas serem direcionadas para cada projeto pelo atendimento.
Última revisão em
https://tdn.totvs.com/display/public/NPR/
http://tfs2015.totvs.com.br:8080/tfs/_home
https://dev.azure.com/totvstfs/AppMeuRH/_git/Portais
https://studio.apicur.io/dashboard
Espelho de tela mobile x windows scrcpy: https://drive.google.com/file/d/1on2oAvudNFLIw3MvL3vDgba88H1qxETb
App para conectar VPN no celular: https://play.google.com/store/apps/details?id=com.f5.edge.client_ics&hl=pt-br
Apontamento no TOTVS 12: https://docs.google.com/document/d/1gBtvg0ZA-XPiteqkTlZbKsxezrlR28jc/
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:
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.
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
Integração Contínua: É possível verificar o status de build das versões através do link abaixo:
Check-in no 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.
Check-in no 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.
Merges Issues:
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.
Merges de 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
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.
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 de Contrato (Postman)
OBS: Solicitar acesso as planilhas.
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.
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.
Sonarqube: É 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
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
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
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
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
Issues para apontamentos de reuniões, apoio, etc.
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
Manutenções internas do RM (defeitos internos encontrados).
Deve ser alinhado com proxy e/ou PO para realizar a abertura de defeitos internos.
Downloads e atualizações: Portal do cliente, onde são realizados os downloads das versões pelos clientes.
Servidores que utilizamos:
- \\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.
Drive compartilhado da equipe e atendimento
Configuração da VPN
Configurar Meu RH (Gerenciador de serviços da informação IIS)
Ferramenta ApiDog: Utilizada para a definição de contratos do Meu RH. Segue abaixo link:
Obs: As credenciais de acesso devem ser solicitadas ao time.
TOTVS 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
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.
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):
- Auzre AD (SAML):
- Fluig Identity (SAML):
VM's para Testes
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)
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:
Debug DNSpy
Seguir as Orientações DnSpy
Ausências
As ausências relacionadas a férias, compensação de horas, abonos, etc devem ser inseridas na planilha abaixo para controle.
Acessos a serem solicitados
- 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
Ferramentas para instalar
- 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
Sugestão de trilha de capacitação
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:
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas