Meu RH

Atalhos

Árvore de páginas



  1. Não devemos encaminhar pacotes internos para os clientes;
  2. Sempre deve ser utilizada a central de downloads;
  3. Não devemos encaminhar pacotes por email, sempre deve haver um ticket e issue para manter o registro para todos;



    Expedição APP

    Ocorre conforme a demanda, analisar demanda em refinamento, sempre comunicando pelo Discord, nas daily´s gerais de quinta e outras reuniões em comum das três squads.


    Formas de Expedição 

    Issue de implementação complexa 

    Teste Fechado e TestFlight* : 4 dias uteis.
    Teste Aberto** : 4 dias uteis.

    Faixa de Produção : 

    • Android : 20%,40%,60%,80%,100% aumento gradativo diário
    •  IOS : Ao atingir a faixa de 50% do android


    Issue de implementação simples  

    Teste Fechado e TestFlight* : 2 dias uteis.
    Teste Aberto** : 4 dias uteis.


    Faixa de Produção :

    • Android : 25%,50%,75%,100% aumento gradativo diário.
    •  IOS : Ao atingir a faixa de 50% do android.


    Observações:

    * Teste fechado e TestFlight

    Versão publicada para um grupo fechado de testers (apenas MeuRH).

    ** Teste aberto

    Versão publicada para um grupo maior de testers (Grupo Totvs) e todos usuários inscritos no beta, inclusive os de clientes.




    01. FAZER CHECKIN NO TFS

    Normalmente no caminho $/HCM/Fontes_Doc/Sustentacao/V11/V11/progress/src/rh/meurh/api/v1/ e $/HCM/Fontes_Doc/Sustentacao/V11/V11/progress/src/rh/mfp

    02. GERAR DOCUMENTO TÉCNICO CORRETAMENTE

    Documentação Protheus - Estrutura e Templates do TDN 

    03. PACOTE PARA TESTE

    1. Compilar fontes da V11. (no caso de emergencial, não seria melhor testarmos o pacote que será enviado ao cliente?)

    04. CHECKIN NA TS PARA CONSOLE

    Antes de concluir a issue deve ser feito o checkin em todas as TS que será expedida.

    05. PACOTES EMERGENCIAS

    Publicação dos pacotes GCAD Tools

    01. ATUALIZAR MASTER

    Criar um branch master e dar o comando "git pull origin master"

    02. GERAR BUILD DE PRODUÇÃO

    Após atualizar a branch gerar a build com o comando "ng build --prod"

    03. GERAÇÃO DO WAR

    Adicionar a dist dentro do war da respectiva versão.

    04. CONFERIR DEPENDÊNCIAS

    1. Conferir depedências do frame no diretório.
    2. Para JBOSS validar arquivos do diretório WEB-INF/classes/com/totvs/hcm/html/rest.
    3. Analisar as bibliotecas para cade versão.

    05. TESTE DE ACESSOS AOS MENUS

    Como a expedição dos artefatos é para todos os clientes, sempre que gerarmos um build para publicar é importante que seja feito um teste rápido navegando pelos menus do Meu RH, principalmente nas funcionalidade que foram criadas e/ou alteradas.

    06. CHECKIN NA TS PARA CONSOLE

    É necessário fazer o checkin para todas as releases no TFS.

    JBOSS Meu RH: $/Patches_Datasul/{release}/{patch}/Squad MeuRH/deploy/datasul-byyou-12.1.32-SNAPSHOT.ear/html-hcm-12.1.32-SNAPSHOT.war

    JBOSS Telas de Aprovações: $/Patches_Datasul/{release}/{patch}/Squad MeuRH/deploy/datasul-byyou-12.1.32-SNAPSHOT.ear/totvs-hcm.war

    TOMCAT Meu RH: $/Patches_Datasul/{release}/{patch}/Squad MeuRH/webapps/html-hcm.war

    TOMCAT Telas de Aprovações: $/Patches_Datasul/{release}/{patch}/Squad MeuRH/webapps/totvs-hcm.war

    06. ESTEIRA DO JENKINS PARA RELEASE

    http://prado.jv01.local:8080/view/HCM/job/11.5.X-HTML-HCM/

    http://prado.jv01.local:8080/view/NFRW_HTML/job/11.5.X-HTML-HCM-NFRW/

    http://prado.jv01.local:8080/view/THF2/job/11.5.X-THF2-totvs-HCM/

    01. MANUAL

    Documentação Protheus - Estrutura e Templates do TDN 

    02. DOCUMENTO TÉCNICO AUTOMÁTICO

    A geração automática do DT está disponível na transição da etapa de Documentação para Em Teste Integrado (com doc.), para o fluxo Simplificado e também Tradicional.

    Preencher o formulário:

    Space TDN: NPR - Meu RH
    Página Pai TDN (Agrupadora): Manutenção 12.1.33
    Produto - Nova Nomenclatura: Meu RH
    Linha de Produto - Nova Nomenclatura: Linha Datasul
    Label TDN: Label/Rótulo para inclusão na criação do Documento Técnico no TDN. Obs.: Informação obrigatória de acordo com estrutura do Produto. Esta informação também definirá rotas no Workflow.
    Todos os países: Todos os países
    Summary: Problema X na rotina Y
    Situação/Requisito: Ao acessar Y ocorre problema X
    Solução TDN: Foi incluída uma validação no campo Z dentro da rotina Y que impede o preenchimento incorreto que ocasionava o erro X.
    Demais informações TDN: Será liberado oficialmente na console do dia XX/XX/XXXX para as versões: 12.1.XX.X, 12.1.XX.X e 12.1.XX.X de acordo com Calendário de Expedição Contínua DATASUL

    02. CHECKIN NA TS PARA CONSOLE

    Assuntos Relacionados TDN: (Quando tiver outras páginas do TDN sobre o assunto)

    03. DOCUMENTAÇÃO DE REFERÊNCIA

    1. Nosso espaço no TDN: Documento de Referência
    2. Para alterações no modo de funcionamento das rotinas devem ser ajustadas as documentações.
    3. Para as novas funcionalidades deve ser gerado uma nova documentação.

    01. CALENDÁRIO

    Calendário de Expedição Contínua DATASUL

    02. CHECKIN NA TS PARA CONSOLE

    Back-end:

    Conferir se foram realizados todos os checkins.

    Front-end:

    JBOSS Meu RH: $/Patches_Datasul/{release}/{patch}/Squad MeuRH/deploy/datasul-byyou-12.1.32-SNAPSHOT.ear/html-hcm-12.1.32-SNAPSHOT.war

    JBOSS Telas de Aprovações: $/Patches_Datasul/{release}/{patch}/Squad MeuRH/deploy/datasul-byyou-12.1.32-SNAPSHOT.ear/totvs-hcm.war

    TOMCAT Meu RH: $/Patches_Datasul/{release}/{patch}/Squad MeuRH/webapps/html-hcm.war

    TOMCAT Telas de Aprovações: $/Patches_Datasul/{release}/{patch}/Squad MeuRH/webapps/totvs-hcm.war

    03. CHECKLIST DA CONSOLE

    Testes da console 2021

    01. BANRISUL

    O time de produto não fazem expedições para Banrisul.

    02. ISSUES ASSOCIADAS

    1. Quando houver issue associada é importante que seja colocada a data de entrega correta (emergencial ou console)
    2. Deve ser gerado o pacote na versão, banco e servidor de cada cliente, no caso de emergencial e notificar via issue/ticket.

    01. FAZER CHECKIN NO TFS

    Normalmente no caminho $/Protheus_Padrao/Fontes_Doc/Master/Fontes/Web Services/WebServices/RH/

    02. GERAR DOCUMENTO TÉCNICO CORRETAMENTE

    Documentação Protheus - Estrutura e Templates do TDN 

    03. PACOTE PARA TESTE

    1. Para gerar o pacote para testar é necessário ajustar o campo Status Pacote com Gerar.
    2. O pacote da issue deve ser baixado para testar, caso o download não seja realizado o robo entende que não houve teste e pode haver problemas na expedição.

    04. CALENDÁRIO DE EXPEDIÇÃO

    Todas as issues concluídas até segunda-feira são expedidas no pacote toda sexta-feira. Então as issues concluídas terça-feira, quarta-feira, quinta-feira, sexta-feira e segunda-feira serão expedidas na próxima sexta-feira.

    05. PACOTES EMERGENCIAS

    Adicionar label "expedicao_tradicional" na issue.

    01. ATUALIZAR MASTER

    Criar um branch master e dar o comando "git pull origin master"

    02. GERAR BUILD DE PRODUÇÃO

    Após atualizar a branch gerar a build com o comando "ng build --prod"

    03. TESTE DE ACESSOS AOS MENUS

    Como a expedição dos artefatos é para todos os clientes, sempre que gerarmos um build para publicar é importante que seja feito um teste rápido navegando pelos menus do Meu RH, principalmente nas funcionalidade que foram criadas e/ou alteradas.

    04. SUBSTITUIR PROPERTIES.JSON

    No diretório Portais\PortalMeuRH que é gerado a dist, antes de publicar substitua o properties.json do diretório pelo properties.json padrão do Protheus.

    05. SUBIR NO GOOGLE DRIVE

    Renomeie o diretório para PortalMeuRH, faça um pasta compactada, renomeie a pasta para AA-MM-DD-ARQUIVOS_PORTAL_MEURH

    Subir no Google Drive e permitir acesso para todos da totvs: https://drive.google.com/file/d/1v2Ivbkd7NkSAPvsIX9W5koiG_eARpWUB/view?usp=sharing

    06. ABRIR TICKET GCAD

    Enviar e-mail para [email protected] com as informações: 

    Boa tarde!

    Poderiam atualizar a publicação: https://suporte.totvs.com/portal/p/10098/download?e=696055 

    Substituir pelo arquivo: colocar link do drive gerado anteriormente

    Motivo: RHMOBILE01-10260 (colocar código da issue ou motivo de estar solicitando a atualização)

    Atenciosamente.

    Assim será aberto um ticket para o GCAD atualizar os arquivos do Meu RH na central de downloads.

    07. ALTERAR DOCUMENTO TÉCNICO NO TDN

    Após o GCAD atualizar a publicação, devemos ajustar documento técnico explicando para o cliente que a atualização foi realizada no front-end, por exemplo:

    Foi efetuado o ajuste no front-end da aplicação, atualize seus arquivos:

    01. MANUAL

    Documentação Protheus - Estrutura e Templates do TDN

    02. DOCUMENTO TÉCNICO AUTOMÁTICO

    A geração automática do DT está disponível na transição da etapa de Documentação para Em Teste Integrado (com doc.), para o fluxo Simplificado e também Tradicional.

    Preencher o formulário:

    Space TDN: NPR - Meu RH
    Página Pai TDN (Agrupadora): Manutenção 12.1.33
    Produto - Nova Nomenclatura: Meu RH
    Linha de Produto - Nova Nomenclatura: Linha Protheus
    Label TDN: Label/Rótulo para inclusão na criação do Documento Técnico no TDN. Obs.: Informação obrigatória de acordo com estrutura do Produto. Esta informação também definirá rotas no Workflow.
    Todos os países: Todos os países
    Summary: Problema X na rotina Y
    Situação/Requisito: Ao acessar Y ocorre problema X
    Solução TDN: Foi incluída uma validação no campo Z dentro da rotina Y que impede o preenchimento incorreto que ocasionava o erro X.
    Demais informações TDN: (Quando precisar atualizar o front-end)

    Assuntos Relacionados TDN: (Quando tiver outras páginas do TDN sobre o assunto)

    03. DOCUMENTAÇÃO DE REFERÊNCIA

    1. Nosso espaço no TDN: Documento de Referência
    2. Para alterações no modo de funcionamento das rotinas devem ser ajustadas as documentações.
    3. Para as novas funcionalidades deve ser gerado uma nova documentação.
    4. Sempre descrever as particularidades, colocar parâmetros e relacionar documentações da linha de produto.

    01. MANUAL

    Expedição Contínua Protheus - Documentação Interna

    02. OBSERVAÇÕES

    1. Todas as issues concluídas até segunda-feira são expedidas no pacote toda sexta-feira.
    2. O front-end não é enviado no mesmo pacote.
    3. Os dicionários já devem ser testados na etapa de codificação, ou seja, as aprovações do ATUSX de DBA e de Sistemas já devem estar ok antes da conclusão da codificação.
    4. Quando houver alteração de dicionário precisamos rodar o UPDDISTR para testar e acrescentar na documentação correspondente.
    5. Quando pede incorporação de pacote precisa colocar o documento técnico do TDN da alteração no TDN de liberações do GCAD para não gerar problema na expedição


    O Calendário de expedição contínua do RH Protheus se inicia sempre em uma terça-feira e termina na segunda feira seguinte, a publicação dos pacotes de dicionário e de fontes ocorre às sextas-feiras e a conclusão das issues é feita nas segundas-feiras.
    Após a conclusão do teste integrado as issues vão para a coluna done da board, mas não são concluídas neste momento, ficam com o status 'teste integrado concluído'.
    As issues com o teste integrado concluído e que estão aguardando a publicação da expedição contínua, ficam com o status do pacote 'Aguardando-Expedição-Release' elas só serão concluídas na segunda-feira após a publicação da expedição contínua, conforme imagem do calendário, após a conclusão o status ficará 'Publicado'
    		 Para casos excepcionais é possível concluir a issue e expedir o pacote assim que o teste integrado for finalizado, desde que antes de concluir o TI a label expedicao_tradicional seja adicionada na issue.

    A conclusão das issues na segunda-feira após a publicação da expedição é feita de forma automática pelo GCAD. Neste momento, o lock dos fontes da issue são liberados no TFS, ficando disponíveis para novas alterações.
    		Neste caso ao concluir o Teste Integrado a issue será concluída e o patch será enviado ao cliente.

    01. CHECKIN FRONT E BACK

    Devem ser feitos checkin nas 3 versão de mercado normalmente no caminho $/RM/Legado/12.1.XX/FrameHTML/web_src/app/RH/PortalMeuRH e checkin na Atual $/RM/Atual/Release/FrameHTML/web_src/app/RH/PortalMeuRH

    02. PR AZURE

    Quando houver alterações de front-end deve ser feito PR para o azure.

    03. CALENDÁRIO

    São expedidos os pacotes toda quarta e sexta-feira todos os checkins feitos até 11:00 que não quebraram a build.

    Status da issue deve ser Teste Integrado concluído até as 16:00 do dia da expedição.

    04. CAMPO RELEASE PARA NOTIFICAÇÃO

    O campo Release para Notificação deve estar preenchido com a versão do cliente antes de fazer o checkin.

    05. FIX VERSION

    O campo fix version deve estar preenchido com a versão atual (release que será expedido no próximo ciclo).

    06. ASSOCIAÇÕES

    Só devem ser feitas associações de issues para mesmo release, o robo só expede uma versão de release por issue pai.

    07. PACOTES EMERGENCIAIS

    Quando necessário deve ser comunicado no chat e solicitada via portal da engenharia: http://10.31.0.83/DashboardExpedicao/

    08. DOCUMENTAÇÃO DE REFERÊNCIA

    1. Nosso espaço no TDN: Documento de Referência
    2. Para alterações no modo de funcionamento das rotinas devem ser ajustadas as documentações.
    3. Para as novas funcionalidades deve ser gerado uma nova documentação.
    4. Sempre descrever as particularidades, colocar parâmetros e relacionar documentações da linha de produto.