Joao Paulo L.G., Um Mero Servidor de TI

 Ao final do post anterior ( segunda parte da série sobre o Flyway ), deixamos três problemas para serem resolvidos na nossa implantação do Flyway no nosso projeto. Eis os problemas que foram expostos: Senhas expostas no arquivo pom.xml ; Como diferenciar ambientes diferentes para o projeto; Scripts incluídos no arquivo jar / war gerado. Vamos às soluções para esses problemas! Problema 1 - senhas expostas : A solução para este problema se dá em duas partes. Primeiramente, removemos as credenciais de acesso do pom.xml e colocamos no arquivo settings.xml do Maven . Esse arquivo traz toda a configuração do framework e fica localizado na subpasta conf da pasta de instalação. Localize a seção <servers> no arquivo, e adicione uma entrada <server> , contendo um identificador para essa entrada, mais o usuário e a senha. Como no exemplo abaixo: <server>    <id>ripando</id>    <username>usrmusica</username>    <...

 Neste segundo post falando sobre o Flyway , vamos meter a mão na massa e trazer um exemplo para implementar a ferramenta em um projeto Java EE. Basicamente, mexeremos no arquivo pom.xml, então conhecimentos de Maven serão necessários. Tentarei explicar os principais conceitos ao longo do post. Vamos lá! (o post relativo a primeira parte pode ser lido aqui ) O primeiro passo é criar a pasta src/main/resources/db/migration , onde ficarão os scripts de banco de dados. Esses scripts deverão receber um padrão de nomeação especial: todos os scripts deverão conter o prefixo Vxx__ , com xx indicando a versão. Repare no duplo caractere underline . Se o script se referir à uma view ou stored procedure, o prefixo deve ser R__ . Alguns exemplos de nomes de scripts:  V01__criacao_tabelas.sql; V02__inclui_indice.sql; R__view_func_ativos.sql; R__sp_inclui_func.sql. No segundo passo, vamos mexer no pom.xml . Adicionaremos, na seção plugins , o plugin do Flyway . Os plugins são uma forma q...

  Quando temos uma empresa terceirizada de fábrica de software desenvolvendo, geralmente especificamos no edital de licitação que essa empresa precisa entregar alguns artefatos obrigatórios para poder receber pelos serviços prestados: o código-fonte (óbvio!), diagramas UML (quando necessário), evidências de testes (artefato que cada vez mais me convenço que de nada serve)... e um plano de implantação. Esse plano de implantação precisa trazer os passos necessários para colocar o produto no ambiente de homologação (e, posteriormente, no ambiente de produção). Na maioria das vezes, um ou mais scripts de banco de dados que devem ser executados. Nós, servidores, tínhamos que abrir o plano de implantação, verificar os passos, acessar o versionador, abrir a ferramenta de banco de dados, copiar o(s) script(s), executá-los, tudo manualmente, gerando um trabalhinho chato e propenso a erros. Além disso, os scripts sempre ficavam meio perdidos: as vezes espalhados por pastas relativas às orden...

 Deixe me apresentar: sou João Paulo L.G., servidor público federal, 11 anos no Ministério Público e 16 anos no Poder Executivo - sim, 27 anos de serviço público no total! Sempre que resolvi escrever algo para publicar na Internet acabava falando sobre uma paixão que não tem a ver com minha profissão. Sempre escrevia sobre rock. Inclusive passei uns dez anos com um blog desse assunto (se quiser conferir, eis o link:  https://ripandohistoriarock.blogspot.com/ ). Mas agora chegou a hora de eu gastar um pouco de tempo escrevendo sobre Tecnologia da Informação. Especialmente na sua utilização no serviço público, minhas experiências com terceirização, ferramentas, licitações, sistemas legados, legislação e qualquer outro assunto onde possa deixar registrada minha opinião para tentar ajudar os colegas que também são servidores e tentar esclarecer visões distorcidas e melhorar a visão do serviço público brasileiro - ao contrário do que alguns pensam, um serviço que conta com trabalha...