Razões boas e simples para ter vários ambientes

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 quando se trata de gerenciamento.

Se nós dois estivéssemos sentados em uma sala por duas horas, poderíamos pensar em dúzias de motivos pelos quais é melhor ter vários ambientes.

Aqui está o problema: se as razões não são baseadas em dinheiro, então nenhuma delas importa .

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

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

Having only one environment increases our downtime and results in lost revenue. Multiple environments allows us to protect our profits by giving our users a front-end that is just as reliable and dependable as our company.

Repita todos os dias.

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

• Karl Bielefeldt teve um grande ponto quando mencionou que a análise Custo / Benefício é um fator importante. Um economista pode se referir a ele como o custo de oportunidade de buscar múltiplos 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 for uma adição muito pequena, o tempo de inatividade inesperado pode 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.

• BlairHippo tinha um bom ponto em que você deveria se sentir livre para fazer parecer uma catástrofe (e se você perder seus dados, é!). Responsabilidade é uma ótima ferramenta para persuadir os gerentes, mas ainda pela mesma razão - ações judiciais são caras. 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 para o gerenciamento, o que, por sua vez, leva a essa resposta. Boa leitura.

Ponto único de falha

Por não ter um ambiente de desenvolvimento ou teste, você tem um Ponto único de falha para esses aplicativos legados. A gerência o ouvirá se você descrever os aplicativos legados nesses termos.

Você precisa lançar sua mensagem em bytes de som que façam sentido para eles. Pegue o " Programmer Speak " fora da discussão e substitua-o por " Manager Speak ". Também fingir que você tem um passeio de elevador de 30 segundo para obter o seu ponto em frente.

Eu tive uma situação em que meu chefe era um fuzileiro 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 em seu escritório um dia e disse a ele que as coisas estavam certas.

Eu disse algo sobre o efeito ... "Se eu estivesse lutando uma guerra, eu 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 pergunta não óbvia é:

É realmente crítico migrar um sistema legado ?

Eu acho que a maioria das pessoas de mentalidade técnica tendem a se concentrar na questão acadêmica de qual é o melhor caminho que é bom na academia. Nos negócios, o melhor nem sempre é vencer. Não estou dizendo que isso seja negativo ou inicie 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. Então a pergunta que o negócio provavelmente está fazendo é:

O custo do investimento adicional no sistema e no desenvolvimento de uma aplicação legada vale o benefício versus colocar esse 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 em migrar / reescrever software, mas em decisões cotidianas em que um lead geralmente se envolve. Eu passei a reescrever / migrar o software antigo porque ele tinha vida limitada e, portanto, valor.

Separando ambientes

O negócio justifica a separação de ambientes.

• Menor risco em liberações e correções de bugs. Prove com números. Quantas vezes o produto falhou e custou a receita do cliente por causa de um bug / bug ruim.
• Menos risco no desenvolvimento. Acidentalmente soprando o db dev é diferente de acidentalmente explodir o db de produção
• A capacidade de separar claramente os papéis e acessar ou seja, 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 construção futura em Cloud Systems.
• A separação do ambiente deve forçar eficiências na replicação de ambientes que podem ser úteis em escalonamento agendado e dinâmico.

Parece que você tem todos os argumentos "certos" já em vigor. Em vez disso, você está experimentando um "red-herring", se você quiser. Ou "perseguindo a cenoura"

management really has no time and interest in hearing me out until there is a critical issue

Isso é o que eu considero ser o problema real. Na minha experiência, se uma empresa tem práticas de desenvolvimento sub-par tão pobres quanto você descreve. Não é simplesmente uma questão de "não sabemos nada melhor". Pelo contrário, é uma compilação de dívida técnica causada por uma equipe de alta gerência que não sabe (se preocupa?) Sobre os problemas que apresenta.

Em tais casos, um bom discurso não vai de repente mudar as coisas em sua direção. Talvez um trauma grave (falha do produto visível para o cliente e diretamente ligado a práticas inadequadas), mas tenho certeza de que técnicos espertos antes de você ter tentado falar sobre isso.

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

Quantos grupos de pessoas planejam trabalhar no aplicativo por vez? Usuasly 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 são 100% necessários, eu diria que varia por projeto), dois ambientes de teste (um grupo de testadores fazendo testes muito detalhados, o outro para Testadores de QA de alto nível - geralmente são usuários de negócios reais, testadores não treinados). Normalmente, há também um ambiente de teste de desempenho isolado (para que você possa testar grandes volumes de dados, simular grandes volumes de usuários, etc.).

Por que todos esses ambientes? Assim, grupos diferentes podem testar diferentes recursos sem pisar nos dedos uns dos outros. Se os desenvolvedores e testadores trabalharem 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 testes, eles podem se concentrar em atividades diferentes e não se preocupar em atrapalhar os dados uns dos outros. Ter um ambiente de desempenho isolado permite que você execute 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 tendo muito tempo perdido enquanto um grupo espera que o teste de outro grupo seja concluído para que eles possam executar o deles. E isso desperdiça tempo, e o desperdício de tempo pode levar a desperdício de dinheiro, o que Stargazer712 apontou poderia dar o arsenal mais strong.

