Controle de Release

O Controle de Release surgiu da necessidade de disponibilizar um ambiente para consulta das atividades homologadas. Essas atividades serão disponibilizadas hierarquicamente por projeto (sistema, Ex: SIPAC) → release → tarefas (Ex: alteração no cadastro de compras). O objetivo é gerenciar o controle na alteração das tarefas para a correção de bug (erro, falha, etc.), para introduzir uma nova funcionalidade ou melhoramento em uma determinada atividade homologada do sistema.

  • Projeto: Sistema (Ex.: SIGAA) no qual um determinado processo foi alterado. Um projeto pode ser composto por mais de uma Release.
  • Release: Versão com alterações significativas no sistema. Composta por um conjunto de builds mais frequentes. Exemplo: Uma release quinzenal pode englobar várias builds (diárias, semanal, etc). A release deve ter um controle de numeração tal como X, Y. O X deverá crescer de acordo com grandes alterações, por exemplo: a adição de um novo módulo (biblioteca) deveria incrementar o X. Aprimoramentos e erros apenas aumentam o Y.
  • Builds: Conjunto de Tarefas homologadas. Representa um deploy no ambiente de produção.
  • Tarefa: A tarefa representa uma solicitação de modificação do desenvolvedor.
  • Usuários Externos: São pessoas que irão interagir com o Sistema Integrado de Gerência de Projetos (iProject). São exemplos de usuários externos: Cooperação Técnica - DPF, Cooperação Técnica - Ministério da Justica - MJ, Cooperação Técnica - DPRF, Cooperação Técnica - Universidade Federal do Maranhão (UFMA), Cooperação Técnica - Universidade Federal da Bahia (UFBA), Cooperação Técnica - Universidade Federal do Recôncavo da Bahia (UFRB), Cooperação Técnica - Universidade Federal de Sergipe (UFS), Cooperação Técnica - Universidade Federal do Ceará (UFC), Cooperação Técnica - Universidade Federal Rural da Amazônia (UFRA) e Cooperação Técnica - Universidade Federal Rural do Semi-Árido (UFERSA).

