Mudanças entre as edições de "Liberação da Versão"
Ir para navegação
Ir para pesquisar
| Linha 16: | Linha 16: | ||
3. Concluídas todas as fases de testes, subir com a versão: | 3. Concluídas todas as fases de testes, subir com a versão: | ||
a. | a. Dias oficiais para liberação de versão Release Candidate: Segunda-Feira, Terça-Feira ou Quarta-Feira. (Situações excepcionais devem ser alinhadas com desenvolvimento/teste/suporte) | ||
b. | b. Fazer a cópia da versão atual na pasta \\serverdb\Documentacao Teste\Cópia de Versão. | ||
c. | c. No Atendimento modificar o Status da versão para Release Candidate. | ||
d. | d. Gerar Scripts e Realizados e colar na pasta da Pré Versão. (Utilizar a VM 192.168.254.159) | ||
e. | e. Deletar as subpastas (exec, bpls, dados, instalação) da pasta suporte (MC/Comercial). | ||
f. | f. Colar os arquivos da Pré Versão na pasta Suporte. | ||
g. | g. No Atendimento, executar a função para subir com a versão para a nuvem. (Utilizar a VM 192.168.254.159) | ||
h. | h. Gerar o link dos realizados, inserindo vídeos demonstrativos da alteração. (Através da VM 192.168.254.159) | ||
i. | i. Publicar o Post de divulgação da versão como Notícias. (Não configurar para ser Feeds ainda) | ||
j. Comunicar a equipe via email que a versão está com liberada com atualização restrita. | j. Comunicar a equipe via email que a versão está com liberada com atualização restrita. | ||
k. | k. Enviar notificação aos clientes dos serviços liberados. | ||
4. Liberar Oficialmente (7 a 15 dias após liberar como RC): | 4. Liberar Oficialmente (7 a 15 dias após liberar como RC): | ||
Edição das 11h29min de 19 de agosto de 2024
Protocolos para fechar a versão a partir da separação do fonte
1. Enviar email aos desenvolvedores solicitando:
a. Testes de Rotina necessários. b. Tempo para apresentação dos realizados.
2. Elaborar Programação dos Realizados e fazer a comunicação:
a. Ao desenvolvedor responsável (solicitando aval). b. Ao Douglas, para criar os eventos. c. Ao Diogo, para elaborar a escala do suporte. d. Ao Flávio, para gerar o link do evento. e. Após tudo esquematizado, comunicar no Geral.
3. Concluídas todas as fases de testes, subir com a versão:
a. Dias oficiais para liberação de versão Release Candidate: Segunda-Feira, Terça-Feira ou Quarta-Feira. (Situações excepcionais devem ser alinhadas com desenvolvimento/teste/suporte) b. Fazer a cópia da versão atual na pasta \\serverdb\Documentacao Teste\Cópia de Versão. c. No Atendimento modificar o Status da versão para Release Candidate. d. Gerar Scripts e Realizados e colar na pasta da Pré Versão. (Utilizar a VM 192.168.254.159) e. Deletar as subpastas (exec, bpls, dados, instalação) da pasta suporte (MC/Comercial). f. Colar os arquivos da Pré Versão na pasta Suporte. g. No Atendimento, executar a função para subir com a versão para a nuvem. (Utilizar a VM 192.168.254.159) h. Gerar o link dos realizados, inserindo vídeos demonstrativos da alteração. (Através da VM 192.168.254.159) i. Publicar o Post de divulgação da versão como Notícias. (Não configurar para ser Feeds ainda) j. Comunicar a equipe via email que a versão está com liberada com atualização restrita. k. Enviar notificação aos clientes dos serviços liberados.
4. Liberar Oficialmente (7 a 15 dias após liberar como RC):
a. Mudar o Status da Versão no programa de atendimento para Final. b. Sincronizar o cabeçalho: Executar a função Apenas atualizar cabeçalhos da versão. c. Modificar a publicação da Post de divulgação da versão para Feeds do sistema. d. Comunicar no geral (via e-mail). e. Ajuste na TekStore para Divulgar a Versão (Marlon).
6. Atualização do Help: A princípio esta etapa vai ocorrer de acordo com a disponibilidade de tempo do setor.