Outro motivo (não tão comum) são os dados: se o aplicativo tiver dados pessoais confidenciais ou dados de cartão de crédito, geralmente não é possível colocá-los em ambientes de teste e geralmente há requisitos de mascaramento para tudo, exceto os ambientes QA e Produção. / p>     

Você parece ter investido um grande esforço em trazer uma mudança cultural em seu local de trabalho. Essa é uma grande conquista já que a mudança é difícil na melhor das hipóteses, mas a mudança cultural não é simplesmente mudar a mente das pessoas, mas mudar hábitos, quebrar preconceitos e, por fim, abrir mentes potencialmente fechadas para possibilidades maiores. Portanto, a pergunta a ser feita nesse ponto é "O que eu senti falta?". A resposta fácil é que você pode não ter se envolvido totalmente com o gerenciamento.

Conseguir o buy-in da gerência é fácil, mas ainda mais difícil é obter aceitação. Independentemente dos argumentos sobre dinheiro, etc, a realidade é que você precisa ser capaz de influenciar a visão de prioridade da administração. 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 serão sobre outras necessidades. Em alguns casos, isso pode significar engraxar as palmas de outros gerentes para obter a promoção que seu chefe sempre quis. Na maioria dos casos, porém, provavelmente será uma maneira de obter mais negócios ou melhorar os relacionamentos com parceiros e clientes. Se você não puder apresentar o seu caso nestes termos, você só poderá ir tão longe antes de se encontrar em um impasse.

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

Aqui está uma: testabilidade.

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

Você quer mudar a maneira como sua organização desenvolve seu software? Esqueça se preocupar com "razões" para "fazer as coisas de maneira diferente". Os 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, para onde estou indo com isso?

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

• Suporte a bases populares: 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 perguntar sobre isso, diga "Ah sim, é assim que fazemos agora".

• Assuma a responsabilidade. Seja voluntário para lidar com implantações para o pessoal legado. Aja como você ama isso. Eles podem ficar felizes em renunciar a essa responsabilidade. Em seguida, execute como quiser.

• Culpe as pessoas certas por seus erros. Na próxima vez que um bug de aplicativo herdado for introduzido na produção devido ao seu mecanismo de implantação de idade avançada, aponte-o para fora. Faça sutilmente ... Não em um email. Da próxima vez que você 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 bichão do Foo que Bob registrou na produção? Sim, isso foi muito esforço desperdiçado!"

• Torne mais fácil fazer isso da melhor maneira. Veja o iphone, por exemplo. Há um botão nele. (Bem, dois). É muito fácil de ligar. Torne fácil a implementação para múltiplos ambientes. Torne tudo tão fácil que todos os gerentes podem fazer isso!

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

Sempre fazemos o 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 para DEV.

DEV: destina-se a ser a caixa de proteção de desenvolvimento, onde as coisas são testadas, iteradas e batidas em qualquer dado deste ambiente nunca deve ser confiável e é regularmente destruído pelos desenvolvedores simplesmente encontrando maneiras de resolver um problema.

QA: Uma vez que seus desenvolvedores estejam satisfeitos com o teste de unidade, é hora de o grupo de teste ver os olhos nele. Eles executam casos de teste, testes de desempenho e encontram bugs. Esses bugs / enchancements são enviados de volta para o DEV e o ciclo continua até que todos estejam felizes.

PROD: Assim que chegar a este estágio, você deve ter certeza de que o código funciona em conjunto com os dados atuais e que o grupo de controle de qualidade / os usuários corporativos estão satisfeitos com a implementação. Se você fez tudo corretamente, você deve simplesmente poder atualizar o código e acabar com isso.

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

Se a empresa não estiver disposta a investir o tempo necessário para fazê-lo corretamente, eles pagarão o custo da manutenção de emergência e os erros serão reduzidos em 10 vezes.

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

Quando apontamos a irregularidade no relatório, o rosto do CFO ficou branco, e eles perderam ~ $ 250.000 por trimestre devido a uma mudança rápida.

Acontece mais frequentemente do que você pensa, se você não puder fazer isso corretamente, então não faça isso.

O gerenciamento tem uma grande parte do sucesso das empresas de software e produtos de software que precisam gerar esses ambientes. Vamos dar um exemplo do seu projeto. Se o seu software é desenvolvido em larga escala, então se você não gerencia seus requisitos de projeto, controle de processo, Test Builds etc, então isso é uma chance de falha. para que o gerenciamento de projetos exista.

