Ambiente de preparação do banco de dados para pessoal que não é de TI

Estou no processo de propor um ambiente de preparação de banco de dados ao meu departamento de TI. A idéia é que uma pessoa que não seja de TI como eu (analista de dados de obras públicas) teria um lugar para testar soluções e, em seguida, implementá-las no ambiente ao vivo ou pedir à TI para implementá-las, se necessário. Existem algumas razões / cenários em que esse ambiente seria benéfico:

1. Eu tenho alguns privilégios de banco de dados básicos em nosso ambiente de banco de dados ao vivo ( create table, create view, etc.). Eu faço alterações de esquema cerca de uma vez por semana, mas me parece insano testar e implementar essas alterações em um ambiente ativo. Existem inúmeras dependências no banco de dados; portanto, se algo der errado, pode ser desastroso. Prefiro testar as coisas com antecedência em um ambiente separado.
2. Eu não tenho alguns dos privilégios mais avançadas como create triggerou create functionno banco de dados ao vivo. Isso é bom, mas tenho alguns problemas que poderiam ser resolvidos por gatilhos e / ou funções. Planejo propor que sejam concedidas essas permissões no ambiente de preparação para que eu possa desenvolver e testar algumas idéias e, se elas funcionarem, proponho que a TI as implemente no ambiente ativo.
3. Em geral, meu departamento de TI não tem tempo ou recursos para desenvolver soluções para mim. É realmente assim tão simples. Portanto, se eu mesmo puder fazer o trabalho braçal, é muito mais provável que meus problemas sejam resolvidos.

O 'ambiente de preparação para o pessoal que não é de TI' parece uma abordagem suficientemente sólida para mim, mas, para ser sincero, acabei de inventar a ideia. Não tenho ideia de como isso geralmente é feito no mundo de TI / banco de dados.

Existe algum tipo de prática estabelecida de TI / banco de dados que se encaixe nesse cenário? (Estou no caminho certo ao propor um ambiente de preparação de banco de dados para o pessoal que não é de TI?)

Concordo com a resposta de @Marcin Gminiski que você idealmente deseja ter um ambiente que imite a funcionalidade disponível em seu ambiente de produção. Embora meus dois centavos no assunto se refiram a "O que você pode pagar?" As restrições orçamentárias costumam ser as principais causas de um bom processo; portanto, o que você pode pagar realmente determina a complexidade / elegância de sua solução final.

Como você menciona que seu departamento de TI não tem tempo e equipe para criar um ambiente para você, você (ou melhor, seu departamento / gerente) é capaz de trazer algum financiamento para a mesa? A aquisição de uma pequena quantia de financiamento anual abriria a possibilidade de observar a nuvem. Os provedores de nuvem oferecem tudo o que você precisa, e algumas soluções incluem até as licenças apropriadas, que costuma ser o seu maior custo no que se refere à Oracle. Se você não estiver lançando dados confidenciais nesse ambiente, a nuvem se tornará ainda mais atraente.

Existem todos os tipos de opções de nuvem disponíveis no mercado, mas indicarei as instâncias do Oracle RDS na AWS apenas porque elas oferecem uma opção de licença incluída , e você pode desativá-la quando não estiver em uso para minimizar ainda mais os custos. Pode existir um equivalente em outros provedores de nuvem, mas muitos provedores de nuvem com os quais estou familiarizado exigem que você traga sua própria licença (BYOL) para soluções baseadas em Oracle, em vez de oferecer uma licença inclusiva.

Nota final aqui, uma instância do AWS RDS é APENAS o banco de dados; portanto, qualquer infraestrutura de servidor de aplicativos que você também precise precisa ser contabilizada. A nuvem é uma ótima opção se você precisar de um ambiente rápido para testar a funcionalidade, além de ser uma abordagem econômica; apenas mantenha-se atualizado e desligue tudo para não pagar por servidores inativos.

Geralmente, um ambiente decente seria composto de pelo menos DEV -> TEST -> PRE-PROD -> PROD. O desenvolvimento normalmente teria acesso ao desenvolvimento no DEV, teste de aceitação no TEST e TI para lançamento no PRE e PROD. Se você usar o controle de origem, evitará problemas ao editar o mesmo trecho de código por diferentes desenvolvedores ao mesmo tempo.

Tecnicamente, você só precisa que o esquema seja o mesmo que no prod e não precise de dados de produção abaixo do pré-prod, mas se você estiver de acordo com os dados do prod fora do ambiente do prod, poderá ter uma restauração automática no dev / test. Eu fiz um trabalho semelhante com o Visual Cron e ele faz maravilhas.

Provavelmente, para manter a conformidade, o pessoal de TI precisará liberar alterações no pré e no produto, para tornar isso mais fácil e resistente, você pode seguir o caminho das implantações automatizadas.

Aqui está a minha experiência:

Originalmente, tínhamos um ambiente de desenvolvimento central chamado simserver. Os desenvolvedores testariam as coisas simultaneamente e ficou confuso .

Agora, cada desenvolvedor tem um local no simserverqual eles implantam para teste. Quando eles dizem que está pronto, ele é empurrado para o quality assurance (QA) environment. Temos jiracasos de teste para qualquer coisa que precise ser verificada, além de testarmos as novas adições novamente (temos uma equipe dedicada de controle de qualidade que não faz desenvolvimento; apenas controle de qualidade).

Em seguida, é empurrado ao vivo.

Fazer um local simserveré lógico e fácil. Depois de preparar os VMmodelos, os desenvolvedores apenas os implantam no computador pessoal (sem acesso ao restante da rede - apenas no computador local).