Deve-se gerar o build do projeto para que se possa realizar o seu deploy no ambiente desejado (Desenvolvimento, Homologação, ou Produção). Se possível, ao gerar esse build, deve-se também executar os testes de unidade e funcionais.

Caso o build tenha sido executado com sucesso e deseja-se colocá-lo em Produção, é necessário verificar se o software está com a qualidade suficiente para ser liberado para o ambiente de produção. Para realizar tal análise, é verificado:
• Se o Registro de Teste não contém nenhum problema impeditivo para a entrada em produção;
• Caso o projeto tenha definido métricas de código, deve-se analisar se elas estão com a qualidade mínima para liberar o software para produção.

Em seguida deve-se criar uma TAG no repositório do projeto indicando que aqueles códigos-fonte geram a versão do projeto. Por exemplo, em JAVA, com o MAVEN, tem-se utilizado o padrão X.X.X (ex.: 1.0.6) para as versões que entram em produção, e X.X.X-SNAPSHOT (ex.: 1.0.6-SNAPSHOT) para indicar uma versão que ainda está em desenvolvimento.

Após a geração do build, deve ser preparada um script de atualização das definições de banco de dados (DDL) sincronizada com as alterações do build.

Para a execução de scripts no ambiente de Desenvolvimento, a própria Equipe do Pojeto tem acesso a base de dados para execução dos mesmos.

Já nos ambientes de Homologação e Produção, os scripts devem ser enviados via ferramenta SCMBD (https://scmbd.trt9.jus.br/) por onde passará por validações do Administrador de Dados do projeto e o DBA responsável. Após validação desses scripts, estes serão executados nos ambientes correspondentes.

Para mais informações sobre as validações de scripts feitas na ferramenta SCMBD, acessar o repositório SVN https://svnserver.trt9.jus.br/trt9/scmbd/Trunk/.

Caso necessário, se o build exigir novos dados de domínio, deve-se preparar um script (DML) para popular as tabelas correspondentes.

Para a execução do script, deve-se seguir o mesmo roteiro descrito no passo anterior:

• A Equipe do Projeto executa scripts no ambiente de Desenvolvimento;
• Utilizar a ferramenta SCMBD para executar scrips nos ambientes de Homologação e Produção.

A disponibilização do arquivo de deploy (versão do sistema) é feita via ferramenta Jenkins (https://www.trt9.jus.br/jenkins/).

Ao enviar o arquivo de deploy, o Jenkins automaticamente instala a versão nos ambientes de Desenvolvimento, Homologação e Produção. Porém, a versão em Produção será instalada APENAS se for informada o número da RDM correspondente.

Crie uma Solicitação de Serviço de requisição de mudança (RDM) para o Serviço de Gerenciamento de Mudanças com as seguintes informações:

• Assunto: Colocar no formato "[RDM] <nome do sistema> - Deploy: <versão>". Ex: "[RDM] Acompanhamento de Sessão - PJe-JT - Deploy: 1.0.7";
• Descrição do sistema: <informar o nome do sistema>; 
• Objetivo/Justificativa: <exemplo: liberação das funcionalidades de Cadastro de Usuário, Cadastro de Juízes e envio de email quando prazo de recurso está acabando. Correções dos bugs 4412 e 4415 do JIRA. Melhora na performance da aplicação.>;
  
• Instruções: <descrever as instruções. Exemplo: realizar deploy do .ear>;
• Procedimento de rollback (se necessário): <exemplo: Retornar o .ear antigo>;
• Horário preferencial: <informar horário que deseja que o procedimento seja realizado>;
• Dados para contato: <informar nome do servidor e ramal para contato>.

Com o documento de RDM em mãos, o Gerente de Configuração e Mudança deve criar ou atualizar o Release Notes para incorporar as mudanças desta nova versão do software antes que o produto seja lançado. O insumo para geração do Release Notes são as solicitações de mudança atualizadas.

O Gerente de Projeto deverá comunicar a disponibilização da nova versão do sistema para as áreas envolvidas com a mudança.