Motivos bons e simples para ter vários ambientes

Ao longo da minha carreira, trabalhei em empresas que tinham uma coleção de ambientes diferentes para diferentes propósitos. Sempre tivemos mais ou menos nosso ambiente de área de trabalho, um ambiente de teste, um ambiente de controle de qualidade, um ambiente de teste e um ambiente de produção. Isso foi válido para servidores / aplicativos e quaisquer fontes de dados que estávamos usando.

Quando comecei na minha empresa atual, descobri que 90% dos aplicativos eram desenvolvidos em um ambiente de desktop com fontes de dados de produção ou diretamente no servidor de produção, dependendo da plataforma. Isso não foi particularmente surpreendente, pois fui contratado em parte para fazer alterações para melhorar o funcionamento da equipe de desenvolvimento, o que ficou claro em meu processo de entrevista. Lentamente, começamos a mudar a filosofia e, em breve, a maioria dos aplicativos poderia ser executada em um ambiente de desktop, teste ou produção. Não demorou muito tempo para aparecer também.

Agora, a maioria dos nossos desenvolvedores vê o benefício dessa metodologia e a defende com atenção. No entanto, temos vários aplicativos herdados que nunca foram migrados. Também temos vários programadores legados que pensam nisso como uma perda de tempo. Infelizmente, recebemos elogios, mas nunca a adesão total da gerência. Conseguimos o que pensávamos ser um compromisso de investir substancialmente nisso há cerca de um ano, mas nada se materializou apesar do considerável planejamento que colocamos nele. Agora estamos descobrindo que precisamos de mais e mais ambientes. Precisamos da ajuda das equipes de administração de servidores / rede para a instalação e da participação das partes interessadas da empresa para apoiar o ciclo de lançamento. Agora estamos em um local em que um projeto pode funcionar o que os desenvolvedores razoáveis ​​considerariam "normalmente"

Eu adoraria apresentar um argumento completo, mas a gerência realmente não tem tempo e interesse em me ouvir até que haja um problema crítico. Não consigo realmente articular os benefícios simplesmente porque sempre me pareceu uma segunda natureza. Fiquei me perguntando se existem razões boas, simples e irrefutáveis ​​para a separação de ambientes que levariam os gerentes sem experiência em desenvolvimento a apoiar essa idéia? . Existem bons recursos / literatura sobre o tema?

A resposta: dinheiro

Eu não me importo qual é o motivo real. O dinheiro DEVE estar na raiz de todo o seu raciocínio, especialmente ao lidar com a gerência.

Se nós dois sentássemos em uma sala por 2 horas, poderíamos encontrar dezenas de razões pelas quais é melhor ter vários ambientes.

Aqui está o problema: se os motivos não são baseados em dinheiro, nenhum deles importa .

Os programadores não são contratados para serem inteligentes. Eles não são contratados para serem criativos. Eles são contratados para aumentar a receita - ganhando dinheiro ou economizando. Se você não está fazendo nenhum desses, é melhor reunir seu currículo.

Ao olhar para esse ponto de vista, a resposta é simples:

Ter apenas um ambiente aumenta o tempo de inatividade e resulta em perda de receita. Vários ambientes nos permitem proteger nossos lucros, oferecendo a nossos usuários um front-end tão confiável e confiável quanto a nossa empresa.

Repita todos os dias.

Existem alguns ótimos comentários abaixo que agregam algum valor real a essa resposta, então vou mencioná-los:

• Karl Bielefeldt teve um grande ponto quando mencionou que a análise de custo / benefício é um fator importante. Um economista pode se referir a ele como o custo de oportunidade de buscar vários ambientes. Embora possa ser surpreendente ouvir, existem cenários em que vários ambientes podem não ser a resposta! Se o site da sua empresa é uma adição muito pequena, o tempo de inatividade inesperado pode realmente ser a maneira mais econômica de fazer negócios. Isso não soa como a posição em que você está, mas vale a pena mencionar.

• O BlairHippo tinha um bom argumento de que você deveria se sentir à vontade para fazê-lo parecer uma catástrofe (e se você perder seus dados, é!). A responsabilidade é uma ótima ferramenta para convencer os gerentes, mas ainda pelo mesmo motivo - os processos são caros. Evitá-los economiza dinheiro.

