Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

Painel
  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;


Deck of Cards
historyfalse
iddeck principal
Card
labelApp


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.




Card
labelDatasul
Expandir
titleBack-end

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

Expandir
titleFront-end

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/

Expandir
titleDocumentação

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.
Expandir
titleExpedição contínua

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

Expandir
titleBanrisul e Associadas

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.
Card
labelProtheus
Expandir
titleBack-end

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.

Expandir
titleFront-end

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: 

Painel

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:

Expandir
titleDocumentação

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.
Expandir
titleExpedição contínua

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.

Image Modified

Image Modified

Image Modified

Image Modified

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.
Expandir
titleEmergencial

Processo de publicação do pacote emergencial

Card
labelRM
Expandir
titleExpedição contínua

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.

...