Nossa empresa contratou um engenheiro de lançamento em tempo integral para o lado do MS Windows e estávamos pensando em um processo de gerenciamento de lançamento para o MS SQL Server.
SE tivermos confiança em suas habilidades para implantar scripts do SQL Server, é comum apenas o gerente de liberação fazer isso ou é algo que os DBAs normalmente fazem? Nossa empresa está crescendo rapidamente e nossos DBA's estão um tanto sobrecarregados (surpresa, surpresa, o que mais há de novo), mas podemos contratar mais, mas isso é outro assunto.
Como vocês administram isso? Você permite que um gerente de lançamento tenha acesso ao produto para implementar as alterações? Você tira os direitos e os ativa quando precisam ser liberados? Estou pensando em dar a eles acesso a um sproc que lhes dá acesso prod por uma hora, mas registra quem o chama.
Ou estou totalmente errado e isso é algo que um DBA sempre deve gerenciar?
Qualquer pensamento seria apreciado!
Editar:
Atualização: Além disso, o que acontece quando encontramos anomalias? Por exemplo, um desenvolvedor declarou que 'essas tabelas devem corresponder a esse outro ambiente (por ambiente, quero dizer ambiente de produção do cliente, não qa/stage/etc.)'. Normalmente eles fariam uma verificação no local. Fiz uma soma de verificação e notei problemas que acabaram sendo apenas problemas de espaço em branco. Em um caso como este, nós o enviamos de volta para o gerente de liberação/pessoa de controle de qualidade para consertar depois de fazer a solução de problemas básica?
Outro exemplo : temos scripts de cerca de 20 desenvolvedores, às vezes eles dependem uns dos outros. A ordem do roteiro estava errada. Não consigo acompanhar o trabalho de 20 desenvolvedores e também gerenciar os dados, mas após algumas soluções de problemas, descobrimos o problema e alteramos a ordem. Isso é algo em que o DBA normalmente deve estar profundamente envolvido ou é justo após o teste básico e examinar, enviamos de volta ao gerente de lançamento e aos desenvolvedores para consertar?
Em primeiro lugar, cada ambiente é diferente. O que funciona no meu ambiente não funcionará automaticamente no seu. (Nós = Equipe DBA)
No meu temos os seguintes ambientes para esse processo
Dev - Normalmente, restauramos uma cópia do live em preparação para um lançamento e limpamos os dados conforme necessário. Em seguida, fazemos o backup e permitimos que o desenvolvedor restaure esse backup à vontade. Em seguida, eles preparam e testam seus scripts de implantação. Esperamos que os desenvolvedores tenham testado o processo de atualização/lançamento com sucesso antes que ele precise ir para o UAT. Frequentemente seremos solicitados a ajudar e aconselhar nesta fase
UAT - Novamente, restauraríamos a cópia do live e higienizaríamos (se formos usar um ambiente de controle de qualidade). O gerenciador de versão e configuração nos fornece os scripts corretos para a atualização dos desenvolvedores e iremos verificá-los, executá-los durante o monitoramento para poder fornecer todas as informações necessárias para o CAB em relação à perda de serviço, tempo de atualização e quaisquer alterações necessárias a scripts de manutenção/monitoramento que então aconselhamos ao Gerente de Liberação.
Às vezes, usamos um ambiente de controle de qualidade, geralmente quando dados sanitizados foram usados nos dois ambientes acima e a empresa precisa fazer o controle de qualidade em vez da equipe de teste.
CAB - O Release Manager fornece todas as informações para que o CAB tome sua decisão a partir das etapas do procedimento para definir exatamente o que acontece durante o lançamento. Eles também são responsáveis por armazenar os scripts usados para ir de Dev para UAT e fornecê-los a nós para lançamento ao vivo. Usamos apenas os scripts fornecidos pelo Release Manager e referenciados no CRP. Obviamente, verificamos se os scripts são os mesmos que usamos no UAT, pois sou extremamente cauteloso
Ao Vivo - Implantamos ao vivo seguindo exatamente as etapas do Plano de Liberação de Mudança autorizado pelo CAB, muitas vezes em coordenação com outras equipes
A razão pela qual fazemos isso é em parte porque é o processo que temos que seguir aqui (usando CAB etc), mas em resposta à sua pergunta é porque a equipe DBA é a responsável pela segurança e acessibilidade dos dados. Também porque temos as habilidades, conhecimento e experiência para nos recuperarmos de problemas inesperados. O que acontece com os bancos de dados Live é nossa responsabilidade e levamos isso muito a sério. Ninguém mais tem permissão para executar tarefas nos bancos de dados ao vivo além da equipe de DBA. Nós somos os guardiões e os seguranças (homens/mulheres da porta)
Para sua atualização. Eu devolvo esse tipo de problema aos desenvolvedores e exijo que eles o corrijam antes de implantar no UAT. Assim que o script for finalizado (no UAT), sabemos que funcionará ao vivo.
Para o seu outro exemplo - Esse é o trabalho do gerente de liberação. Se eles estão nos fornecendo scripts que falham, nós os devolvemos a eles e exigimos que consertem antes de implantarmos no UAT. NÃO implantaremos no UAT nada que exija modificação ou alteração das instruções fornecidas e nas poucas ocasiões em que isso aconteceu (um desenvolvedor usou a conta do aplicativo para manipular alguns dados depois de executarmos os scripts para permitir que o lançamento passasse pelo UAT) Eu me levanto no CAB e explico isso e explico que não estou feliz em liberar isso para viver sem um teste correto do lançamento. Isso geralmente funciona :-) Sei que sou duro, mas também sou justo.
Eu digo aos gerentes de lançamento e aos desenvolvedores que o processo de passar o lançamento para o UAT é o teste não apenas do lançamento, mas de como o lançamento será executado, portanto seguiremos exatamente os mesmos passos em ambos os exemplos (dev - UAT e Live ) e que, se falhar no UAT, eles voltam para consertar.
espero que ajude