Menu de navegação

[MottaParticipante]

Prezados ,

Feliz Ano Novo !

———————————————————————-

Existe alguma forma prática de versionar Objetos Oracle ,

principalmente

Procedures

Functions

Views

“Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 – Production
Version 19.14.0.0.0”

 

[José Laurindo ChiappaModerador]

Bom dia, blz ? Um excelente Ano Novo para vc, também… Então, não há software de versionamento built-in no SGBD Oracle, então vc VAI ter que adotar um software de versionamento externo : hoje os mais populares são o SVN/Subversion, o GIT, o LiquiBase e o TFS…
Aqui no trabalho temos uma equipe de desenvs que usa SVN e outra que usa GIT, tanto para versionar o código-fonte da app quanto para versionar objetos e código-fonte armazenado no banco Oracle – ambos são bastante estáveis, e são bastante aceitos e conhecidos, eu achei o SVN um pouco mais estável : não sei se foi orelhada dos devs que fizeram o setup todo, mas já tive alguns casos aqui onde meu client do git ficava em conflito com o branch do pessoal e não conseguia se atualizar, aí o dev que manja mais disso teve que me dar um suporte e rodar uns comandinhos pra acertar, euqnato o svn por enquanto nunca deu enrosco…

O procedimento para usar um software desses é relativamente simples : o que esses softwares controlam são arquivos-texto, e depois de ter um servidor de rede acessível a todo mundo, instalar o server do software de versionamento desejado e confirgurar uma pasta central com sub-pastas onde estão todos os arquivos-texto com todos os códigos que vc quer versionar, vc indica no server do software que pasta é essa, se assegura que as máquinas-clients dos devs Possuem todo mundo acesso à essa pasta de rede central E possuem o client da app de versionamento escolhida e é isso : daí em diante , TEM que ser policiado o ambiente para que SEMPRE que se vai fazer uma alteração em um objeto do banco (da mesma forma que sempre que se vai fazer alteração na app) , o alterador ‘puxe’ o código-fonte a partir do repositório (dessa pasta de rede central) , e depois de aplicado grave a nova versão do código no arquivo, e então faça o COMMIT, ie, peça para o software de versionamento gerar nova versão do código, automaticamente ao se fazer isso o arquivo-texto com a versão antiga vai ser versionado para uma versão anterior….

Obs :

1. aqui no trabalho o pessoal usa uma estrutura mais ou menos tipo :

C:\NomedaAPP\scripts\pendentes>dir /on
O volume na unidade C não tem nome.
O Número de Série do Volume é 3C18-212D

Pasta de c:\NomedaAPP

02/12/2024 14:43 <DIR> .
03/01/2025 17:25 <DIR> alteracoes
18/12/2024 15:20 <DIR> documentacao
02/12/2024 14:42 <DIR> DW
02/12/2024 14:43 <DIR> functions
02/12/2024 14:43 <DIR> jobs
02/12/2024 15:54 <DIR> modelo
02/12/2024 14:43 <DIR> mviews
02/12/2024 14:43 <DIR> packages
02/12/2024 14:43 <DIR> portabilidade
02/12/2024 14:43 <DIR> scripts
02/12/2024 14:43 <DIR> sequences
02/12/2024 14:43 <DIR> sinonimos
02/12/2024 14:42 <DIR> SP
02/12/2024 14:43 <DIR> triggers
02/12/2024 14:43 <DIR> usuarios
02/12/2024 14:43 <DIR> views
0 arquivo(s) 0 bytes
17 pasta(s) 401.580.666.880 bytes disponíveis

Veja acima que não só o código-fonte de stored PL/SQL (ie, Procedures, Functions, Packages e Triggers) mas TAMBÉM código-fonte SQL armazenado no datbase (views, views materializadas) são versionados… O pessoal optou (corretamente, imho) em versionar TAMBÉM itens que disparam código SQL e PL/SQL (ie, views) e TAMBÉM versionar as ESTRUTURAS DE DADOS, como tabelas e índices , aí CADA alteração numa estrutura de dados fica versionada e portanto em tese PODE ser desfeita… OBVIAMENTE, é por conta do freguês CONTROLAR as inter-dependências , assim se um novo release X da app exigiu alteração no código-fonte do programa P da app, criação da nova coluna C na tabela T, e alteração na stored procedure SP_XYZ para usar a nova coluna, TODOS ESSES ARQUIVOS DE CÓDIGOS ** tem ** que compor un Build, um ‘release da app’ conjunto, e precisam ser aplicados juntos, E se por qquer motivo precisar voltar, TODOS ESSES CÓDIGOS precisam ser ‘desfeitos’….

2. A partir do momento ue vc usa versionamento do seu código, passa a ser AINDA MAIS IMPERATIVO vc ter um ambiente de teste/desenvolvimento, um de Homologação e um de Produção, JUSTAMENTE para evitar ao máximo vc ter que ‘desfazer/voltar atrás’ um release da app – a idéia é fazer TODOS OS TESTES necessários para desenvolvimento em Dev, fazer a Demonstração E os testes reais com os usuários em HOMO, e só então, com tudo Aprovado e Validado, aí sim os códigos-fonte que precisaram ser alterados são versionados…

