Normas e Procedimentos
Referenciado por: Normas e Procedimentos |
Objetivo
Estabelecer um padrão para o processo de liberação de versões do Totali BI, visando a melhor forma de executá-la, dentro dos prazos estabelecidos e garantindo que todas as etapas atinjam resultados previsíveis e de qualidade assegurada. Além disso, mantendo um padrão para execução dos processos podem-se medir os índices de produtividade e eficiência do processo estipulado. Porém, os padrões não poderão, em hipótese alguma, engessar a criatividade em função da burocracia. Os padrões deverão ser renovados, expandidos e aperfeiçoados ao passar do tempo para que não caiam em desuso ou desatualizados, caso contrário, deteriorarão a ponto de se tornarem inúteis.
Nomenclatura
1 - 9.9
2 - x
3 - r99
Versão
3.3
3.3a
3.3a r01
3.3b
- Número: representado por dois números, separados por um ponto. O primeiro número é alterado quando houver grandes mudanças no sistema.
- Complemento: representado por letras de "a" a "z". A letra de completo deve ser utilizada para separar a versão. Toda e qualquer mudança nos sistemas ou na base de dados gera uma nova versão, alterando o Número ou o Complemento.
- Release: representado pela letra "r" e dois números. A release representa uma sub-versão. Será utilizada somente quando ocorrer algum erro em operações de missão crítica, e a correção não puder esperar a liberação da próxima versão.
Registro no WorkFlow
Todas as alterações executadas em uma determinada versão devem ser registradas no WorkFlow indicando o número da versão que contemplam as mesmas.
Manutenção Simultânea de Versões
Poderá ocorrer manutenção em até 3 versões ao mesmo tempo. Assim se houver manutenção em uma versão, todas as seguintes deverão ser atualizadas. As versões simultâneas são:
Atual
Beta
Implementação
- Atual: a atual versão em produção somente poderá sofrer manutenção no caso descrito para as releases. Caso seja identificado erro em versões anteriores, identificar qual das três ações abaixo é a indicada:
- Se o erro não mais ocorrer na versão atual, indica-se ao cliente que o problema já está corrigido e que ele deve atualizar-se.
- Se o erro ainda ocorrer na versão atual e tratar-se de problema em rotina de missão crítica, deve-se criar uma release corretiva da versão atual e indicar ao cliente que se atualize.
- Se o erro ainda ocorrer na versão atual, porém não se tratar de problema em rotina de missão crítica, corrige-se na próxima release semanal posicionando ao cliente o prazo para liberação da mesma.
- Beta: ao se finalizar o desenvolvimento de uma versão, o desenvolvimento gerará uma versão beta.
- Implementação: versão na qual se implementa as novas solicitações de clientes ou melhorias gerais do sistema.
Considerações: A versão Beta não será liberada para nenhum cliente. Para garantir isto, ela terá controle no próprio executável que permite que seja executada somente no ambiente da Totali.com. Esta garantia será feita identificando-se se o número de série do Protec da Totali.com é encontrado na rede. Depois que a versão beta passar pelo "Roteiro de Liberação de Versão" (descrito abaixo) ela se torna versão atual. Uma vez disponibilizada uma versão beta, o desenvolvimento já estará trabalhando na nova versão (de implementação).
Fluxograma
Roteiro de Liberação da Versão
Cada liberação de versão será conduzida por uma pessoa da qualidade, que é designado pelo gerente da área. Esta pessoa que terá a responsabilidade de ser o 'Liberador' da versão deverá seguir o seguinte roteiro, após ter recebido do desenvolvimento uma nova versão Beta:
- Base de Teste: migrar uma base de teste, validando assim o script de upgrade.
- Revisão: verificar se todas as tarefas desenvolvidas na versão estão revisadas: Caso não estejam, deve ele mesmo revisa-las ou definir quem o fará. O objetivo da revisão é identificar se a funcionalidade de cada tarefa individualmente está de acordo com o esperado.
- Testes Funcionais: executar testes funcionais das atividades desenvolvidas: É função do liberador, testar as tarefas dentro do contexto a que se aplicam (atividade), verificando se interam corretamente, tornando-se funcional.
- Testes Regressão: executar testes de regressão: O liberador deverá identificar possíveis 'efeitos colaterais' das implementações sobre as rotinas de missão crítica. Caso perceba que alguma implementação tem efeito sobre elas, deverá executar testes funcionais sobre as mesmas.
- Erro nos Testes: em caso de erro nos testes, o liberador deverá informar no WorkFlow que determinada tarefa esta revisada com erro, ou até mesmo gerar tarefa nova caso seja um efeito colateral. Em ambos os casos a prioridade da tarefa será máxima (zero).
- Documento de Liberação: gerar documento de liberação de versão: O liberador deverá documentar as alterações nos sistemas, seus efeitos sobre a operação dos mesmos e eventuais pré-requisitos para a instalação.
- Informar ao Desenvolvedor: informar ao desenvolvedor quando os testes estiverem finalizados e a versão estiver aprovada. O desenvolvedor por sua vez, retirará o controle de Beta, transformando a versão em atual, e isolará seus fontes.
- Tabela Resumo: atualizar tabela 'Resumo de liberação de Versões': O liberador deverá atualizar este documento, que está publicado na intranet, acrescentando uma nova linha com as informações: Versão, Data de Liberação, Liberador, Principais Implementações/Correções e link para o documento de liberação de versão.
- FTP: disponibilizar em FTP os executáveis, scripts de migração e documento de liberação da versão.
- Comunicar o Suporte: enviar e-mail para a equipe de suporte e a pessoa responsável no comercial, informando que a versão está disponibilizada no FTP.
- Comunicar aos Clientes: O e-mail comunicando aos clientes da nova versão é enviado pela pessoa responsável no Comercial. Na falta desta pessoa a equipe de Suporte fica responsável em repassar o comunicado.