Criação de versão do sistema
A geração de versão dentro da cultura de desenvolvimento de software pode ser entendida, em um primeiro momento, como a associação de um nome ou numeração únicos para um distinto estado de um sistema. Assim, versões diferentes de um sistema denotam cópias de um mesmo sistema com algumas diferenças entre elas. Entre os diferentes tipos de geração de versão, existe uma categoria bem difundida e de conhecimento geral que é a utilização de grupos numéricos, por exemplo o grupo 2.3.98. Cada subgrupo numérico representa um certo nível de evolução do software. Assim, estes subgrupos são atualizados de forma crescente e em diferentes períodos. Em geral, o subgrupo mais à direita da composição é incrementado com uma frequência maior que os subgrupos à esquerda. Podemos então concluir que a versão 2.5.3 é, por exemplo, mais atual que a versão 2.1.82 de um dado software. O processo de geração de uma versão na Nginstack consiste em uma série de etapas executadas automaticamente através de uma rotina central e coordenadora de todo este processo. O objetivo deste manual é esclarecer como configurar esta rotina e apresentar todas as ações e eventos disparados por ela.
Existe um grupo de processo a se conhecer que está disponível através do caminho: “Desenvolvimento > Build do Sistema”. Estão disponíveis os processos Agendamentos, Configurações, Servidor e Detalhes da versão do Sistema.
Configuração e agendamento do build do sistema
Para se realizar a configuração e o agendamento de um build, devemos inicialmente determinar qual será o engine responsável por executar este agendamento. Isto deve ser feito através do processo Servidor. Neste processo, o engine selecionado será um dos itens do cadastro Engines. Este cadastro está disponível em: “Admin > Servidores > Servidores”.
Após definido o engine servidor, devemos utilizar o processo Configurações para se parametrizar o build a ser gerado. Neste processo, definimos diversos parâmetros a respeito da geração do build. Por exemplo, devemos configurar o texto caracterizador da versão principal (major version), o estágio de desenvolvimento do build a ser gerado, os destinatários do relatório de geração do build entre outros. Neste mesmo processo, a última grade pode ser utilizada para já se criar um agendamento de execução desta configuração.
Além das opções citadas, podemos configurar também a utilização de um cluster para fazer com que o processamento dos testes seja distribuído pelos engines que o integram. Os testes executarão paralelamente acelerando a sua finalização.
Ainda no processo de Configurações de build pode definir uma base de origem de onde serão atualizados os scripts para base detentora da configuração antes que seja feita a atualização para base de origem. Essa atualização inicial não gera bloqueio na base de origem. Devem ser informados usuário e senha para a base de origem quando configurada. Por padrão a base geradora do build bloqueia atualizações no momento em que o build está sendo gerado, caso o administrador deseje que o bloqueio não seja feito o campo Bloquear durante o build deverá ser desabilitado.
Através do processo Agendamentos, podemos visualizar todas as gerações de builds que estão agendadas. Esta é uma visão geral do agendamento e, através dela, podemos disparar manualmente a execução de um determinado build.
Para obter mais detalhes sobre o build e até manipulá-lo, pode ser utilizado o processo Console. Esse processo está disponível em “Desenvolvimento > Build do sistema > Console”.
Detalhes mais técnicos sobre os testes, como tempo e consumo de memória, podem ser observados através do arquivo de log jsunit.log. Esta classe de log não é padrão do Sistema e precisa ser configurada previamente.
Detalhes da versão atual do Sistema
Para se saber os detalhes que compõem a versão do sistema, devemos utilizar o processo Detalhes da versão do Sistema. Através deste processo, teremos as informações a seguir: versão principal do sistema, último build gerado e estágio de desenvolvimento desta versão.
Configuração das bases geradoras de versão
Deve ser colocado na classe /Dados/Sistema/Tabelas Auxiliares/Detalhes da versão do Sistema
um arquivo *.ijs na vfs com o conteúdo abaixo:
var fld = this.field('iMajorVersion');
fld.userCanChangeNegativeKey = true;
fld = this.field('iBuild');
fld.userCanChangeNegativeKey = true;
fld = this.field('iStage');
fld.userCanChangeNegativeKey = true;