Como adendo, achei este artigo muito bom. Ele não responde diretamente à sua pergunta, mas permite que você reconheça como os programadores são vistos no gerenciamento, o que, por sua vez, leva a essa resposta. Boa leitura.

Ponto unico de falha

Por não ter um ambiente de desenvolvimento ou armazenamento temporário, você tem um ponto único de falha para esses aplicativos herdados. A gerência ouvirá você se você descrever os aplicativos herdados nesses termos.

Você precisa enviar sua mensagem em bytes de som que faça sentido para eles. Tire o " Programmer Speak " da discussão e substitua-o por " Manager Speak ". Finja também que você tem uma viagem de elevador de 30 segundos para obter seu ponto de vista.

Eu tive uma situação em que meu chefe era um fuzileiro naval de infantaria. Eu ficava dizendo a ele que precisava de ferramentas de software e treinamento em informática para meus fuzileiros navais, a fim de ser mais produtivo. Ele não entendeu. Eu finalmente entrei no escritório dele um dia e disse a ele que as coisas estavam acontecendo.

Eu disse algo para o efeito ... "Se eu estivesse travando uma guerra, estaria usando paus, pedras e galhos de árvores. O que eu preciso são granadas, bazucas e metralhadoras." Ele entendeu a mensagem.

É realmente crítico?

Eu posso entender o desejo de usar ambientes separados. A questão não óbvia é:

É realmente crítico migrar um sistema legado ?

Eu acho que a maioria das pessoas com espírito técnico tende a se concentrar na questão acadêmica de qual caminho é melhor e o que é bom na academia. Nos negócios, o melhor nem sempre vence. Não estou dizendo que isso seja negativo ou comece uma guerra de chamas. Estou afirmando o óbvio, ou o que deveria ser óbvio para aqueles de nós que estão no negócio de software há alguns anos.

Todas as decisões de negócios geralmente são tomadas com base no custo / benefício percebido. Portanto, a pergunta que a empresa provavelmente está perguntando é:

O custo do investimento adicional em sistemas e desenvolvimento em um aplicativo herdado vale o benefício, em vez de colocar o mesmo investimento em outro projeto / produto?

Eu tenho e ainda faço análises regulares de custo-benefício para fazer determinações não apenas na migração / reescrita de software, mas nas decisões do dia-a-dia em que um lead geralmente participa. Passei reescrevendo / migrando software antigo porque tinha vida útil limitada e portanto valor.

Ambientes Separados

Os motivos de negócios para separar ambientes.

• Menos risco em lançamentos e correções de bugs. Prove com números. Quantas vezes o produto falhou e custou a receita do cliente devido a uma versão / bug incorreto.
• Menos risco no desenvolvimento. Acidentalmente afastando o banco de dados dev é diferente de acidentalmente afastando o banco de dados de produção
• A capacidade de separar claramente funções e acesso, ie. melhor segurança. limitar o número de dedos na torta de produção é uma coisa boa
• A capacidade de separar ambientes e as práticas e procedimentos que acompanham esse estilo de desenvolvimento permitem a criação futura de sistemas em nuvem.
• A separação do ambiente deve forçar eficiências nos ambientes de replicação que podem ser úteis tanto na escala programada quanto na dinâmica.

Parece que você já possui todos os argumentos "certos". Em vez disso, você está enfrentando um "arenque vermelho", se quiser. Ou "perseguindo a cenoura"

a gerência realmente não tem tempo e interesse em me ouvir até que haja uma questão crítica

É isso que considero o verdadeiro problema. De acordo com a minha experiência, se uma empresa tem práticas de desenvolvimento abaixo da média, como você descreve. Não é simplesmente uma questão de "não sabíamos melhor". Pelo contrário, é uma compilação de dívida técnica causada por uma equipe de gerência superior que não sabe (se importa?) Com os problemas que apresenta.

Nesses casos, uma boa conversa de ânimo não vai mudar repentinamente as coisas na sua direção. Talvez um trauma grave (falha do produto visível para o cliente e diretamente ligada a práticas inadequadas), mas tenho certeza de técnicos experientes e sensatos antes de tentar a coisa da conversa.

