Um DB por desenvolvedor ou não?

https://stackoverflow.com/questions/234580

04-07-2019
|

Pergunta

Em um ambiente de desenvolvimento corporativo escrevendo software administrativo na sua maioria, devem todos os desenvolvedores usar a sua própria instância de banco de dados, ou devem usar uma instância de banco de dados central durante o desenvolvimento? Quais são as vantagens e desvantagens de cada abordagem? E quanto a outros ambientes e outros produtos?

Solução

Se você compartilhar o mesmo banco de dados, você pode ter alguns problemas se alguém fazer uma mudança estrutura para o banco de dados e que o código não é "sincronizado" com ele.

Eu recomendo altamente um DB por desenvolvedor para a única razão que você não quer fazer teste "write" para ver alguém substituir-lhe logo depois. A exemple simples? Você tenta exibir produto para um site. Tudo funciona até que todos os produtos desaparecem. Problema? Outro desenvolvedor decidiu jogar com a bandeira "ativa" do produto de teste de outra coisa. Em casos como este, uma transação pode até não funcionar. Fim da história, você gasta tempo de depuração para alguém ação mais.

Eu recomendo replicar o banco de dados de preparo para o banco de dados desenvolvedor de vez em quando para sincronizar a estrutura (ou melhor, ter uma ferramenta para reconstruir um banco de dados a partir do zero).

É claro, precisamos de roteiros para alterações para o banco de dados e tudo está em um controle de origem.

Outras dicas

Os dias em ambientes de banco de dados deve ser escasso estão muito longe. Estou escrevendo esta postagem em um xw9300 com 5x15k discos SCSI na mesma. Esta máquina irá executar um trabalho ETL substancial em um comprimento bastante razoável de tempo e (em meados de 2007) me custar cerca de £ 1.700 no eBay, incluindo os discos. Da perspectiva de um desenvolvedor, especialmente em projetos centrados banco de dados como armazenamento de dados, a linha entre um desenvolvedor e um DBA é bastante turva. Enquanto escrevo isto, estou a construção de uma estrutura de gerenciamento de partição para um armazém de dados SQL Server 2005.

Os desenvolvedores devem ter um ou mais bancos de dados de desenvolvimento de seus próprios para (IMO) estas razões:

Requer as pessoas a manter procedimentos armazenados, scripts de patch e arquivos de definição de esquema no controle de origem. Aplicando os patches pode ser automatizado para um bastante grande medida. Há ainda ferramentas como Redgate SQL Compare Pro que fazer muito do trabalho pesado para isso.
Incentiva uma arquitetura de aplicação que facilita o gerenciamento de configuração fácil e implantação, como as pessoas têm para implantar em suas próprias estações de trabalho. Muitas rugas implantação vai ficar resolvido muito tempo antes que eles atinjam a produção ou as pessoas sequer percebem que poderia ter errado ido.
desenvolvedores Evita tropeçar no trabalho um do outro. Em algo como um armazém de dados, onde as pessoas estão trabalhando com código ETL esta é uma vitória ainda maior.
Ele estimula um grau de responsabilidade como os desenvolvedores têm de aprender a administração básica do banco de dados. Isso também elimina muitos dos requisitos para pessoal de apoio operacional e alguns dos dev-vs. ops atrito.
Se você tem seu próprio banco de dados, não há porteiros obstruindo a experimentação ou outro trabalho sobre ela. A política em torno gestão 'servidores' desaparecer à medida que não há 'servidores'. Esta é uma vitória produtividade em uma qualquer ambiente com a burocracia Compete significativa.
Para volumes de dados pequenos um PC comum é rápido o suficiente para isso. Developer Edition ou licenciamento estão disponíveis para a maioria, se não todos os sistemas de gerenciamento de banco de dados e será executado em um desktop O / S. Se você está trabalhando com Linux ou Unix isso é ainda menos de um problema. Para volumes maiores de dados, até e inclusive a maioria das aplicações MIS, uma estação de trabalho como um HP xw9400 ou Lenovo D10 pode ser equipado com 5 discos de 15k por menos do que o custo de um monte de profissional desenvolvimento ferramental . (Sim, eu sei que é licença dupla, mas uma licença all-plataforma comercial para QT é cerca de £ 4000 um assento). Uma máquina como esta será executado um processo de ETL com 10 de para 100 dos milhões de linhas mais rápido do que você imagina.
Ele facilita a criação de mais de um ambiente para fins de teste de fumaça ou de reconciliação. Como você tem controle total sobre a máquina, você tem um monte de espaço para zombar-se as condições em um ambiente de produção. Por exemplo, uma vez eu fiz um emulador simples para Control-M por apenas bodging algunsde seus scripts de tempo de execução. Onde você tem esse nível de controle e transparência sobre o ambiente que você pode produzir um processo de implantação bastante robusta testado que faz bastante para eliminar oportunidades para apontar o dedo na implantação de produção.

