Gerenciamento do Branch de Versão
Descrição de todas as etapas realizadas durante a "vida útil" de um Branch de Versão, desde a abertura até o fechamento.
- Índice
- Definição do Processo
- Abertura do branch de versões
- Definição do Processo
- Criação do repositório do Branch de Versão no Azure
- Criação dos novos casos para Branch de Versão
- Aviso de publicação do novo Branch da Versão para a equipe
- [extinto] Criação do repositório do Branch de Versão no SVN
- Manutenção do branch de versões
- Fechamento do branch e liberação de versões
- Decisão do fechamento do Branch da Versão
- Atualização dos arquivos "Config.ini"
- Atualização dos arquivos Altver.rtf
- Solicitar a inclusão do Branch da versão no main
- Geração de executáveis das versões
- Validação e assinatura dos executáveis
- Geração de Customizações (DLLs) para liberação das versões
- Geração das pastas com as novas versões
- Publicação dos executáveis e instaladores
- Finalização do fechamento do Branch da Versão
- [extinto] Commit das alterações dos arquivos "Config.ini" e "Altver.rft" no SVN
- Subprocessos Dependentes
Índice
Resumo
O livro "Gerenciamento do Branch de Versão" é composto por três capítulos principais. Cada qual contendo as informações referentes à uma etapa do ciclo de vida do branch da versão. Desde sua criação, passando pela sua manutenção até o processo de fechamento e liberação. Este livro, apesar de ser dirigido à equipe da qualidade, também conta com a participação da equipe de desenvolvimento para a realização de algumas etapas do processo.
Sumário
Abertura do branch de versões
Neste capítulo são tratados os assuntos iniciais à abertura do branch de versões, como criação do caso no mantis, criação do branch no SVN e os detalhes do processo.
Manutenção do branch de versões
Neste capítulo são passadas as informações sobre a manutenção do branch durante sua "vida útil", como relacionar as versões dos módulos que serão liberados e a atualização do código do branch para que esteja sempre atualizado em relação ao trunk.
Fechamento do branch e liberação das versões
O último capítulo diz respeito ao processo de fechamento e liberação do branch de versões, que sem dúvida é a etapa que exige mais atenção e possui mais itens à serem feitos, podemos citar, a atualização dos arquivos altver e config.ini, geração dos executáveis, publicação e etc.
Definição do Processo
Resumo do processo
Em termos de desenvolvimento, um Branch é um galho de um tronco (Trunk), que é o repositório principal do código fonte do sistema. Na prática o Branch é uma cópia do código onde os desenvolvedores farão as correções/implementações necessárias, preservando assim a integridade do código no Trunk. Se as mudanças funcionarem conforme o planejado, elas serão mescladas de volta para o "tronco principal" (Trunk).
Essa prática é usada o tempo todo durante o desenvolvimento, onde apesar de o Trunk ser o repositório principal do código fonte, todas as alterações devem ser feitas nos Branchs, por isso a nomenclatura Branch de Versão ou Branch de Versão de Trabalho.
Envolvidos no processo
Indiretamente, toda a equipe de desenvolvimento e qualidade fazem parte do gerenciamento do Branch de Versões. Diretamente cada Branch de Versão terá uma dupla responsável por sua abertura, manutenção e fechamento, ou seja, um desenvolvedor e um testador que darão início ao Branch da Versão e o acompanharão até que o mesmo seja finalizado. Arquivo com a programação dos responsáveis pelo branch de cada versão Clique Aqui.
Etapas do processo
- Abertura do Branch da Versão
- Manutenção do Branch da Versão
- Fechamento do Branch e liberação das versões
Ponto inicial do processo
Por se tratar de um processo cíclico, ou seja, o início do processo de gerenciamento do branch X é iniciado logo após a finalização do processo referente ao branch Y (sendo que Y = X - 1). O seu ponto inicial será sempre após a finalização do fechamento do Branch da Versão anterior, onde a dupla responsável pelo próximo Branch deverá providenciar a abertura do mesmo, repetindo sempre esse ciclo.
Ponto final do processo
A etapa final do gerenciamento do Branch da Versão será a liberação e finalização do fechamento do Branch da Versão, quando o mesmo poderá ser considerado como concluído, dando início à abertura do próximo Branch e repetindo o ciclo.
Resultado esperado
É esperado que com essa estruturação de Trunk, Branch de Versão e Branch por caso (pasta de trabalho de cada desenvolvedor, por caso) mantenha-se a integridade do código fonte do sistema no Trunk e que todas as correções/implementações necessárias não sejam realizadas no Trunk, evitando problemas e garantindo maior segurança nas liberações e entrega das versões aos clientes.
Abertura do branch de versões
Detalhamento do processo de como realizar a abertura de um novo Branch de Versão
Definição do Processo
Resumo do processo
O processo de gerenciamento do Branch de Versões é um ciclo, onde sempre após o fechamento do Branch atual, deverá ser realizada a abertura de um novo Branch, que passará a ser o atual Branch da Versão ou Branch da Versão de Trabalho, onde o mesmo será utilizado até ser fechado e as versões à ele relacionadas sejam liberadas aos clientes.
O pré-requisito para abertura/início de um novo Branch de Versão será que o Branch da Versão atual tenha sido finalizado.
Envolvidos no processo
Sempre será uma dupla que ficará responsável pela abertura, manutenção e fechamento do Branch da Versão, sendo um desenvolvedor e um testador.
Etapas do processo
- Decisão do Fechamento do Branch da Versão
- Atualização dos arquivos "Config.ini"
- Atualização dos arquivos "Altver.rtf"
- Solicitar a inclusão do Branch da versão no main
- Geração dos executáveis das versões
- Validação e assinatura dos executáveis
- Geração das Customizações (DLLs) para liberação das versões
- Geração das pastas com as novas versões
- Publicação dos executáveis e instaladores
- Finalização do fechamento do Branch da Versão
- Criação de novos casos para o Branch da Versão
- Criação do repositório do Branch de Versão no Azure
- Publicação do novo Branch da Versão para a equipe
Ponto inicial do processo
Por se tratar de um processo cíclico, ou seja, o início do processo de gerenciamento do branch X é iniciado logo após a finalização do processo referente ao branch Y (sendo que Y = X - 1). O seu ponto inicial será sempre após a finalização do fechamento do Branch da Versão anterior.
Ponto final do processo
Será a criação do novo Branch da Versão no Azure e a publicação desse novo Branch para a equipe de Desenvolvimento e Qualidade.
Resultado esperado
Realizar toda a documentação do novo Branch da Versão, criando os novos casos no Mantis e publicar os novos casos para as equipes de Desenvolvimento e Qualidade.
Criação do repositório do Branch de Versão no Azure
Após o caso do Branch da Versão ter sido criado no Mantis, será necessário realizar um "New Branch" no Azure.
Essa etapa só poderá ser realizada quando o Branch da Versão anterior já tiver sido vinculado ao main. Portanto antes de realizar essa etapa, confirmar com o desenvolvedor se o Branch já foi vinculado ao main e se pode ser criado o novo Branch de Versão.
O repositório do Branch da Versão deverá ser criado dentro do repositório https://dev.azure.com/SuperSoftDelphi/_git/SistemaERPFISCO
No repositório ir em Branches -> "New Branch" e seguir o modelo:
Em Name:
Número do Branch da Versão+Caso+Número do caso no mantis. Exemplo: "167-Caso-0053630"
Em Base on:
Seguir sempre o padrão deixando em "main"
Após criar o Branch ir em Branches -> 3 pontinhos -> Branch policies
Acessar a aba Policies deixar essa configuração padrão
Na aba Security, deixar como padrão:
Criação dos novos casos para Branch de Versão
Após a liberação e fechamento de um Branch de Versão sempre será necessário realizar a abertura de um novo Branch e, com isso, abrir os casos no Mantis para documentação e manutenção do mesmo.
Criação do Branch da Versão no Mantis
O primeiro passo será a abertura do novo caso do Branch da Versão no Mantis, para isso deveremos preencher os campos conforme exemplos abaixo:
Tipo do Projeto: "Outros";
Categoria: "Outros";
Resumo: "BRANCH DE VERSÕES XXX - GERENCIAMENTO DE CASOS" (sempre incremental em +1);
Descrição: Adicionar a mensagem padrão:
"Caso para controle e gerenciamento dos casos adicionados ao Branch de Versões.
O Branch de Versões é a centralização dos códigos de todos os módulos que estão sendo trabalhados para liberação (Versões cheias).
Todos os casos testados na versão "Por Caso", serão adicionados no Branch de Versões para ser trabalhado para liberação.
Após os casos passarem por testes e retestes e estarem prontos para liberação, os casos são adicionados no TRUNK da Versão de liberação.
O TRUNK será o repositório apenas dos casos que estão 100% finalizados."
Aplicar marcadores: "BRANCH_ERP" ou "BRANCH_FISCO" e "BRANCH_VERSAO";
Departamento: Qualidade ERP;
Tipo e Estado: "Nova Versão".
Após criar o caso, relacioná-lo ao caso 0044448 - Gerenciamento das Versões Correntes:
Após a criação do caso do Branch da Versão no Azure feito pelo Desenvolvedor, copiar o endereço "URL" para o caso no Mantis, no quadro "Informações Adicionais", conforme exemplo:
Criação dos casos de versionamento dos módulos (Casos pai)
Assim como após a liberação e fechamento de um Branch de Versão é necessário fazer a abertura de um novo, também é necessário criar novos "casos pai" para os módulos que foram liberados no Branch da Versão anterior.
O processo para abertura dos "casos pai" é basicamente o mesmo do que o da abertura do caso do Branch da Versão, salvo algumas exceções. Para a abertura dos casos pai seguir as regras abaixo:
Tipo do Projeto: Deve ser o tipo de projeto de cada módulo, exemplo "Compras", "Vendas", "Estoque", etc.
Categoria: "Outros";
Resumo: "Versão 5.191 - COMPRAS" (Número da versão incremental em +1 e o módulo referente ao caso pai);
Descrição: "Versão 5.191 - COMPRAS" (repetir o campo "Resumo");
Aplicar marcadores: "Não é necessário aplicar marcadores;
Departamento: Qualidade ERP;
Tipo e Estado: "Nova Versão".
Após a abertura dos casos, também relacioná-lo ao caso 0044448 - Gerenciamento das Versões Correntes e também ao Branch atual de versões:
Aviso de publicação do novo Branch da Versão para a equipe
Processo feito pelo Desenvolvimento
Após o Branch da Versão ter sido criado tanto no Mantis quanto no Azure, é necessário avisar à equipe de Desenvolvimento e Qualidade que o novo Branch está pronto e que deverão passar a utilizá-lo.
Para isso, no comunicador padrão utilizado pela equipe (atualmente é o Rocket Chat), no canal "Equipe.Delphi.ERP" deverá ser enviada uma mensagem seguindo o padrão:
Pessoal!
BRANCH 168 foi liberado na data 07/04/2026.
Foi criado o caso e pasta no SVN para o BRANCH 169.
https://dev.azure.com/SuperSoftDelphi/SistemaERPFISCO/_git/SistemaERPFISCO?version=GB169-Caso-0053778
Favor utilizar esse BRANCH a partir de hoje.
Obrigado!
[extinto] Criação do repositório do Branch de Versão no SVN
Após o caso do Branch da Versão ter sido criado no Mantis, será necessário realizar um "Copy to" no SVN, copiando o Trunk (https://svn.supersoft.com.br/svn/desenvolvimento/trunk/CodigoBaseSkin) para um novo repositório que será criado para o Branch da Versão.
Essa etapa só poderá ser realizada quando o Branch da Versão anterior já tiver sido vinculado ao Trunk. Portanto antes de realizar essa etapa, confirmar com o desenvolvedor se o Branch já foi vinculado ao Trunk e se pode ser criado o novo Branch de Versão.
O repositório do Branch da Versão deverá ser criado dentro do caminho
ERP:
(https://svn.supersoft.com.br/svn/desenvolvimento/branches/Versoes/ERP)
Fisco:
(https://svn.supersoft.com.br/svn/desenvolvimento/branches/Versoes/Fisco)
e deverá seguir o modelo:
Número do Branch da Versão+Caso+Número do caso no mantis. Exemplo: "042-Caso-0044323"
Dessa forma o endereço completo do Branch da Versão ficará parecido com:
https://svn.supersoft.com.br/svn/desenvolvimento/branches/Versoes/ERP/042-Caso-0044323.
Após inserir o caminho de repositório, uma tela de mensagem de log será aberta, e deverá seguir o modelo:
Número do caso: BRANCH DE VERSÕES + Número do Branch da versão - GERENCIAMENTO DE CASOS.
Exemplo: "0044760: BRANCH DE VERSÕES 048 - GERENCIAMENTO DE CASOS"
Após a realização de todos os passos, o resultado final deverá ser semelhante a:
Manutenção do branch de versões
Descrição dos processos de manutenção do branch de versões. Processos que serão realizados após a abertura da versão corrente até o fechamento da mesma.
Definição do Processo
Resumo do processo
Após a abertura de um novo Branch de Versão, durante a "vida útil" do Branch, ou seja, até que ele seja liberado e fechado será necessário realizar algumas rotinas de manutenção para manter o Branch sempre atualizado e evitar erros na hora da liberação da versão.
Envolvidos no processo
Sempre será uma dupla que ficará responsável pela abertura, manutenção e fechamento do Branch da Versão, sendo um desenvolvedor e um testador.
Etapas do processo
- Vínculo dos casos de versionamento dos módulos (casos pai) com o caso do Branch da Versão
- Manter o repositório do Branch da Versão atualizado no SVN
Ponto inicial do processo
Inicia-se logo após a abertura do Branch da Versão.
Ponto final do processo
Deverá ser realizado diariamente até o fechamento e liberação do Branch da Versão.
Resultado esperado
Manter o Branch da Versão atualizado tanto no Mantis quanto no SVN, facilitando para a equipe saber em tempo real quais casos e versões estão relacionados ao mesmo.
Etapas de manutenção do Branch da Versão
Após a abertura de um novo Branch de Versão, durante a "vida útil" do Branch, ou seja, até que ele seja liberado e fechado será necessário realizar algumas rotinas de manutenção para manter o Branch sempre atualizado e evitar erros na hora da liberação da versão.
No mantis, conforme os casos de erros/implementações forem relacionados ao branch de versões, deve-se verificar se o caso da versão do respectivo módulo que será liberado com o caso tratado já se encontra relacionado no branch de versões, caso não esteja, então deve-se relacionar.
No azure o branch da versão está sempre atualizado, pois nenhum PR deve ser feito diretamente na main. Atualmente a equipe Fisco e ERP utilizam o mesmo branch de versão que é gerenciado pela equipe ERP.
No SVN, a única rotina que precisará ser feita é a realização de um update, merge e commit diário, de preferência no início do dia, para que o Branch da Versão sempre fique atualizado em relação ao trunk.
Fechamento do branch e liberação de versões
Descrição dos processos à serem realizados para realizar a liberação e fechamento do Branch da Versão corrente.
Decisão do fechamento do Branch da Versão
Processo feito pela qualidade
Após ser definido que o Branch da Versão será fechado, deve-se avisar à equipe de Desenvolvimento e Qualidade para que não subam mais nenhum tratamento e/ou façam alterações no Branch. Para isso, no Rocket Chat (ferramenta utilizado internamente para comunicação) no canal "Equipe.Delphi.ERP" deve ser enviada uma mensagem padrão, conforme exemplo abaixo:
"Pessoal,
Por favor, não subir mais nenhum tratamento para o Branch XXX.
Irei começar a fazer a liberação dos módulos.
Obrigado!"
Após comunicar a equipe sobre o fechamento da versão, confirmar no Mantis se todos os casos vinculados ao Branch foram realizados os testes e revisão de testes e se estão com o status "Aguardando liberação de versão". Confirmar também se todos os casos do versionamento dos módulos que serão liberados foram vinculados ao caso do Branch, conforme exemplo abaixo:
O quadro em verde está demonstrando todos os casos de versionamento de módulos e que serão liberados no Branch da Versão. Neste exemplo, no Branch 041 serão liberados os módulos Vendas e Compras.
No quadro em vermelho estão todos os casos de erros, solicitações ou melhorias que estão relacionados ao Branch 041 e que serão entregues através dos módulos de Vendas e Compras.
Os casos de versionamento de módulos que serão relacionados ao Branch da Versão dependerão dos casos de erro, solicitação ou melhorias que serão liberados. Se no Branch houver apenas casos do Financeiro, por exemplo, não há necessidade de liberação dos demais módulos, a não ser que para correção de algum destes casos seja necessária alguma correção em uma unit comum, nesta situação precisarão ser liberados todos os módulos que fazem uso da unit em questão.
Casos de versionamento de DLLs também devem ser vinculados ao caso do Branch da Versão.
Atualização dos arquivos "Config.ini"
Processo feito pela qualidade em um computador que possui o Delphi
Os arquivos "Config.ini" são os arquivos onde informamos o número do caso pai (caso de versionamento das versões), número da versão e data de liberação dos módulos, portanto é necessário atualizar estes arquivos à cada liberação de versão.
Antes de começar a atualizar estes arquivos precisaremos selecionar o Branch da versão no Azure e em seguida siga os passos abaixo para atualização dos arquivos:
Na pasta do Branch da Versão (Exemplo "C:\Codigo Fonte"), acessar "WorkingCopies > Sistemas", conforme exemplo:
No quadro "Pesquisar Sistemas" digitar "config.ini" para que sejam filtrados apenas os arquivos que contenham esse nome e extensão:
Selecionar os arquivos de todos os módulos que serão liberados, clicar com o botão direito do mouse e em seguida clicar em "Edit with Notepad++":
Neste exemplo faremos a liberação do Branch 041, portanto serão liberados apenas os módulos de Compras, Vendas e NFe.
Os arquivos serão abertos com o aplicativo do Notepad++, conforme demonstrado abaixo. Em todos os arquivos será necessário atualizar os campos "CasoPai", "DataLiberacao", "Versao1" e "Versao2". Após atualizar os campos clicar no botão "Salvar":
Caso Pai
Caso do versionamento do módulo, no Branch 41 o caso pai do módulo de Vendas é o 0044227, por exemplo.
Data Liberação
Data que serão compilados os executáveis para liberação.
Versao1
Preencher com o número da versão anterior ao "ponto". No exemplo do Branch 041 será liberada a versão 6.555 do Vendas, portanto o campo "Versao1" deve ser preenchido com "6".
Versao2
Preencher com os números após o ponto. No exemplo da versão 6.555, preencher o campo "Versao2" com "555".
Atenção: Somente para o arquivo do módulo NE é necessário preencher também os campos "Versao1Principal" e "Versao2Principal".
O módulo NE utiliza as mesmas configurações do projeto do Vendas, portanto o arquivo "Config.ini" do NE deve apontar qual a versão principal do módulo do Vendas que ele estará vinculado.
No exemplo da liberação do Branch 41, que iremos liberar a versão 6.555 do Vendas, os campos deverão ser preenchidos da seguinte forma:
Atualização dos arquivos Altver.rtf
Processo feito pela qualidade em um computador que possui o Delphi
O que são os arquivos "Altver"?
Os arquivos "Altver" contém as informações do que será liberado em cada versão. Existem versões que apenas trataram ajustes/erros no sistema e outras versões que além de correções de erro, liberam também alguma melhoria do sistema, novo recurso, etc, então os mesmos precisarão ser preenchidos de acordo com essas informações.
Geração dos arquivos:
O arquivo deverá ser criado sempre através do WordPad, devendo conter o número da versão que será liberada e quais as implementações da versão, conforme exemplos abaixo:
Exemplo de arquivo Altver onde foram realizados apenas ajustes ou correções de erro no sistema:
Exemplo de arquivo Altver onde houveram melhorias no sistema:
Para o módulo NFE não é necessário criação do arquivo Altver, pois utilizará o mesmo arquivo que o módulo de Vendas.
Atualização dos arquivos "Altver.rft" no SVN e módulos
Após gerar os arquivos Altver de todos os módulos que serão liberados, será necessário atualizá-los no SVN e no projeto de cada módulo.
Atualização dos arquivos Altver no SVN
Para isso, acessar a pasta do Branch da Versão e em seguida "WorkingCopies > Sistemas > Vendas", por exemplo. Deverá eliminar o arquivo "Altver.rtf" já existente e substituir pelo novo arquivo gerado, mantendo a nomenclatura "Altver.rtf":
Esse processo deverá ser repetido para todos os módulos que serão liberados, exceto o módulo NFE, que utilizará o mesmo arquivo que o módulo Vendas.
O arquivo "AltverNE.rtf" não deve ser excluído ou substituído.
Atualização dos arquivos Altver nos módulos (projetos)
Após fazer a substituição do arquivo "Altver.rtf" da pasta de cada um dos módulos que serão liberados, será necessário alterar o projeto de cada um dos módulos para que ele passe a "enxergar" o novo arquivo adicionado. Para isso deveremos acessar a pasta "project" e executar o programa "VD.dproj":
O projeto do módulo que executou, "VD.dproj", "CC.dproj", "FN.dproj" (...) será aberto aberto no Delphi:
Na tela do Delphi, utilizar o comando "CTRL + F12" para abrir a tela de pesquisa de units "Search for units". No campo de pesquisa digite "altver", em seguida selecione a unit "ALTVER1.pas" e clique em "OK". Será aberta a unit "ALTVER1" em uma nova aba:
Clicar na aba "VD", pesquisar novamente por "altver" e agora selecionar a primeira opção, "AltVer.pas". Clicar em "OK" e será aberta uma nova aba com a unit "AltVer":
A ordem de abertura das units sempre devem seguir o padrão "ALTVER1.pas" e depois "AltVer.pas" por motivos relacionados ao código(herança).
Na unit "AltVer" aperte a tecla F12 do teclado e será aberta a tela "Correções e Implementações da Versão Corrente":
Observar que por enquanto o número da versão e as implementações não foram atualizadas.
Clicar com o mouse dentro do quadro "Correções e Implementações da Versão Corrente" para selecioná-lo e em seguida, nas propriedades do canto inferior esquerdo da tela, clicar no DLG da propriedade "LoadRTF". Será aberta uma tela para buscar o arquivo à ser importado:
Na tela "Selecione um RTF", certifique-se de que está dentro da pasta do projeto correto, ou seja, do mesmo projeto que estiver fazendo as alterações no Delphi e então selecione o arquivo "Altver.rtf" e clique em "Abrir".
Após importar o novo arquivo "Altver.rft", verifique que no quadro "Correções e Implementações da Versão Corrente" o número da versão e o conteúdo serão atualizados conforme o arquivo importado. Clique no botão "Salve All (Shift+Ctrl+S)" para salvar o projeto e em seguida pode fechar o Delphi:
O altver do NE é atualizado dentro do projeto do VD pela parte lateral "PagesControl1" onde tem os dois altver "TS_ALTVER" e "TS_ALTVERNE":
É só clicar no "TS_ALTVERNE" e selecionar o arquivo AltverNE.rtf conforme feito nos demais projetos:
Solicitar a inclusão do Branch da versão no main
Processo feito pela qualidade
Após concluir a revisão de teste de todos os casos que foram incluídos no branch da versão e a atualização dos arquivos "config.ini" e "altver.rtf", uma anotação solicitando a inclusão do branch da versão no main deverá ser enviada para o desenvolvedor responsável no Mantis (branch da versão atual). Informando os módulos que foram alterados e os casos que foram tratados.
A anotação de solicitação deverá seguir o seguinte padrão:
A anotação não só ajuda na conferência dos arquivos altver e config.ini antes do commit, como facilita muito a busca por casos quando necessário buscar um tratamento de uma determinada versão.
Geração de executáveis das versões
Processo feito pelo desenvolvimento
Compilando os executáveis
Para gerar os executáveis que faremos a liberação, deveremos acessar a pasta do projeto dentro do main, exemplo (C:\Codigo Fonte\CodigoBaseSkin\WorkingCopies\Sistemas\SSVendas\project) e em seguida abrir o arquivo ".dproj":
Será aberto o Delphi, digitar "Shift+F9" para abrir a tela "Configurações de Compilação". Selecione qual a Empresa (ambiente) será gerado o executável e confira se os campos "Caso Pai", "Data de liberação" e "Versão" estão corretos. No quadro "Diretório" selecione onde o executável deverá ser salvo e então clique em "OK (F5)":
Será exibida a tela "Information". Clique em "Yes to All" e em seguida em "OK":
Será iniciada a compilação do executável:
Quando a compilação for finalizada, no canto inferior esquerdo será exibida a mensagem "Sucess" e o tempo de compilação:
Verifique que o executável terá sido gerado dentro do diretório indicado anteriormente. Confirmar se o executável foi gerado corretamente de acordo com as opções selecionadas, observando as informações de "Data de modificação", "Marcas Registradas", "Nome do produto" e "Versão do produto":
Até aqui fizemos a compilação do executável do Vendas apenas para o ambiente Nooven, então precisaremos compilá-lo ainda para o ambiente SuperSoft e depois compilar os executáveis das demais versões que serão liberadas. Para não perder os executáveis que já geramos e ir fazendo a separação, é aconselhável criar os diretórios "SS", "NV" e "EC" e ir alocando os executáveis gerados em cada uma dessas pastas, conforme o ambiente do executável:
Recortar o executável e colá-lo dentro da pasta do ambiente correspondente. Neste exemplo, "NV":
Agora compilaremos o executável do Vendas para o ambiente Supersoft. Voltar no Delphi, digitar "Shift+F9", selecionar a empresa "SuperSoft" e clicar em "OK (F5)" e seguir os passos:
Observar que agora terá sido gerado o executável do ambiente "SuperSoft". Recortar e colar o executável dentro da pasta do diretório correspondente:
Os passos acima deverão ser realizados para todos os executáveis que serão liberados.
O módulo NE estará dentro do projeto do Vendas, para compilá-lo deverá executar o arquivo "NE.dproj".
Para os módulos "NE" e "FN" é necessário compilar também os executáveis para o ambiente E-Contab.
Validação e assinatura dos executáveis
Processo feito pela qualidade
Conferência dos executáveis
Após todos os executáveis terem sido compilados, o desenvolvedor responsável irá passar o caminho que foi gerado os executáveis e customizações vinculados ao branch.
Copie as pastas referentes à cada ambiente para que possam ser conferidos.
Validação das informações na abertura dos executáveis
Copiar os executáveis para o local da instalação dos sistemas SuperSoft e executá-lo para abertura do sistema:
Verifique se a versão que será exibida e se nome, ambiente e versão do sistema estarão corretos:
Após atualizar o sistema, acessar o menu "Ajuda > Sobre" e verificar se o número da versão, data da liberação e número do caso pai estarão corretos (dados do arquivo "Config.ini"):
Em seguida acesse o menu "Ajuda > Correções e Implementações da Versão" e confira se a versão e as implementações/melhorias estão corretas (dados do arquivo "Altver.rtf"):
Validação das informações do executável (propriedades)
Clique com o botão direito do mouse no executável e em seguida clique me "Propriedades". Será aberta a tela com as propriedades do executável:
Clique na aba "Detalhes" e confira se os dados "Descrição do arquivo", "Versão do arquivo", "Nome do produto", "Versão do produto", "Direitos autorais" e "Marcas registradas" estarão corretos:
Exemplo de dados das propriedades do módulo Vendas do ambiente Supersoft.
Exemplo de dados das propriedades do módulo Vendas do ambiente Nooven.
Os passos acima deverão ser realizados para todos os módulos que serão liberados e para todos os ambientes.
Assinando os executáveis
Após ter conferido todos os executáveis será necessário assiná-los. Para isso precisará ter em mãos o certificado digital da SuperSoft, (atualmente a assinatura dos exes está sendo realizado pelo Filipe.Erbetta).
Com o certificado já plugado na máquina, execute o programa "Assinador de Arquivos", disponível no caminho (\\ss\qualidade\Compilador\Assinador de exe):
Clique no botão "Add Arquivos" e será aberta a tela "Arquivos Executáveis". Selecione todos os executáveis e clique em "Abrir":
Todos os executáveis que foram selecionados serão listados, então clique no botão "Assinar" para iniciar a assinatura:
O sistema irá solicitar a senha do certificado para que os executáveis sejam assinados. Preencher a senha:
Após assinar os executáveis, o programa "Assinador de arquivos" adicionará um "OK" na frente de cada um dos executáveis selecionados e que foram assinados:
Para conferir se todos os executáveis foram assinados corretamente, verifique se nas "Propriedades" de cada um dos executáveis foi adicionada a aba "Assinaturas Digitais":
Geração de Customizações (DLLs) para liberação das versões
Processo feito pelo desenvolvimento
Atualmente a Custom está sendo gerada conforme o passo a passo do Azure
Compilando uma Custom SVN (extinto)
Para a compilação de uma Custom será necessário baixar a pasta específica dela que fica em "https://svn.supersoft.com.br/svn/desenvolvimento/outros/DLLs/EmFireDac Skin" com o nome do módulo + o nome do cliente, exemplo "CustomVDOasis":
Para compilar será necessário copiar essa pasta do EmFireDac Skin para o trunk -> CodigoBaseSkin -> WorkingCopies -> Sistemas, e colar:
Após isso abrir a CustomVD.dproj (sempre será o nome do módulo da custom que está sendo compilada) que está dentro da Custom -> Project:
Atualização da versão dentro da Custom
Ao abrir, antes de compilar será necessário ajustar o número da verão em da custom, ir em "Project -> Options -> Version Info" e corrigir para o número da versão que será liberada, e clicar em OK:
Na pagina inicial, abaixar a barra e corrigir o número da versão e conferir o nome da Custom:
Após isso crie uma pasta em: \\ss\qualidade\LIBERADO_DLLs + o nome do cliente + o nome do projeto da custom, exemplo: "\\ss\qualidade\LIBERADO_DLLs\Oasis\CustomVD"
Pasta das Customizações
Crie uma pasta com o número do caso + versão + data de liberação, assim sempre terá as versão antigas salvas
Antes de compilar será necessário ajustar o caminho para salvar a dll em "Project -> Options -> Delphi Compiler -> Output directory" e clicar em OK:
Salve o projeto:
Compilando a Custom
Digitar "Shift+F9" para iniciar o processo de compilação, será exibido no canto inferior esquerdo será exibida a mensagem "Sucess" e o tempo de compilação:
Commit da Custom
Depois acesse novamente a pasta em que foi compilado o projeto e copie os arquivos .dpr e .dproj:
E cole (clique em SIM para substituir) dentro da pasta "EmFireDac Skin" -> nome do projeto -> Project:
Após isso é só clicar com o botão direito na tela TortoiseSVN -> Commit, como padrão sempre usamos o resumo do caso:
Depois ao dar o showlog na pasta será possível ver a alteração na versão da Custom:
Validação das informações das Custom
Após a custom ser compilada será necessário conferir se foi gerada a versão correta, acesse o caminho em que foi compilada:
Selecione ela, clique com o botão direito e vá em "Propriedades" -> "Detalhes" e veja se a versão do arquivo está correta:
Geração das pastas com as novas versões
Processo feito pela qualidade
Publicação no diretório da Qualidade Assinados Temp
É necessário copiar os executáveis da versão (assinados) para para cada ambiente que será liberado no diretório: \\ss\qualidade\LIBERADO_VERSOES_EXECUTAVEIS\Assinados_Temp
Nesse exemplo será liberado o FN e NE do ambiente eContab:
Também é necessário substituir os arquivos altver.rtf para os novos do branch atual:
Publicação das Versões liberadas no diretório da Qualidade
Primeiramente deverá ser criada uma pasta para cada módulo que será liberado, seguindo o padrão "Número do caso pai_Versão_Número da Versão_liberado_data da liberação", conforme exemplo: "0053706_Versão_5.190_liberado_07-04-2026". Dentro dessa pasta deverão ser criadas uma pasta para cada ambiente que será liberado:
No exemplo do módulo de Compras, uma pasta "SS" e outra pasta "NV" e o arquivo "Altver" referente ao módulo também deverá ser incluído nesta pasta, com o padrão "Altver+módulo (neste exemplo, AltverCC)":
Dentro da pasta de cada ambiente deverá ser salvo o executável (já conferido e assinado) correspondente:
Este processo deverá ser realizado para todos os módulos que serão liberados.
Após os passos acima serem realizados, copiar a pasta de cada um dos módulos que foram criadas, acessar o caminho "\\ss\qualidade\LIBERADO_VERSOES_EXECUTAVEIS" e colá-las dentro das pastas dos respectivos módulos:
Publicação das Customizações no diretório da Qualidade
Será necessário copiar a pasta as custom que foram geradas pelo desenvolvimento para o caminho "\\ss\Qualidade\LIBERADO_DLLs" + Cliente + Projeto:
Criar uma pasta para cada Custom que será liberada, seguindo o padrão "Número do caso pai_Versão_Número da Versão_liberado_data da liberação", conforme exemplo: "0053725_Versão_5.00_liberado_07-04-2026"
Publicação das Versões Liberadas no diretório Sistemas
Será necessário disponibilizar essas pastas também no diretório \\ss\sistemas\VERSOES LIBERADAS\01. Atualizações + sigla do Módulo:
Publicação das Customizações no diretório Sistemas
Será necessário disponibilizar essas pastas também no diretório \\ss\sistemas\DLLS_NOVO_SKIN + Cliente + Projeto:
Publicação dos executáveis e instaladores
Processo feito pela qualidade
Publicação no Mantis
No Mantis a publicação dos módulos liberados deverá ser apontada em cada um dos casos pai (casos de versionamento dos módulos) que estão vinculados ao Branch que está sendo liberado. Seguindo o padrão de mensagem:
*Adicionar usuários do Suporte, Projetos, Comercial e Qualidade na anotação
[b]COMPRAS 5.190[/b] (Módulo + Número da versão)
Data da publicação: 07/04/2026
Ambientes: SuperSoft / Nooven (Adicionar E-Contab quando for liberação dos módulos NE e FN).VERSÃO LIBERADA EM: \\ss\sistemas\VERSOES LIBERADAS\01. Atualizações\CC (incluir a sigla do módulo no final)
Suporte, Projetos e Comercial,
Favor verificar os casos vinculados a versão e atualizar os clientes que necessitam da atualização.
Obrigada.
Abaixo segue exemplo de preenchimento no Mantis (caso 53706):
Quando houver casos onde foram criadas ou alteradas DLLs de algum cliente, é necessário vincular o caso de versionamento da DLL ao caso do Branch e seguir o mesmo procedimento de publicação para o caso de versionamento da DLL. Abaixo exemplo da mensagem de publicação em casos de DLL:
*Adicionar usuários do Suporte, Projetos, Comercial e Qualidade na anotação
CustomXX Nome_do_Cliente (XX = módulo, exemplo CustomVD, CustomFN, CustomCE, etc).
Versão: 5.00 (sempre incremental a partir de 5.00)
Data de liberação: DD/MM/AAAA
Liberar em conjunto com: SSmodulo XX.XXX (Módulo e versão do módulo que deverá ser atualizado em conjunto).
DLL disponível em:
- \\ss\Sistemas\DLLS_NOVO_SKIN
Qualquer duvida estou a disposição.
Obrigada.
Abaixo segue exemplo de preenchimento no Mantis (caso 53725):
Publicação nos comunicadores (Atualmente pelo Rocket Chat)
No comunicador que estiver sendo utilizado pelos setores (atualmente é o Rocket Chat, no canal "Entrega_de_Versoes_ERP"), deverá ser enviada uma mensagem avisando os usuários sobre a liberação das versões e relacionando os casos que estão sendo liberados. Abaixo segue exemplo do padrão da mensagem à ser seguido:
Suporte, Projetos e ComercialSeguem as versões e casos liberados na data de 07/04/2026.0053705: BRANCH DE VERSÕES 168 - GERENCIAMENTO DE CASOS0053706: Versão 5.190 - COMPRAS
- 0053379: OREGON (NV) Elaine: Inconsistência ao tentar gravar NR de Importação
- 0053477: WAYBOR (SS/NV) - Ao realizar uma NR, a aba “Duplicatas” não é exibida para vínculo com o FN.
- 0053586: Anhembi - (Jonathan) - exportação de notificações não são levadas para fiscal (2.556 352)
- 0053243: TALKLINK (SS) - Ao realizar a importação de NR, sistema não cálculo base de PIS e COFINS para produtos e monofasicos.
- 0053313: ALEXANDRE ALTOMAR (NV) Carolini: NFE com valor do ICMS, porém, sem Base de Cálculo e sem Alíquota do ICMS
0053708: Versão 3.951 - FINANCEIRO
- 0053723: SM ELEVADORES (SS/NV) Compilar DLL de gestão de contratos
- 0053643: QUANTA (SS/NV) Karina - Inconsistência ao selecionar tipo de movimento duplicata descontada
- 0053427: ACITEC SOLUCOES EM TRANSPORTES VERTICAIS(NV-SS): Sistema não permite visualizar e nem salvar o boleto bancário do Banco Inter.
0053731: CustomCP - Brascar 5.00
- 0053198: BRASCAR (NV/SS) Julio/Marcelo - Codificação de produtos especifica conforme grupo e linha de produtos
Qualquer dúvida estou a disposição.Obrigada.
Publicação na Central de Operações
Para o segmento ERP os módulos liberados devem ser publicados na Central de Operações após análise com o líder do desenvolvimento e também mediante autorização do Gerente do setor de Suporte.
Para publicação dos módulos na Central de Operações utilizaremos o programa "GeradorSetupVersao2" disponível em: \\ss\qualidade\FERRAMENTAS\GeradorDeSetup2.0
O executável deverá ser buscado no caminho "\\ss\qualidade\LIBERADO_VERSOES_EXECUTAVEIS\Assinados_Temp", ao abrir o gerador de setups e clicar na opção "Utilizar diretório Assinados_Temp?" ele vai direcionar para a pasta correta e conforme o ambiente selecionado, nesse exemplo publicaremos os eContab
Selecionar os executáveis que serão publicados, conferir a data de modificação do arquivo:
Deverá ser confirmado se os dados do executável estão corretos e em seguida clicar no botão "Publicar", conforme exemplo:
Este processo deverá ser realizado para todos os módulos e para cada um dos ambientes que será realizada a publicação na Central de Operações.
Após realizar a publicação de todos os módulos e ambientes, conferir se em "\\ss\Sistemas\ASSINADOS", dentro da pasta de cada módulo e cada ambiente, se o executável e o arquivo Altver.rtf foi atualizado com a data de liberação do mesmo:
Conferir também se em "\\ss\Sistemas\INSTALADORES", dentro da pasta de cada módulo e cada ambiente, se o instalador foi gerado com a data da publicação:
A conferência da geração dos executáveis, instaladores e dos arquivos Altver deverão ser realizadas para cada um dos ambientes publicados.
Liberação da versão na Intranet
Para liberação das versões para o cliente é necessário acessar a intranet e nas Ferramentas -> Versões
Clicar em "Nova Versão":
Selecionar o módulo, versão e as empresas:
Tornar a versão oficial na Central OP: Só marcar essa opção quando for necessário disponibilizar essa versão para todos os clientes, caso contrario só de cadastrar a versão já será liberada para uso dos clientes.
As versões antigas podem ser excluídas do site e manter apenas uma versão oficial na CentralOP.
Finalização do fechamento do Branch da Versão
Processo feito pela qualidade
Após terem sido realizadas todas as etapas anteriores, agora é necessário apenas fechar todos os casos relacionados ao Branch da Versão (caso de erro/melhoria/customizações e casos de versionamento das versões) para fechar o caso do Branch.
Para isso basta acessar cada um dos casos, começando pelos casos que foram tratados dentro do Branch da Versão atual em questão e seguir os passos abaixo:
No mantis, clicar na opção "Gerenciar", depois "Gerenciar Projetos":
Encontrar o módulo vinculado ao caso, nesse exemplo o SSCompras e entrar nele:
Rolar a tela até a parte das "Versões" aqui será necessário alterar a versão anterior para "Liberada":
Depois no final da listagem Adicionar a nova versão:
Voltar no caso que está "Aguardando Liberação de Versão" e Alterar Status para "Fechado":
E selecionar a nova versão na opção "Corrigido na Versão" e "Fechar Tarefa":
Após fechar todos os casos tratados no Branch, o caso do Branch da Versão passará a demonstrar:
Repetir o processo acima para os "casos pai (Versionamento dos módulos)" e depois fechar também o caso do Branch da Versão.
Depois que todos os casos do Mantis e o Branch da Versão for fechado, no Trello mover os casos da coluna "Aguardando Liberação" para a coluna "Entregues":
Sempre após um Branch da Versão ser encerrado é obrigatório realizar o processo da criação de um novo Branch da Versão e criação dos novos "Casos pai (Versionamento dos módulos)".
[extinto] Commit das alterações dos arquivos "Config.ini" e "Altver.rft" no SVN
Após realizar a atualização dos arquivos "Config.ini" e "Altver.rft" é necessário commitar essas alterações, ou seja, subir as alterações que foram realizadas por enquanto somente em sua máquina para o código fonte do Branch da Versão.
Clique com o botão direito do mouse na pasta do Branch da Versão, exemplo "Caso-BranchVersão-0044433" e em seguida em "SVN Commit":
No quadro das mensagens deverá ser incluída uma mensagem padrão, contendo o Branch da Versão que será liberado, quais casos de versões estão relacionados à ele e quem está realizando o commit (caso esteja utilizando por uma máquina virtual), conforme exemplo abaixo:
No quadro "Changes made" deverão ser selecionados os arquivos que foram modificados e que deverão ser commitados:
Deverão ser selecionados apenas os arquivos com extensões ".dfm", ".Config.ini" e ".rtf".
Dica: Clique no campo "Extension" para que os arquivos sejam ordenados por extensão, assim facilitará selecionar somente os arquivos das extensões ".dfm", ".Config.ini" e ".rtf".
Após selecionar os arquivos que deverão ser commitados, clicar em "OK". Será aberta a tela abaixo para realização do commit, após finalizar clicar em "OK":
Pronto, as alterações foram salvas e enviadas ao código fonte do Branch da Versão.
Subprocessos Dependentes
(extinto) Programação dos responsáveis pelo branch das versões
ERP:
Atualizado dia: 02/03/2021
Até branch: 055
Fisco:
Atualizado dia: 12/05/2021
Até branch: 023
Resumo do processo
Cada Branch de Versão terá uma dupla responsável por sua abertura, manutenção e fechamento, ou seja, um desenvolvedor e um testador que darão início ao Branch da Versão e o acompanharão até que o mesmo seja finalizado.
O arquivo em anexo nesta página, é uma programação para os próximos branchs e com seus responsáveis.
Responsáveis por gerar a programação:
- Ainda a decidir, exemplo ERP em anexo gerado por Mateus Joia(Qualidade).
Manutenção da página
No topo da página terá informações relativas a atualização do documento. Quando o mesmo for atualizado, deve-se atualizar essas informações.
Quanto ao anexar o documento, deverá "substituir" o já existente referente ao seu departamento.
Exemplo:
- Editar página
- Clicar no canto direito em Anexos
- Na tela que abre, clicar em Editar, desta forma conseguiremos substituir o arquivo mas sem alterar nome ou forma lista grande de anexos, já que até o momento o botão Excluir não está funcionando.
- Arraste para área indicada, o novo arquivo atualizado com a programação, após clique em Salvar
Certifique-se de estar substituindo o arquivo correto de acordo com o departamento.
(extinto) Incluindo Branch da versão no Trunk
Processo feito pelo desenvolvimento
Resumo do processo
Passar as alterações trabalhadas no branch da versão, para o Trunk.
- Update e Clean Up nas pastas locais C:\Codigo Fonte e pasta da versão.
- Verificar se a pasta da versão está atualizada com Trunk, isso pode ser feito comparando último log do Trunk com última atualização no branch da versão.
- Caso estiver desatualizada, atualize fazendo Merge.
- Copie os arquivos dentro da pasta da versão (sem utilizar CTRL + A para não selecionar o arquivo oculto do .svn), cole dentro de C:\Codigo Fonte.
- Simule o Commit, aperte em None por segurança, deixe marcado a opção "Show unversioned files" para aparecer os arquivos criados na versão.
- Coloque no log a mensagem de liberação da versão.
- Faça as comparações de alterações necessárias.
- Se tudo certo, então aperte em OK.
Envolvidos no processo
Dupla responsável pelo branch da versão, porém processo realizado pelo Dev.
Etapas do processo
Baixar a pasta a seguir para o computador através de um Checkout usando o endereço:
-
-
https://svn.supersoft.com.br/svn/desenvolvimento/trunk/CodigoBaseSkin
-
Ou caso já tenha em sua máquina, atualizar o Trunk local com Update.
Faça o processo de Merge na sua pasta local, com as seguintes alterações:
URL to merge from: Colocar endereço no branch da versão atual
Ex: https://svn.supersoft.com.br/svn/desenvolvimento/branches/Versoes/ERP/048-Caso-0044760
Merge depth: Working copy Importante essa parte!
Fazer um Commit com as seguintes informações:
Nas Units com Status “modified(property change only)” dar um Revert
Utilizar como mensagem padrão a seguinte estrutura:
Seguir a estrutura:
Resumo do caso pai do branch da versão
Casos pai (versionamento do módulo)
Casos filho (casos relacionados ao módulo acima e que serão entregues através da liberação do módulo)
Ponto inicial do processo
Pedido vindo da qualidade através do caso pai, para que seja incluído no Trunk as alterações do branch da versão.
Ponto final do processo
Avisar no mesmo caso que o código já está no Trunk e avisar na ferramenta de comunicação (Atualmente Rocket) que foi feita a inclusão das alterações e que podem iniciar abertura do casos do próximo branch da versão.
Resultado esperado
Passar para o Trunk o código trabalhado por versão, validado e testado, mantendo a integridade do Trunk para uma eventual versão de urgência "B Erro" no fluxograma.