Minha sugestão é sugá-lo e aceitar as coisas como elas são ou procurar uma nova posição.

Quantos grupos de pessoas planejam trabalhar no aplicativo de cada vez? Usuaslly eu vi um ambiente para cada grupo de pessoas. Estes são os desenvolvedores (eles obtêm um ambiente DEV e um ambiente de integração DEV - alguns diriam que não é 100% necessário, diria que varia de acordo com o projeto), dois ambientes de teste (um grupo de testadores fazendo testes muito detalhados, outro para testadores de controle de qualidade de alto nível - geralmente são usuários de negócios reais, não testadores treinados). Geralmente, também existe um ambiente de teste de desempenho isolado (para que você possa testar grandes volumes de dados, simular grandes volumes de usuários, etc ... g).

Por que todos esses ambientes? Portanto, grupos diferentes podem testar recursos diferentes sem pisar nos dedos um do outro. Se desenvolvedores e testadores trabalham no mesmo ambiente, é um pesadelo: um testador pode abrir um defeito em um recurso que está sendo alterado ativamente a cada minuto por um desenvolvedor. Se houver dois níveis de teste, eles podem se concentrar em atividades diferentes e não se preocupar em bagunçar os dados um do outro. Ter um ambiente de desempenho isolado permite executar testes que podem travar a máquina, mas se estiver isolado, nenhum outro testador será afetado.

Quando muitas pessoas tentam fazer muitas coisas diferentes no mesmo ambiente, você acaba perdendo muito tempo enquanto um grupo aguarda a conclusão do teste de outro grupo para que eles possam executar o deles. E isso desperdiça tempo, e o desperdício de tempo pode levar ao desperdício de dinheiro, o que a Stargazer712 apontou que poderia ser o argumento mais forte.

Outro motivo (não tão comum) são os dados: se seu aplicativo tiver dados pessoais sensíveis ou dados de cartão de crédito, você geralmente não poderá colocá-los em ambientes de teste e, geralmente, haverá requisitos de mascaramento para tudo, exceto os ambientes de controle de qualidade e produção.

Você parece ter investido muito esforço em promover uma mudança cultural em seu local de trabalho. Essa é uma grande conquista, pois a mudança é difícil na melhor das hipóteses, mas a mudança cultural não se limita apenas a mudar a mente das pessoas, mas a mudar hábitos, romper preconceitos e, finalmente, a abrir mentes potencialmente fechadas para maiores possibilidades. Portanto, a pergunta a ser feita neste momento é "O que eu perdi?". A resposta fácil é que você pode não ter se envolvido totalmente com o gerenciamento.

Obter a adesão da gerência é fácil, mas ainda mais difícil é obter aceitação. Independentemente dos argumentos sobre dinheiro, etc, a realidade é que você precisa poder influenciar a visão de prioridade da gerência. Seu gerente terá um orçamento e desejará mostrar que o orçamento foi aplicado de maneira sensata e de acordo com os valores e prioridades da empresa. Algumas dessas prioridades serão fiscais, mas outras servirão a outras necessidades. Em alguns casos, isso pode significar unir as mãos de outros gerentes para obter a promoção que seu chefe sempre desejou. Na maioria dos casos, provavelmente será sobre encontrar maneiras de obter mais negócios ou melhorar o relacionamento com parceiros e clientes. Se você não conseguir defender sua argumentação nesses termos, só poderá ir tão longe antes de se encontrar em um impasse.

Minha sugestão é tentar argumentar sobre a produtividade e como isso afeta o orçamento, como outros sugeriram, mas também argumentar em termos das prioridades da sua empresa e como sua produtividade pode impactar diretamente o relacionamento da empresa com outras empresas.

Aqui está um: testabilidade.

Ter um ambiente de teste oferece a liberdade de executar testes em um banco de dados que seria desaconselhável executar em um ambiente de produção.

Você quer mudar a forma como sua organização desenvolve seu software? Esqueça de se preocupar com "razões" para "fazer as coisas de maneira diferente". Os seres humanos não mudam o comportamento por causa de argumentos racionais. Eles mudam por causa de influências psicológicas em seus hábitos.