Eu vi pequenas equipes que trabalham com 14 ambientes, e teve 7 ativo em uma estação de trabalho ao mesmo tempo. No banco de dados de trabalho pesado, como ETL, onde você está com com mesas inteiras, trabalhando em um único ambiente dev é uma receita para o desperdício de tempo ou gastar o seu tempo andando em cascas de ovos.

Além disso, você pode usar licenças de desenvolvimento único usuário para plataformas de banco de dados, que você pode economizar o custo das estações de trabalho apenas no licenciamento de banco de dados. A maioria das licenças de desenvolvedor (Microsoft e OTN são um par de exemplos que eu estou familiarizado com) permitirá que você use o sistema em uma única estação de trabalho para um único desenvolvedor gratuitamente ou a um preço nominal.

Por outro lado, termos de licenciamento em servidores de desenvolvimento compartilhados são muitas vezes um pouco turva e eu vi vendedores tentar agitar clientes para baixo para o licenciamento em servidores dev em mais de uma ocasião.

Cada um dos nossos desenvolvedores tem um banco de dados totalmente funcional. Alterações são script e fonte controlada como qualquer outro código.

Idealmente, sim, cada desenvolvedor deve ter uma "sandbox" ambiente de desenvolvimento, para que eles possam testar seu código, mesmo antes de implantá-lo a um teste de ambiente compartilhado / encenação.

ambiente de cada desenvolvedor deve executar testes que redefinir o banco de dados para um estado conhecido script. Isso é impossível de se fazer em um ambiente compartilhado.

O custo de dar a cada colaborador a sua própria instância é menor do que o custo do caos resultante de vários desenvolvedores que tentam testar mudanças voláteis juntos em um ambiente compartilhado.

Por outro lado, em muitas lojas de TI o sistema usa infra-estrutura complexa, que envolve vários servidores de aplicativos ou vários nós físicos. Então a economia mudar; é menos caro para as pessoas a cooperar e evitar pisar em trabalho um do outro do que seria de se replicar isso para cada desenvolvedor. Especialmente verdadeiro se você integrar sistemas de terceiros caros que não dão a você licencia para vários ambientes de desenvolvimento.

Portanto, a resposta é sim e não. :-) Do dar a cada colaborador seu próprio ambiente se que o ambiente pode ser reproduzido barata.

A minha recomendação é ter 2 níveis de ambiente de desenvolvimento:

Cada desenvolvedor tem seu próprio sistema de desenvolvimento pessoal, com testes que inicializar seu banco de dados e sistemas para um estado conhecido seu próprio dp, servidores web, etc. Isto permite-lhes código contra uma configuração conhecida, escrita automática (nível de sistema), etc.

O ambiente de integração de desenvolvimento é compartilhada por todos os desenvolvedores e usado para se certificar que tudo está trabalhando em conjunto como esperado antes de entregá-lo para QA. Código é verificado para fora do controle de origem e instalado lá, e há apenas uma única instância de quaisquer servidores (db ou não).

Esta questão insinua que um desenvolvedor precisa para fazer a sua / seu trabalho. Certamente uma instância DB privado deve ser fornecido. Igualmente importante, gostaria de ter certeza de que o DB é o mesmo produto / versão, como o que você pretende implantar. Não se desenvolvem no MySQL 6.xe deploy para MySQL 5.x (Isso vale para os servidores de aplicativos e servidores web, bem!)

Ter um desenvolvedor DB não necessariamente ean você precisar dele hospedado em sua máquina local. Você poderia ter uma máquina host DBMS central com todos os dbs dev nela localizados. Os prós são o garauntee que você desenvolva contra o alvo DB. Menos sobrecarga no dev caixas, mais espaço / potência para IDEs musculosos e servidores de aplicativos. Os contras são ponto único de falha para todos os devs. (O servidor DBMS desce ninguém pode trabalhar.) Falta de exposição dev para configurar e administrar os DBMS. Devs não pode experimentar a mesma facilidade com os próximos lançamentos DB ou escolhas DB alternativas para resolver problemas difíceis.

