Versões Totali Commerce, Funcionalidades

Referenciado por: Normas e Procedimentos | Processo de Testes de Releases |

Apresentação

Estabelecer um padrão para o processo de liberação de versões do Totali Commerce e Totali CheckOut, 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.9x r99

2 - 9.9x r99

3 - 9.9x r99

1. Número: Representado por dois números, separados por um ponto. O primeiro número é alterado quando houver grandes mudanças no sistema.

2. Complemento: Representado por letras de "a" a "z". A letra de complemento deve ser utilizada para separar a versão. Toda e qualquer mudança no sistema ou na base de dados gera uma nova versão, alterando o Número ou o Complemento.

3. Release: Representado pela letra "r" e dois números. A release representa uma subversão. Será utilizada sempre que houver alguma correção no sistema.

Código de Estrutura

A estrutura do banco de dados tem um código sequencial. Cada nova versão incrementa obrigatoriamente o código de estrutura, a qual esta versão está vinculada.

Cada nova versão do sistema gerará obrigatoriamente um novo código de estrutura, mesmo que nenhuma alteração no banco de dados seja necessária.

Como releases somente existirão no caso de erro em rotinas de missão crítica nos sistemas, conseqüentemente todas as releases de uma versão utilizam à mesma estrutura de banco.

Veja a tabela de versões de sistema e estrutura: Versões Commerce

Registro de 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. As alterações em banco de dados devem ser registradas indicando o número da versão e não o código de estrutura.

Manutenção Simultânea de Versões

Poderá ocorrer manutenção em até 4 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

• Fixa

• Beta

• Implementação

1. 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:
   1. 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.
   2. 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 atualize.
   3. 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.
2. Fixa: Esta versão terá releases corretivas por um período longo de tempo. Assim os clientes que estejam utilizando ela poderão receber correções sem necessitar atualização de versão.
3. Beta: Ao se finalizar o desenvolvimento de uma versão, o desenvolvimento gerará uma versão beta.
   Esta versão 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).
4. Implementação: Versão na qual se implementa as novas solicitações de clientes ou melhorias gerais do sistema.

A liberação semanal ocorre todas as segundas-feiras e possui uma carência de 5 dias úteis para entrada de tarefas no pacote que está sendo desenvolvido. Ou seja, as tarefas lançadas na quinta ou na sexta entram apenas na segunda-feira seguinte no pacote para desenvolvimento. Cabe ao gerente de produto avaliar em qual versão uma determinada tarefa fará parte, levando em consideração a severidade indicada.

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:

1. Base de Teste: Migrar uma base de teste, validando assim o script de upgrade.

2. Revisão: Verificar se todas as tarefas desenvolvidas na versão estão revisadas. Caso não estejam, deve ele mesmo revisá-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.

3. Testes Funcionais: Executar testes funcionais atividades desenvolvidas: É função do liberador, testar as tarefas dentro do contexto a que se aplicam (atividades), verificando se interam corretamente, tornando-se funcional.

4. 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.

5. 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).

6. 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.

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

8. 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.

9. FTP: Disponibilizar em FTP os executáveis, scripts de migração e documento de liberação da versão.

10. Comunicar o Suporte: Enviar e-mail para a equipe de suporte e para a pessoa responsável no comercial, informando que a versão está disponibilizada no FTP.

11. 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.