Então, onde eu vou com isso?

Embora ocasionalmente você possa alterar com êxito o comportamento de uma organização por meio de argumentação, existem outras táticas que funcionam melhor. Esses incluem:

• Suporte de base: encontre UM outro desenvolvedor "legado" que esteja disposto a lhe dar uma chance. Faça parceria com ele e mude como as coisas funcionam. Não anuncie a mudança. Apenas faça a mudança. Se alguém lhe perguntar, basta dizer "Ah, sim, é assim que fazemos agora".

• Assuma a responsabilidade. Ofereça-se para lidar com implantações para o pessoal herdado. Aja como você ama. Eles podem ficar felizes em renunciar a essa responsabilidade. Em seguida, execute-o como quiser.

• Culpe as pessoas certas pelos seus erros. Na próxima vez que um bug de aplicativo herdado for introduzido na produção por causa do seu mecanismo de implantação da idade da pedra, aponte-o. Faça sutilmente ... Não em um email. Da próxima vez que estiver em uma reunião com um gerente, mencione casualmente o exemplo de um motivo pelo qual a implantação foi problemática. "Sim, lembre-se de como estávamos lutando na sexta-feira passada por causa do bug do Foo que Bob entrou em produção? Sim, foi muito esforço desperdiçado!"

• Torne mais fácil fazê-lo da melhor maneira. Veja o iphone, por exemplo. Há um botão nele. (Bem, dois). É MUITO fácil ligar. Torne estúpido o processo de implantação em vários ambientes. Torne tão fácil que todos os gerentes possam fazê-lo!

É mais um problema quando você começa a lidar com sistemas legados ou interconectados, sistemas dos quais a empresa depende para estar funcionando e preciso. É importante porque precisa haver segregação entre os estágios, é a razão pela qual você não DEV no PROD porque ele tem o potencial de causar danos no valor de milhões de dólares em tempo perdido .

Sempre fazemos DEV -> QA -> PROD (ocasionalmente, essas etapas são divididas em partes menores) com hardware idêntico por trás delas. Os dados de produção atuais são sempre enviados de PROD para QA e DEV.

DEV: pretende ser o sandbox de desenvolvimento, onde as coisas são tentadas, iteradas e batidas em qualquer dado nesse ambiente nunca deve ser confiável e é jogado na lixeira regularmente pelos desenvolvedores, simplesmente encontrando maneiras de resolver um problema.

QA: Quando seus desenvolvedores estiverem satisfeitos com o teste de unidade, é hora do grupo de teste chegar lá de olho nele. Eles executam casos de teste, testes de desempenho e encontram bugs. Esses bugs / aprimoramentos são devolvidos ao DEV e o ciclo continua até que todos estejam felizes.

PROD: Depois de chegar a esse estágio, verifique se o código funciona em conjunto com os dados atuais e se os usuários de seu grupo / empresa de controle de qualidade estão satisfeitos com a implementação. Se você fez tudo corretamente, basta atualizar o código e concluir o processo.

Da mesma maneira que você nunca lançaria um produto não testado para os clientes, nunca lançaria código não testado em um ambiente de produção.

Se a empresa não estiver disposta a investir tempo para fazê-lo adequadamente, ela pagará o custo em manutenção de emergência e os erros 10 vezes.

Como um pequeno exemplo: tivemos uma empresa que decidiu fazer uma alteração em um relatório de produção por conta própria. Ninguém sabia que isso mudou até que chegamos para abordar uma variedade de questões por um ou dois anos.

Quando apontamos a irregularidade no relatório, o rosto do diretor financeiro ficou branco, mas eles estavam perdendo US $ 250.000 por trimestre por causa de alguém fazendo uma mudança rápida.

Acontece com mais frequência do que você pensa, se você não pode dar ao luxo de fazê-lo corretamente, então não faça.