3. Existem softwares que fazem a ‘ligação’ do software de versionamento com o banco de dados E com a IDE / tool de desenv que os desenvolvedores usam, Automatizando várias dessas tarefas citadas acima : o pessoal aqui não tinha verba pra isso, mas https://www.red-gate.com/products/flyway/ é um desses, e https://dbmstools.com/categories/version-control-tools/oracle lista outras vários… Na ausência de um software do tipo, vc até pode ter coisas como trigger de DDL que impeça alterações no banco prod fora de hora/sem aprovação da gerência/supervisão , e que talvez já gere os arquivos-textos que precisam ser versionados , mas MUITO desse procedimento vai ser manual, como é aqui…

4. Até dá para fazer o mesmo (com muito mais trabalho, ao que sei) no SVN e no git, mas o Liquibase e o TFS normalmente usam um conceito um tanto diferente, que são so change logs : eles são um .XML contendo a relação do que foi mudado, aí vc envia esse .XML pro server e ele já aplica as alterações e gera novo release da app … Para vc ter uma idéia, dá um look em https://oracle-base.com/articles/misc/liquibase-automating-your-database-deployments … Se vc quiser usar esse conceito mais “automatizável” , existem tools que Automatizam muito da geração do change log e da aplicação, https://www.youtube.com/watch?v=oyU11sk51ao e https://www.youtube.com/watch?v=lxkZyRVta9E exemplificam o uso do freeware SQLcl da Oracle para isso… Já TFS , ao menos pelo que me foi dito (como não sou dev mas sim DBA, vendo aqui o peixe como me foi oeferecido), é mais voltado/pensado para quem usa VisualStudio, então para conectar com banco Oracle e versionar código SQl ou PL/SQL, vc precisaria de ainda mais camadas, tipo instalação do plugin https://www.oracle.com/br/database/technologies/developer-tools/visual-studio/ : em principio, como o pessoal não use VS Studio aqui, por isso que não foi usado nada disso…

É isso, espero que isso te seja útil…

[José Laurindo ChiappaModerador]

Dica extra : além de vc ter o código-fonte (de tudo, desde DDLs e queries armazenadas em views até stored PL/SQL e JOBs) versionado num software externo de verionamento, OPCIONALMENTE, desde a versão 11g vc pode também ter versionamento DENTRO DO DATABASE, que nem eu mostro no meu artigo https://www.profissionaloracle.com.br/2024/10/10/upgrade-de-aplicacao-com-zero-downtime-usando-edition-based-redefinition/ e a Oracle documenta um pouco mais aprofundado em https://www.oracle.com/a/tech/docs/ebr-technical-deep-dive-overview.pdf além da Doc oficial dela….
A vantagem de vc fazer isso internamente dentro do banco é que, como o objeto versionado ESTÁ localmente disponível dentro do database, num formato que ele, database, conhece e é capaz de manipular, vc pode criar nova Edition, nova “versão” do objeto MESMO QUE NESTE MOMENTO o objeto original esteja em uso, assim ELIMINANDO (ou diminuindo Drasticamente) downtimes da Aplicação durante upgrades de versão de código de database. ALÉM de vc.DBA, poder consultar ‘versões’ anteriores do Objeto via query no próprio database, SEM DEPENDER de clients de apps externas ao banco…. As desvantagens são , primeiro, que Obviamente isso OCUPA SIM espaço no dicionário de dados (pouco, mas Ocupa), e segundo, nem TODOS os objetos e nem Todo e qualquer código-fonte aceita EBR : a cada Release a Oracle vem eliminado restrições, mas veja na doc da sua exata release de SGBD Oracle quais tipos de objeto podem ter EBR….

[MottaParticipante]

Grato pelo retorno , vamos estudar estes casos.

===============================

[José Laurindo ChiappaModerador]

Blz, qquer dúvida/qquer necessidade, tamos aqui, é só mandar msg… E se posso dar duas dicas finais, primeiro *** INSISTA ** em versionar Não Apenas código -fonte SQL e PL/SQL armazenado no banco (ie, Views, procedures, Functions, packages e Triggers) mas TAMBÈM VERSIONE os arquivos contendo a modelagem do database, versione TODO e QUALQUER DDL aplicado nas tabelas (não só DDLs que criam objetos, como CREATE INDEX por exemplo, mas TAMBÉM os DDLs que adicionam/removem colunas e constraints, que alteram cláusulas/propriedades internas do objeto OU do database), versione os objetos programados que não contem mas podem EXECUTAR código SQL ou PL/SQL, como JOBs de banco, versione objetos não programados mas que são usados por código, como SINÕNIMOS, DATABASE LINKs, ROLEs… O pessoal da app é DOIDINHO para ‘esquecer’ desses caras, mas eles são sim parte INTEGRAL da sua Aplicação, vc com certeza Não se Arrependerá de os versionar….
A segunda dica é : por mais que o pessoal (erradamente imho) pense que desenvolvimento Ágil e Eficiente entre outras coisas seja Não Ter Documentação nem ter procedimento algum de promoção de código e de alterações de banco para Prod, isso Não É verdade : ambas as coisas são CRUCIAIS para o Sucesso de uma aplicação, o que a metodologia Ágil exige é que eles sejam feitos, SIM, mas feitos da maneira MAIS RÁPIDA E EFICIENTE, aí que entram coisas como softwares e ferramentas/procedimentos que aceleram esses itens, que repito, são cruciais… E isso tem ligação DIRETA com versionamento, se vc está versionando é para ter Rastreio e Controle das suas alterações, então elas TEM que ser Documentadas e Tem que seguir um procedimento de Promoção de Código só após testes e Homologação, por mais expedito que seja o rito…

Abraços,

Chiappa

[Autor]

Posts