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 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
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 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 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. 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;
- 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.
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. 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
- 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
Sugestão de trilha de capacitação
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:
 |
| 