O gerenciamento tem uma grande parte por trás do sucesso das empresas de software e dos produtos de software necessários para gerar esses ambientes. Vamos dar um exemplo do seu projeto. Se o seu software for desenvolvido em larga escala, se você não gerenciar os requisitos do seu projeto, o controle do processo, as Construções de Testes, etc., haverá chances de falha. para que exista o gerenciamento de projetos.

Concordo um pouco com a @ Stargazer712 que sua declaração aponta para o Dinheiro é importante, mas verifique a seguinte declaração que recebi do livro de Marc Hamilton sobre Desenvolvimento de Software: Construindo Sistemas Confiáveis ​​(Prentice Hall PTR, 1999, ISBN 0-13-081246- 3) Depois de analisar todos esses fatores; minha opinião sobre sua pergunta é que o ambiente único não oferece economia, ele fará um processo de longo prazo para concluir o projeto / software. Ambientes distribuídos economizarão tempo e receita, conforme aprendi e vi em minha experiência o que aconteceu com as empresas iniciantes de software das quais iniciei minha operadora.

Existem muitos artigos que demonstram que o que importa para o sucesso, confira Organizar para o desenvolvimento bem-sucedido de software

Cada indivíduo em uma organização possui certas habilidades, e essas habilidades são geralmente medidas com base em métricas de desempenho formais ou informais, levando a recompensas (remuneração) como incentivos para desempenho futuro. As pessoas em uma organização estabelecem sua cultura - os padrões e valores de comportamento que geralmente são reconhecidos como adotados.

Um grande conjunto de desenvolvedores de software enfrentará dificuldades e, no final das contas, não alcançará seus objetivos se tiverem que gastar todo o seu tempo lutando contra uma estrutura organizacional inadequada.

Muitas startups de software começam a vida com não mais do que alguns desenvolvedores trabalhando em uma garagem. Não é necessária muita estrutura organizacional neste momento da história da empresa, mas a estrutura organizacional ainda existe. Por exemplo, em 1977, quando Bill Gates e Paul Allen formaram sua parceria e a nomearam oficialmente como Microsoft, a empresa tinha uma estrutura organizacional mínima. Menos de uma dúzia de funcionários trabalhava no primeiro escritório da Microsoft em Albuquerque, Novo México, e todos sabiam quem estava no comando. Não foram necessários gráficos organizacionais complicados para descobrir a estrutura de relatórios de todos. Ao mesmo tempo, todos os funcionários sabiam seu papel na empresa e o que estavam tentando realizar. Isso porque qualquer estrutura organizacional necessária poderia ser comunicada informalmente entre cada um dos funcionários.

Esqueça tempo, dinheiro, testabilidade, qualidade ... e a reputação .

razões boas, simples e irrefutáveis ​​para a separação de ambientes que levariam os gerentes sem experiência em desenvolvimento a apoiar essa idéia.

O Uber recentemente enviou um código para o github que continha senhas para seu ambiente ativo, permitindo que 'hackers' baixassem todos os detalhes de seus clientes. O Uber diz que foi uma violação, todo mundo diz "não coloque as chaves dos seus bloqueios à vista do público. Se os desenvolvedores funcionassem inteiramente em um ambiente de desenvolvimento, eles poderiam ter liberado as chaves do ambiente de desenvolvimento no github, mas isso é inteiramente O fato de os lançamentos de produção terem mostrado o quão ruim é essa idéia de executar dev no ambiente de produção.

Lembre ao seu gerente que os erros acontecem; assim, a maneira de evitar que ele seja rebocado diante do CEO, que está prestes a ser interrogado diante dos jornalistas e rido pelo público de tecnologia, é tomar medidas simples e óbvias para evitar que esses erros sejam catastróficos. uns.

Parece que você tem muitos ambientes diferentes e custa muito tempo às pessoas para configurar um "ambiente".