Alguns dos prós pode ser contras e vice-versa, dependendo da sua organização e estrutura. Talvez você não quer devs que administram os DBMS. Talvez você faz plano para apoiar variando plataformas DB. A decisão se resume a sua organização, bem como suas escolhas plataforma de destino. Se você pretende atingir uma variedade de combinações DB / OS / servidor aplicativo, em seguida, cada dev não só deve ter sua própria DB mas deve funcionar em uma combinação única. (MySQL / Tomcat / OSX para um DB2 / Jetty / Linux por mais Postegres / Geronimo / WinXP para um terceiro, etc.) Se você configurar um tipo de loja de ASP (Application Service Provider) em um iSeries, por outro lado, então é claro que você vai provavelmente ter uma máquina central com todos DBMSes dev ainda cada dev deve ter pelo menos uma instância db separado para permitir mudanças estruturais esquema.

Eu tenho uma instância de SQLServer Development Edition instalado localmente. Temos um servidor QA DB, bem como vários servidores de produção. Todos os testes de desenvolvimento e integração é feito usando o meu servidor local (ou outros desenvolvedores de servidores locais). Novos lançamentos são encenadas ao servidor de QA. Cada versão, após a aceitação pelo cliente, é colocado em produção.

Desde que eu principalmente fazer o desenvolvimento web, eu uso o servidor web empacotados com VS2008 para o desenvolvimento e teste local, em seguida, publicar o aplicativo web para um servidor QA web hospedado em um VM. Uma vez aceite pelo cliente, é publicado a um dos vários servidores diferentes de produção web -. Algum virtual, outros não, dependendo da aplicação

O meu departamento na minha empresa só tem ambientes de desenvolvimento limitadas, puramente por causa do custo de apoio e hardware. Nós temos um par de ambientes que são baseados em t-1 refresca noturnas de produção, e algumas estáticas.

O ideal é que todos devem ter o seu próprio, mas em muitos casos, isso vai ser impraticável quando o seguinte forem verdadeiras:

você tem um grande número de desenvolvedores que precisam de recursos (o nosso departamento tem talvez 80)
cada desenvolvedor precisa de vários recursos (normalmente eu uso 4-5 dbs diferentes cada dia)
dados atualizados é importante (você só não pode atualizá-los rápido o suficiente)

Nestes casos, as instâncias compartilhadas e boa comunicação são o que é necessário.

Uma vantagem de um banco de dados por desenvolvedor, cada desenvolvedor tem um instantâneo de seus próprios dados em um estado "conhecido".

Eu gosto da idéia de usar uma versão local quando um desenvolvedor deve ser isolado - o desenvolvimento de uma alteração de esquema, testes de desempenho, criação de cenários específicos, etc ...

Em outros momentos, usar a versão compartilhada como para garantir que tudo está em sincronia com os outros.

Eu acho que há um problema de terminologia aqui. Tem sido um tempo desde que eu usei meu chapéu DBA (Golly Gee, quase 10 anos.) - para que outra pessoa carrilhão de lata e me corrigir

Eu acho que todos estão de acordo que cada desenvolvedor deve ter o seu próprio conjunto de esquema sandbox.

No MySQL e Sybase / MS SQLServer, cada motor de banco de dados pode suportar múltiplos bancos de dados. Cada base de dados é (normalmente) totalmente independente da outra base de dados. Então você pode ter uma instância de banco de dados, e dar a cada colaborador o seu espaço de banco de dados para fazer o que quiser. o único problema é se os desenvolvedores estão usando tempdb - não pode haver colisões lá (eu acho - isso você vai precisar de olhar para cima). Basta ter cuidado que as consultas entre bancos de dados com nomes de banco de dados fixas não são utilizados.

Na Oracle, a instância de banco de dados está vinculado a um conjunto determinado esquema. Se você tiver vários desenvolvedores sobre o mesmo motor, eles estão todos apontando para as mesmas tabelas. Neste caso, sim, você terá que executar várias instâncias.

