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
Conferir depedências do frame no diretório.
Para JBOSS validar arquivos do diretório WEB-INF/classes/com/totvs/hcm/html/rest.
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.
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)
Para gerar o pacote para testar é necessário ajustar o campo Status Pacote com Gerar.
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
title
Front-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
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:
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)
Todas as issues concluídas até segunda-feira são expedidas no pacote toda sexta-feira.
O front-end não é enviado no mesmo pacote.
Quando houver alteração de dicionário precisamos rodar o UPDDISTR para testar e acrescentar na documentação correspondente.
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.
Detalhamento do fluxo e necessidade do usuário (issuetype Story), esperada pelo PO e time de UX (documentação);
Critérios de aceite devidamente descritos e apresentados;
Quando a entrega for fatiada deixar somente os critérios de aceite que devem ser entregues naquela issue;
Especificar em quais linhas de produto deve ser feito desenvolvimento e teste;
Descrever quando novo menu deve aparecer na parte de Mais Acessados;
Adicionar o Link Issues quando uma issue for dependente de outra;
Preservar funcionalidades existentes nos portais legados de acordo com cada story, que fazem sentido pro Meu RH;
Definição de contrato sempre que houver atuação de front-end, fazendo checkin com as atualizações;
DoD - Definition of Done - Definição de Feito
Code review antes de iniciar o teste integrado;
Teste unitário automatizado nos projetos do angular e ionic;
Documentação feita na etapa de codificação (documento técnico e documentação de referência);
Comentário ou evidência do que foi corrigido de forma detalhada dentro da subtarefa de codificação;
Subir commit ou pull request com arquivos de tradução (PT, EN, ES) do projeto angular e ionic;
Cumprir critérios de aceite;
Quando houver alteração de layout deve haver validação de UX/UI (com subtarefa de Design)
Última revisão em
Expandir
title
Protheus
Protheus
DoR - Definition of Ready - Definição de Preparado
Detalhamento da jornada do usuário, esperada pelo PO e time de UX;
Critérios de aceite devidamente descritos e apresentados, e que não apresentem riscos;
Story com 8 pontos ou menos;
Fatiamento de story com a relação mencionada (ou seja, as relações de dependência);
Especificar em quais linhas de produto deve ser feito desenvolvimento e teste (no refinamento técnico deixar descrito para apoiar PO);
Quando for nova funcionalidade especificar em qual Versão/Release ela será disponibilizada;
Preservar funcionalidades existentes nos portais legados de acordo com cada story, que fazem sentido pro Meu RH;
Na planning levar em consideração as observações levantadas no refinamento técnico e passar o que for necessário para os critérios de aceite;
Descrever como devem ser os Permissionamentos e se deve considerar no Mais acessados;
UX prototipar pensando em como funciona nas 3 linhas (tamanho e tipo do campo).
Nos refinamentos incluir os fontes que serão alterados nos comentários.
DoD - Definition of Done - Definição de Feito
Definição de contrato sempre que houver atuação de front-end, sempre fazendo checkin com as atualizações;
Code review;
Teste unitário automatizado nos projetos do angular e ionic;
Teste automatizado unitário e/ou de API (desde de que seja possível automatizar);
Documentação (evidência de teste de desenvolvimento, documento técnico e documentação de referência);
Tradução feita pelo dev (no projeto angular e ionic);
Cumprir critérios de aceite;
Quando houver alteração de layout deve haver validação de UX/UI (com subtarefa de Design e Components), sendo os components (Front, Back e UX);
Quando criar novos cenários automatizados de backend, atualizar o kanoah* e o mapa mental;
Tarefas que envolvem front-end devem ser testadas em todas as linhas:
Quando o teste for rápido (em média 1h) criar uma subtarefa de teste para cada linha;
Quando for um teste mais extenso devem ser criadas novas issues e repassadas ao PO para priorizar;
Considerar Permissionamento e fieldProperties de acordo com a necessidade de cada linha.
*entender como isso funciona na estrutura do Protheus - Kaio (deve ser usado em todos os casos? tem sentido não usar BDD, tem planejamento para automatizar rodar o advpr a partir do ciclo de teste)
Última revisão em
Expandir
title
RM
RM
DoR - Definition of Ready - Definição de Pronto
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;
Especificar em quais linhas de produto deve ser feito desenvolvimento e teste;
Descrever quando novo menu deve aparecer na parte de Mais Acessados;
Adicionar o Link Issues quando uma issue for dependente de outra;
Ter documentação de UX;
Preservar funcionalidades existentes nos portais legados de acordo com cada story, que fazem sentido pro Meu RH;
Quando tiver integração ter disponibilidade de ambiente, usuário e senha que devem ser utilizados
DoD - Definition of Done - Definição de Feito
Definição de contrato sempre que houver atuação de front-end, sempre fazendo checkin com as atualizações;
Code review antes de iniciar o teste integrado;
Teste unitário automatizado nos projetos do angular e ionic;
Documentação de referência para inovações (quando houver issues fatiadas, será feita ao final do Epic);
Comentário ou evidência do que foi corrigido de forma detalhada dentro da issue;
Subir commit ou pull request com arquivos de tradução (PT, EN, ES) do projeto angular e ionic;
Sempre garantir cobertura mínima dos testes unitários, Branches: 74% | Functions: 85% | Lines: 88%
Cumprir critérios de aceite;
Quando houver alteração de layout deve haver validação de UX/UI (com subtarefa de Design);
No gromming, as tarefas que envolvem front-end, devem ser avaliadas para verificar a necessidade de serem testadas em todas as linhas:
Quando o teste for rápido (em média 1h) criar uma subtarefa de teste para cada linha;
Quando for um teste mais extenso devem ser criadas novas issues e repassadas ao PO para priorizar.
Considerar Permissionamento e fieldProperties de acordo com a necessidade de cada linha.
Check-in no back-end deve ser realizado sempre na versão atual e após os testes integrados realizar o merge para as versões de mercado.
Última revisão em
Card
label
Review
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
Card
label
Daily
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;
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:
Card
label
PR
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
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
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:
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;
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
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
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.
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.