Você deve ter o menor número de "ambientes" diferentes com os quais possa se safar, mas conseguir clonar muitas cópias por tantos motivos quanto você e a empresa desejarem (usando "ambiente para significar a configuração do sistema)!

Idealmente, as únicas diferenças devem ser:

1. Tamanho (mínimo, recomendado, maior suporte / testado);
2. A preparação e a produção não possuem ferramentas de desenvolvimento
3. A produção é protegida contra a substituição acidental de dados
4. Você pode carregar dados de clientes de demonstração, teste ou [anoymized] com muita facilidade em servidores de desenvolvimento ou teste

ENTÃO, a questão de quanto e que tipo de teste deve ser feito é uma avaliação de negócios de risco / custo e decidida no nível da empresa, porque é o negócio como um todo que sofrerá se falhas significativas chegarem a vários clientes .

Editar mais tarde: Isso me levou a racionalizar minhas convenções de nomenclatura com meus produtos da web (obrigado pela pergunta). Eu decidi por quatro "ambientes", com os testes divididos entre qa (camada única mínima para apenas a funcionalidade de teste) e a preparação (mesma arquitetura da produção, para teste de carga / desempenho / volume).

A única diferença real no provisionamento é a instalação de produção / armazenamento temporário em um sistema separado, que eu controlo por quais grupos os diferentes servidores estão. Qa / dev tem as funções de servidor da Web e db. O balanceamento de carga é feito pelo cloudflare.

Eu também tenho uma variável ENV_NO, que é passada para os sistemas, para que eu possa optar por ter tantos exemplos de "qa" ou "teste" como eu escolher.

Portanto, para configurar um segundo ambiente de qa, incluindo meu último backup do live, os comandos seriam:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

Por fim, tenho um servidor extra (opcional) chamado "somente leitura" como a última rede de segurança antes de atingir o solo. Ele é provisionado como um sistema qa, mas com o backup e a atualização da noite anterior desativados (o software também é atualizado para a noite passada).

Ele usa a abordagem "Todos os ovos em uma cesta diferente": é fornecido com um local / registrador DNS diferente, host DNS, provedor de serviços de host do sistema. Esta é a última / última rede de segurança; portanto, se tudo tiver pegado fogo, você poderá pelo menos acessar os dados até a noite passada. Os scripts de provisionamento isolam a diferença entre os diferentes provedores; portanto, 99% é o mesmo, apenas o sinalizador somente leitura. O balanceador de carga do Cloudflare redirecionará o tráfego para o site somente leitura se todos os servidores ativos falharem.

Quando se trata de fazer uma alteração, você terá sorte de ter alguém que apenas ouvirá sua opinião profissional e implementará as alterações sugeridas.

De acordo com minha experiência, toda vez que tive que fazer uma grande mudança, tive que justificá-la em termos de economia que os negócios gerariam. Por exemplo, a introdução do ReSharper no pipeline de desenvolvimento foi bastante fácil, pois eu pude dizer algo fora do assunto:

O ReSharper custa em torno de £ 50 por desenvolvedor. O custo médio do desenvolvedor por ano é de £ 40k. O ReSharper deve aumentar a produtividade dos desenvolvedores em pelo menos 20%, dado que é utilizado em todo o seu potencial. Digamos que o desenvolvedor gaste 75% do tempo escrevendo código no IDE. 75% de 40k é £ 30k. £ 30k agora é o custo da produtividade do desenvolvedor. Uma porcentagem adicional de produtividade (1%) por ano custa £ 300. Para obter 20% de produtividade adicional, a empresa teria que gastar £ 6k.

Se você colocar isso em perspectiva com os negócios, pode dizer que pode contratar outra pessoa e obter 20% de produtividade adicional por £ 6k, ou pode obter o mesmo resultado gastando £ 50 em uma licença ReSharper. Quando os números estiverem na frente dos negócios, será fácil tomar uma decisão.

Agora, no que diz respeito às suas perguntas sobre a existência de vários ambientes, tudo o que você precisa fazer é encontrar uma maneira de calcular quanto custa aos negócios todos os anos agora ter esses ambientes.

Você pode pedir a seus colegas desenvolvedores que acompanhem as horas gastas semanalmente na configuração de aplicativos para desenvolvimento, implantação etc. Por exemplo, dez horas do tempo de desenvolvedor sênior podem custar 500 libras aos negócios. São 10 horas que podem ser gastas em desenvolvimento, ou algo muito mais importante. Você reúne os números por algum período e fornece aos negócios um custo anual.

Eu pessoalmente odeio esse tipo de política, mas é comum e temos que conviver com isso.