Os desenvolvedores devem fazer seus próprios lançamentos de software (se houver uma equipe de suporte a produtos)?

5

Eu sei que sempre haverá diferenças dependendo do tamanho, da equipe, etc., mas eu gostaria de receber comentários em geral sobre:

Em um ambiente onde você tem uma equipe de suporte de produção que faz o suporte de primeira linha e o gerenciamento de versões, é melhor simplesmente fazer com que os desenvolvedores gerenciem seus próprios lançamentos? Neste caso, seu software interno em uma companhia de seguros, mas a questão deve ser válida em qualquer empresa, tamanho, etc. Eu acho.

Atualmente, temos nossa equipe de produção fazendo lançamentos, mas há um argumento de que é ineficiente e, se você permitir que os desenvolvedores façam isso, eles se concentrarão mais em torná-lo simples e eficiente e evitarão basicamente passar scripts, etc. para concorrer a outra equipe.

O argumento contrário é que, se você não tiver um teste e equilíbrio, você pode obter uma equipe de software (ou um indivíduo) que não faz um trabalho muito hacky sobre como obter seu software (fazer alterações dinâmicas). , não documentando o processo, etc) e que forçando a equipe de suporte a fazer a liberação real, ela reforça a consistência e as verificações e balanços adequados.

Eu sei que isso não é um problema de preto ou branco, mas eu queria ver o que as pessoas pensavam sobre isso, então a disciplina e consistência estão lá, mas sem a sensação de que um processo ineficiente está em vigor.

    
por leora 26.11.2011 / 01:38
fonte

4 respostas

3

Existem várias razões pelas quais os desenvolvedores não devem fazer lançamentos de produção. Isso é ainda mais importante quando você tem uma equipe de suporte de produção que precisa gerenciar o código após o lançamento.

Tenho uma vasta experiência em pequenas organizações e equipes sem equipes de suporte de produção. Mesmo nessas organizações, os lançamentos eram feitos como se tivéssemos uma equipe de suporte de produção. Minhas experiências apoiando os aplicativos, bem como desenvolvendo-os, levam-me a respeitar os dois papéis e seus diferentes requisitos.

Entre os motivos para a transferência para o suporte à produção:

  • Correções podem ser feitas diretamente na produção e perdidas quando o próximo lançamento for lançado. (Acabei de violar esta regra para uma correção de configuração de uma linha durante uma versão de produção de fim de semana. Mas uma aposta maior foi feita no código base na segunda-feira. Uma correção maior foi dos desenvolvedores para o teste de integração e depois para a produção .)
  • A configuração do ambiente pode ser incluída no código. Isso resulta em compilações de desenvolvimento, compilações de testes de integração e construções de produção. Às vezes, alterações não configuradas ou não testadas são incluídas na compilação de produção.
  • Suporte à produção obtém construções que não sabem como executar. Isso parece ótimo para o desenvolvedor indispensável que precisa fazer todas as reinicializações, mas não é bom para a empresa.
  • O código de produção e desenvolvimento de uma versão pode se tornar cada vez mais diferente. (Certa vez, cometi o erro de comparar uma base de código de desenvolvimento que deveria ser idêntica ao código de produção. Alguns arquivos eram os mesmos.)
  • O código liberado é empacotado e configurado de maneira mais adequada para o desenvolvimento do que a produção. A equipe de produção provavelmente incentivará ou exigirá recursos de configuração e empacotamento adequados.
  • Liberações de código podem não ser marcadas no controle de versão. Versões construídas para hand-off precisam ser rastreadas. Isso pode não necessariamente acontecer, mas é menos provável que seja ignorado ou ignorado se o código estiver sendo "liberado" para testes ou produção de integração.
  • Micro-lançamentos são possíveis. Isso faz do suporte um pesadelo. (Ele foi quebrado às 2:00, mas pode ter sido corrigido no release 2:15 ou 3:05).

EDIT: A equipe de suporte à produção é uma das partes interessadas no lançamento. Ajuda se a equipe de desenvolvimento trabalhar com a equipe de suporte de produção para torná-lo bem-sucedido. Separe a configuração específica do ambiente para que possam ser mantidos adequadamente. Geralmente, é apropriado que a equipe de suporte de produção mantenha a configuração do ambiente.

    
por 26.11.2011 / 04:24
fonte
1

Acredito firmemente que os desenvolvedores devem fazer todas as coisas necessárias para liberar seu código. O maior problema com a delegação de responsabilidade é que isso cria muita desconfiança entre equipes que recebem muitos hits e equipes que fazem o trabalho. Esta desconfiança e fricção faz com que ambas as equipes concentrem seus esforços e energia em atividades de combate a incêndios e ataques com dedos.

Se a ideia é que sua equipe desenvolva um código valioso que funcione bem em um ambiente de produção, o maior valor vem do que o desenvolvedor aprenderá fazendo todas as atividades sozinho. Se ele não enfrentar a questão, ele vai ver todos os combates de outras equipes como um obstáculo ao invés de aprender. Quando ele vê como obstáculo, ele simplesmente não aprende, mas tenta se concentrar em como fazer as coisas não detectadas pelas outras equipes.

Se eu fosse a empresa com dinheiro para pagar equipes especializadas e exigir zero falhas. Eu colocaria em prática algumas equipes de especialistas vagamente definidas (não obrigatórias) e deixaria o desenvolvedor escolher se ele queria que seu trabalho fosse analisado por elas. Se o lançamento falhar, o desenvolvedor sabe o que ele fez de errado e como ele pode evitá-lo. À medida que cresce na escala técnica, ele pode querer passar para as equipes de especialistas.

Devido à pressão dos colegas, as pessoas terão seus trabalhos revisados pelas equipes de especialistas. E também criará uma melhor relação entre equipes de especialistas e desenvolvedores, na verdade, levando a um trabalho melhor.

    
por 26.11.2011 / 04:31
fonte
0

Atualmente, estou trabalhando em uma pequena empresa (são apenas 4), portanto, temos que fazer todo o trabalho (começando com as entrevistas com o cliente para buscar informações sobre recursos, criando documentos de especificação e implantação do produto final).

Foi um caos a princípio, mas quando começamos a nos acostumar a realizar várias tarefas, percebemos que, se você definir fluxos de trabalho e padronizá-los, todos devem poder fazer parte do processo sem saber o que o outro fez. .

Outra lição que aprendemos é: É sempre bom saber algo sobre cada parte do sistema. Eu não quero dizer como isso é implementado, mas sim o que ele faz. É realmente útil ao criar lançamentos (como o problema que você mencionou) porque o desenvolvedor fazendo o lançamento, embora não tenha escrito esse código, sabe o que é para.

Então, para resumir: Desenvolvedores devem se desenvolver para resolver um problema. Releasers (acho que acabei de inventar isso) deveriam pensar na melhor maneira de liberar uma certa solução. Se você pensar em lançar durante o desenvolvimento, seu código não será tão limpo e poderá gerar problemas no futuro.

    
por 26.11.2011 / 04:01
fonte
0

Você pode tentar instalar um processo de integração contínua (veja aqui link ). Dessa forma, você tem sempre e a cada dia um novo candidato a lançamento em mãos. Isso não significa que cada um desses lançamentos seja realmente entregue aos usuários, a decisão ainda é da equipe de produção que versão ou marco eles entregam. A parte importante é que você obtém as responsabilidades certas entre a equipe de desenvolvedores e a equipe de produção.

Por outro lado, sua equipe de desenvolvimento será forçada a aprender como desenvolver em iterações menores, onde cada iteração é um incremento totalmente documentado e testado internamente. Talvez isso ajude você a trabalhar de forma mais eficiente em ambos os lados.

    
por 26.11.2011 / 10:36
fonte