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 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: Integração contínua 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 o TFS. 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é 11h do dia da expedição já saem na versão (esse horário pode variar de acordo com solicitações dos times). 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 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. Issues com status ‘Teste integrado concluído’ até as 16: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 com Protactor Automação de Contrato (Postman) Projeto de Testes de Contrato Dashboard Automação 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. Gated Checkin Portal da Engenharia: É possível verificar a data de expedição dos Patchs e Releases: Engenharia BH: http://engenhariabh/DashboardExpedicao OBS: Patchs de mercado são expedidos toda quarta e sexta, para Patchs expirados ou que precisem ser expedidos com urgência deve ser solicitado uma versão emergencial. Checkins realizados até 11h 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 integrado concluído’ até as 16: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. Segue link onde é efetuada a reserva. Com a VPN conectada: http://engenharia.bh01.local/alura/#/
Com a VPN desconectada: https://engenhariabh.totvs.com.br/alura/#/login 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 Issues para apontamentos de reuniões, apoio, etc. Diversos: https://jiraproducao.totvs.com.br/browse/DRHMEURH-567 Eventos ágeis: https://jiraproducao.totvs.com.br/browse/DRHMEURH-590 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. Portal do Cliente 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
Drive Meu RH Configuração da VPN Configuração VPN Configurar Meu RH (Gerenciador de serviços da informação IIS) Configurar Meu RH Ferramenta Apicurio: Utilizada para a definição de contratos do Meu RH. Apicurio 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
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 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: Ferramentas para instalar - Visual Studio: 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
Sugestão de trilha de capacitação LIBRepositório RH com vídeos de treinamentos: DiversosJira | 