Cada um dos nossos desenvolvedores tem um banco de dados local. Nós armazenar o script e um despejo dos "dados padrão" em nosso repo SVN criar. Temos um extenso conjunto de testes que devem passam por esses dados de teste. Nós também temos um banco de dados "sandbox" que está disponível para as pessoas a colocar os dados em que eles querem compartilhada para os dados padrão. Isso funciona bem para nós e nos permite que desenvolvedores modificar suas cópias locais de dados para testar as coisas, mas nós controlar o que é passado para outros desenvolvedores. Nós também controlar rigorosamente as mudanças de esquema, de modo que não encontrar os problemas que alguém mencionou.

Ela realmente depende da natureza da sua aplicação. Se o seu caso é uma arquitetura cliente-servidor em um ambiente distribuído, o melhor é ter um banco de dados central que usa todos. Se o produto oferece aos usuários um ambiente com instâncias de banco de dados locais, você pode usar isso. É melhor se seus espelhos de desenvolvimento do ambiente do mundo real, tanto quanto possível.

Também é dependente do que estágio de desenvolvimento em que está. Provavelmente nos estágios iniciais, você não quer ficar atolados por conectividade, rede e questões de ambiente distribuído e só quero ser instalado e funcionando. Em tal caso, um, você pode começar com um modelo de banco de dados instância por usuário antes de mudar para o modelo central como o produto atinge um certo nível de maturidade.

Na minha empresa temos a tendência de copiar todo o DB quando se trabalha em novos recursos não-triviais. O raciocínio há espaço em disco é barato, enquanto perda acidental de dados (mesmo que de dados de teste) não é.

Eu trabalhei em ambos os tipos de ambientes de desenvolvimento. Pessoalmente, eu prefiro ter meu próprio servidor DB / app. No entanto, pode haver algumas vantagens de se utilizar uma infra-estrutura compartilhada para o desenvolvimento.

A principal delas é que um ambiente compartilhado mais se assemelha a um cenário do mundo real: você é mais propensos a problemas desvendar com bloqueio ou transações quando todos os desenvolvedores compartilham um DB. Dando a cada desenvolvedor sua própria DB pode levar a "funciona no meu DB" síndrome.

No entanto, se você precisa aplicar e alterações de esquema de teste ou otimizações, então eu posso ver problemas neste tipo de set-up.

Talvez uma solução de compromisso que funcionam melhor: toda infra-estrutura desenvolvedores share, e se alguém precisa de alterações de esquema de teste, eles criam a sua própria instância DB temporário (? Talvez haja uma apenas sentado ali para essa finalidade) até que eles estão felizes de comprometer o novo esquema de controle de origem.

Você tem todo o seu esquema (e dados de teste) no controle de origem, certo? Direito ???

Eu gosto da solução de compromisso (todos os desenvolvedores de compartilhar infra-estrutura, e se alguém precisa de alterações de esquema de teste, eles criam a sua própria instância DB temporário (talvez haja uma apenas sentado ali para essa finalidade?) Até que eles estão felizes para cometer o novo esquema de controle de origem.)

Um DB por desenvolvedor. Nenhuma pergunta. Mas a questão realmente é a forma de bases de dados de script inteiro "os dados de controle", ea versão deles. Minha solução é aqui: http://dbsourcetools.codeplex.com/ Diverta-se. -. Nathan

Os esquemas de banco de dados deve ser realizada em controle de origem e os desenvolvedores devem possuir os changesets o check-in para o código e db juntos. Antes do check-in o desenvolvedor deve estar trabalhando em seu próprio banco de dados. Depois de coleira, uma compilação automatizada (por exemplo: na coleira, todas as noites, etc), deve actualizar um db integrado central, juntamente com as próprias aplicações.

A nível exemplo desenvolvedor os dados carregados deverão ser adequadas para o teste de unidade, pelo menos. A nível integrado, a db compartilhada deve conter dados também apropriado para testar, mas não deve confiar em replicação de produção -. Este é apenas um substituto folga para dados de teste gerenciados

Na minha experiência, a única razão que os desenvolvedores optar por um db compartilhada é que eles acreditam que o desenvolvimento e execução em dados de produção recente é de alguma forma 'real' e significa que eles podem colocar menos esforço nos testes. Eles preferem passo em pé de ninguém e colocar-se com um db compartilhada que lentamente corrompe antes da próxima atualização de produção de escrever e gerenciar testes adequados. É este tipo de prática de gestão que dá o mundo da TI a má reputação para entregar que tem atualmente.

Eu sugiro usar uma instância do banco de dados. Você não quer que seu banco de dados para ser um alvo em movimento.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow