Um pouco de experiência aqui - somos uma pequena equipe (de 5) de desenvolvedores da RAD responsáveis pelo desenvolvimento interno de software em uma grande empresa que não é de software. "Software interno" varia de um aplicativo .NET para desktop que usa o servidor MSSQL como back-end para scripts Python executados em segundo plano para documentos e modelos do MS Word - um zoológico de tecnologias.
Toda a equipe é formada por pessoas versáteis, capazes de obter os requisitos dos usuários, codificá-los, testá-los e implantar na produção. Uma vez que o software em produção está sendo tratado por outra equipe, mas geralmente é fácil intervir se algo der errado.
Tudo parece bom até agora, mas há um problema - sendo uma equipe da RAD que temos que liberar frequentemente, e não há um dia sem lançarmos novas versões de um ou dois aplicativos (ou pode ser um script, documento atualizado do word , Aplicativo de console C ++ etc.) na produção. Fazemos um teste de desenvolvimento e também envolvemos usuários finais, permitindo que eles executem o software no ambiente UAT ...
... mas os bugs estão chegando à produção de qualquer maneira. Os usuários entendem que esses bugs e a instabilidade ocasional são o preço que estão pagando para obter o que desejam rapidamente, mas, ao mesmo tempo, nos fez pensar - talvez possamos melhorar nosso desenvolvimento ou práticas de lançamento para melhorar a estabilidade do software e reduza o número de erros que apresentamos ao adicionar uma nova funcionalidade.
A coisa boa - nós realmente não temos muitos processos em primeiro lugar, por isso deve ser fácil começar a melhorar, a coisa ruim - sendo uma equipe pequena da RAD, não temos muito tempo e recursos para implementar algo grande, mas estivemos pensando nas seguintes iniciativas e gostaríamos de receber comentários, dicas, sugestões e sugestões.
Atualmente, alguns dos aplicativos estão sendo lançados na produção logo após o teste do desenvolvedor, ignorando o teste de aceitação do usuário. Essa prática deve ser descontinuada e até uma pequena alteração deve ser testada por um usuário final. Cada aplicativo terá um beta-tester dedicado selecionado entre os usuários finais. Somente após a aprovação do novo beta-tester, o novo release é promovido do ambiente de teste para a produção.
Não realizamos revisões de código - mas começaremos a fazer revisões de código antes que um de nós faça check-in no conjunto de alterações. Eu também estava pensando em uma "revisão de lançamento" - basicamente um dos desenvolvedores tem que se sentar ao lado do outro, observando-o fazendo o lançamento do software (copiar binários, atualizar configurações, adicionar nova tabela ao banco de dados etc.) - geralmente apenas demora de 5 a 10 minutos para não demorar muito tempo na "revisão de lançamento".
Como diminuir o tempo de reversão quando uma nova versão é comprovadamente buggy o suficiente para sair da produção e ser substituída por uma boa versão anterior. Armazenamos um histórico de todos os lançamentos (como binários) para facilitar a volta de uma versão - e, embora seja rápido "sobrescrever binários recém-lançados com binários de versões anteriores", ainda é um processo manual suscetível a erros e exigente às vezes "e se a reversão falhar e tornar o sistema inutilizável em vez de com erros".
É aqui que ficamos sem nossas idéias e gostaríamos de receber seu feedback sobre elas e se você pudesse compartilhar alguns conselhos simples de aprimoramento do processo de liberação / desenvolvimento - isso seria incrível.