I am somewhat agree with @Stargazer712 that your statement point to the Money matters, But Check the following statement that i have gotten from Marc Hamilton's book on Software Development: Building Reliable Systems (Prentice Hall PTR, 1999, ISBN 0-13-081246-3). After looking all of these factors; my Opinion about your question is that Single Environment is not give you savings, it will make a long term process to complete the project/software. Distributed Environments will save Time and revenue as i learned and seen in my experience that what happened with the start-up software companies from which i have start my carrier.

Existem muitos artigos que demonstram o que é importante para o sucesso. Marque esta Organização para o Desenvolvimento de Software de Sucesso

Each individual in an organization has certain skills, and these skills are typically measured against formal or informal performance metrics leading to rewards (compensation) as incentives for future performance. The people in an organization establish its culture—those behavior patterns and values that are generally recognized as being adopted.

Um grande conjunto de desenvolvedores de software terá dificuldades e, em última análise, não conseguirá atingir seus objetivos se tiver 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 nesse ponto da história de uma 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 estrutura organizacional mínima. Menos de uma dúzia de funcionários trabalhavam 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 eles estavam tentando realizar. Isso porque qualquer estrutura organizacional necessária era comunicada informalmente entre cada um dos funcionários.

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

good, simple, irrefutable reasons for the separation of environments that would get managers lacking development experience to support this idea.

O Uber recentemente enviou o código para o github que continha senhas para o ambiente ao vivo , permitindo que 'hackers' baixassem todos os detalhes de seus clientes. Uber diz que foi uma brecha, todo mundo diz "não coloque as chaves dos seus cadeados na visão pública. Se seus desenvolvedores trabalharam inteiramente em um ambiente de desenvolvimento, eles podem ter liberado as chaves do seu ambiente de desenvolvimento no github, mas isso é inteiramente inofensivo.Que as produções foram lançadas mostra quão pobre é essa idéia de executar o desenvolvimento no ambiente de produção.

Apenas lembre ao seu gerente que erros acontecem, então a maneira de evitar que ele seja arrastado para o CEO que está prestes a grelhar diante de jornalistas e riu do público de tecnologia é dar passos simples e óbvios para evitar erros sendo catastróficos.

Parece que você tem muitos ambientes diferentes e custa muito tempo para as pessoas configurarem um "ambiente".

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

Idealmente, as únicas diferenças devem ser:

1. Tamanho (mínimo, recomendado, maior suporte / testado contra);
2. Preparação e produção não têm ferramentas de desenvolvimento
3. A produção está protegida contra substituição acidental de dados
4. É muito fácil carregar dados de demonstração, teste ou [anoymized] de clientes em servidores de desenvolvimento ou de teste

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

Edição posterior: isso me motivou a racionalizar minhas convenções de nomenclatura com meus produtos da Web (obrigado pela pergunta). Decidi sobre quatro "ambientes", com divisão de testes entre qa (camada única mínima para testar somente a funcionalidade) e preparação (mesma arquitetura da produção, para testes de carga / desempenho / volume).

A única diferença real no provisionamento é a produção / preparação instalar um banco de dados em um sistema separado, que eu controle por quais grupos os diferentes servidores estão. qa / dev tem as funções servidor 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 "staging" quanto eu escolher.

Então, para configurar um segundo ambiente 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 "readonly" 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 última noite desabilitados (o software também é atualizado para a noite anterior).

Ele usa uma abordagem "Todos os ovos em uma cesta diferente": ele é provisionado com um local diferente / registrador DNS, host DNS, provedores de serviço de host do sistema. Esta é a última / última rede de segurança, então se tudo tiver ficado em chamas, você pode pelo menos obter 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 mudança, você terá a sorte de ter alguém que apenas ouça sua opinião profissional e implemente as mudanças sugeridas.

Pela minha experiência, cada vez que tive que fazer uma grande mudança, tive que justificá-la em termos de economia que a empresa fará. Por exemplo, a introdução do ReSharper no pipeline de desenvolvimento foi bem fácil, já que consegui dizer algo nas linhas:

O ReSharper custa cerca 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 o seu uso a todo o seu potencial. O desenvolvedor gasta 75% do tempo realmente escrevendo código no IDE. 75% de 40k é £ 30k. £ 30k é agora o custo da produtividade do desenvolvedor. Um percentual adicional de produtividade (1%) por ano custa £ 300. Para obter uma produtividade adicional de 20%, a empresa teria que gastar £ 6k.

Se você colocar isso em perspectiva para o negócio, pode dizer que pode contratar alguém e obter uma produtividade adicional de 20% por £ 6k, ou obter o mesmo resultado gastando £ 50 em uma licença ReSharper. Uma vez que os números estão na frente do negócio, a decisão será fácil de fazer.

Agora, no que diz respeito a suas perguntas com vários ambientes, tudo o que você precisa fazer é encontrar uma maneira de calcular quanto custa à empresa todo ano ter esses ambientes agora.

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

Eu pessoalmente odeio esse tipo de política, mas é comum e nós temos que viver com isso.