O controle da release será visualizado obedecendo a seguinte estrutura:

  • Autenticação do usuário com permissão de acesso externo ao Sistema Integrado de Gerência de Projetos (iProject).
  • O usuário externo quando autenticado, terá acesso a visualização do Controle de Release, Abertura de tarefa, Consulta de tarefa, e alteração de senha no Sistema Integrado de Gerência de Projetos (iProject), os demais menus devem está desabilitados.
  • A Release será composta da seguinte forma:
    • Releases
      • SIPAC (Sistema Integrado de Patrimônio e Administração de Contratos).
      • SIGAA (Sistema Integrado de Gestão Acadêmica).
      • SIGED (Sistema Integrado de Gestão de Documentos).
      • SIGPRH (Sistema Integrado de Gestão, Planejamento e Recursos Humanos).
      • SIGAdmin (Sistema Integrado de Gestão Administrativa dos sistemas).
  • No lado direito da denominação de cada sistema deve ser exibida a Última Alteração (deverá ser um link para baixar o patch, a SQL e o LOG de alteração) da Release e um link para visualizar (#Visualizar Detalhes#) todas as Releases do sistema. Ao clicar no link (#Visualizar Detalhes#), todas as Releases do sistema selecionado (Ex.: SIPAC) serão exibidas e as visualizações devem obedecer o formato composto por: Número da versão, data e link (#Ver Tarefas da Release#) para detalhar a Release.
    • Exemplo: Release 1.00 - 09/10/2009 - #Ver Tarefas da Release# -
  • Ao clicar no link (#Ver Tarefas da Release#) será exibido o seguinte formato de formulário com as tarefas:
    • Após a seleção do sistema devem ser exibidos os links para baixar o PATCH, a SQL e o LOG de alteração de Tarefa do módulo selecionado.
    • As tarefas são descritas conforme o modelo abaixo:
      • Descrição Tarefa 01 - Data da Alteração da tarefa (Formato: 00/00/0000).
        • Alteração de Log da tarefa.
        • PATCH.
        • SQL.
      • Descrição Tarefa 02 - Data da Alteração da tarefa (Formato: 00/00/0000).
        • Alteração de Log da tarefa.
        • PATCH.
        • SQL.
  • O cabeçalho das tarefas são compostos pelos itens: Título da tarefa, alteração de log por tarefa, breve descrição da tarefa, sub-sistema, data de início e fim da tarefa.
  • Exemplificando a estrutura:
  • SIPAC (Sistema Integrado de Patrimônio e Administração de Contratos) - Data da última alteração (formato: 00/00/0000) - #Visualizar Detalhes#
    • Release 1.00 - 09/10/2009 - #Ver Tarefas da Release# -
    • Release 2.00 - 09/10/2009 - #Ver Tarefas da Release# - (clicando nos detalhes desta Release será exibido o conteúdo abaixo)
      • Links para baixar o PATCH, a SQL e o LOG de alteração de Tarefa do módulo selecionado.
      • Tarefa 01 - Data da Alteração da tarefa (Formato: 00/00/0000).
        • Alteração de Log da tarefa.
        • PATCH.
        • SQL.
      • Tarefa 02 - Data da Alteração da tarefa (Formato: 00/00/0000).
        • Alteração de Log da tarefa.
        • PATCH.
        • SQL.
    • Release 3.00 - 09/10/2009 - #Ver Tarefas da Release# -
  • Quando as builds de uma release estiverem encerradas, a realease poderá ser reaberta.
  • Quando uma build estiver encerrada, ela poderá ser reaberta para possíveis manipulações no log SQL.
  • Uma build que está associada a uma sistema e contiver vínculos, não poderá ser desvinculada do sistema original.
  • Só será possível cadastrar uma nova Release se não existir alguma aberta para o sistema.
  • Uma Release deve ser aberta com Data de Início e uma Descrição.
  • Uma build aberta que está associada, poderá ser desvinculada da Release. Neste caso, poderá ser aberta uma Release e associar a mesma ou deixá-la sem associação.
  • Quando uma determinada Build for fechada será possível associar ou não a uma Release posteriormente.
  • Uma build pode ser associada a uma Release que está aberta e vinculada a um sistema.
  • É possível encerrar a release mesmo se existir alguma build que esteja aberta.
  • Quando uma Release for encerrada, deve ser informado qual o link da tag do SVN e data de encerramento.
  • Os cadastros de release, build, fechamento de release só serão realizados por usuário com permissão de gerente.
  • Uma equipe (Ex.: COOPERAÇÃO TÉCNICA - UFS) deve está associada a um sub-sistema (Exemplo: SIPAC - Compras).
  • Em caso de possuir alterações de Banco de Dados, será gerado um ou mais arquivos SQL (para cada Banco de Dados) e um arquivo PATCH a uma determinada tarefa homologada da Release.
  • Para cada Release poderão ser gerados arquivos SQL (baseado na solicitação de update em banco de dados) para cada Banco de Dados e um arquivo PATCH respectivo.

Diagrama de Atividades - Controle de Release

< Cite as classes e as tabelas envolvidas diretamente no processo de negócio para que testes possa usá-la. >

Classe Tabela

Plano de Teste

Sistema: <Nome do sistema> ex.: SIGPRH

Módulo: <Nome do módulo> ex.: DAP

Link(s): <Menus utilizados para alcançar a funcionalidade> ex.: Menu Servidor → Chefia → Cursos e Concursos

Usuário: <Usuário que realmente irá realizar a operação e não usuários genéricos como gleydson ou raphaela. O usuário não é obrigatório.

        Exemplos: 
           gizelealmeida (projetos de cursos e concursos), 
           simonelopes (capacitação)>

Papel que usuário deve ter: <Denominação dos papéis. Preenchimento obrigatório. Ex.: SigrhPapeis.GESTOR_PROJETO_CURSOS_CONCURSOS >

<É a definição de um conjunto específico de entradas de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um Item a ser testado.>

< Descreve como obter os dados que serão usados para o teste do caso de uso.>

Arquivos

  • desenvolvimento/especificacoes/iproject/casos_de_uso/controle_release.txt
  • Última modificação: 2017/04/03 18:10
  • (edição externa)