O relatório falará sobre algumas práticas de DevOps, mas do ponto de vista do desenvolvedor. Normalmente, todos os engenheiros que ingressam no DevOps já possuem vários anos de experiência administrativa. Mas isso não significa que não haja lugar para o desenvolvedor aqui. Na maioria das vezes, os desenvolvedores estão ocupados corrigindo “o próximo bug urgentemente crítico do dia” e não têm tempo nem para dar uma olhada rápida no campo DevOps. No entendimento do autor, DevOps é, em primeiro lugar, bom senso. Em segundo lugar, é uma oportunidade para ser mais eficaz. Se você é desenvolvedor, tem bom senso e deseja ser mais eficaz em equipe, este relatório é para você.
Deixe-me apresentar-me, admito plenamente que há pessoas na sala que não me conhecem. Meu nome é Anton Boyko, sou MVP do Microsoft Azure. O que é MVP? Este é o Model-View-Presenter. Model-View-Presenter sou exatamente eu.
Além disso, atualmente ocupo o cargo de arquiteto de soluções na Ciklum. E recentemente comprei um domínio tão lindo e atualizei meu e-mail, que costumo mostrar em apresentações. Você pode escrever para mim em: me [dog] byokoant.pro. Você pode me enviar um e-mail com perguntas. Eu costumo respondê-los. A única coisa é que não gostaria de receber por e-mail perguntas relacionadas a dois temas: política e religião. Você pode me escrever sobre todo o resto por e-mail. Algum tempo vai passar, eu responderei.
Algumas palavras sobre mim:
- Estou nesta área há 10 anos.
- Eu trabalhei na Microsoft.
- Sou o fundador da comunidade Azure Ucraniana, que fundamos em 2014. E ainda temos e estamos desenvolvendo.
- Também sou o pai do fundador da conferência Azure, que estamos a organizar na Ucrânia.
- Também ajudo a organizar o Global Azure Bootcamp em Kiev.
- Como eu disse, sou um MVP do Microsoft Azure.
- Falo em conferências com bastante frequência. Eu realmente adoro falar em conferências. No ano passado, consegui me apresentar cerca de 40 vezes. Se você passar pela Ucrânia, Bielorrússia, Polônia, Bulgária, Suécia, Dinamarca, Holanda, Espanha ou mais ou menos outro país da Europa, então é bem possível que quando você for a uma conferência que tenha um tema de nuvem em seu fluxo, você pode me ver na lista de palestrantes.
- Também sou fã de Star Trek.
Vamos falar um pouco sobre Agenda. Nossa Agenda é muito simples:
- Falaremos sobre o que é DevOps. Vamos conversar por que isso é importante. Anteriormente, DevOps era uma palavra-chave que você escrevia em seu currículo e recebia imediatamente +$500 em salário. Agora você precisa escrever, por exemplo, blockchain em seu currículo para ganhar +500 dólares em seu salário.
- E então, quando entendermos um pouco sobre o que é isso, falaremos sobre o que são práticas de DevOps. Mas não tanto no contexto de DevOps em geral, mas sobre aquelas práticas de DevOps que podem ser de interesse dos desenvolvedores. Vou lhe dizer por que eles podem ser do seu interesse. Direi por que você deveria fazer isso e como isso pode ajudá-lo a sentir menos dor.
Uma imagem tradicional que muitas pessoas mostram. Isso é o que acontece em muitos projetos. É quando temos departamentos de desenvolvimento e operações que dão suporte ao nosso software. E esses departamentos não se comunicam entre si.
Talvez, se você não conseguiu sentir isso tão claramente nos departamentos de DevOps e operações, possa fazer uma analogia com os departamentos de Dev e QA. Existem pessoas que desenvolvem software e existem pessoas de controle de qualidade que são ruins do ponto de vista dos desenvolvedores. Por exemplo, eu envio meu código maravilhoso para o repositório, e há algum canalha sentado lá que me retorna esse código e diz que seu código é ruim.
Tudo isso acontece porque as pessoas não se comunicam entre si. E eles jogam alguns pacotes, alguma aplicação uns para os outros através de algum muro de mal-entendidos e tentam fazer algo com eles.
É precisamente esse muro que a cultura DevOps foi projetada para destruir, ou seja, forçar as pessoas a se comunicarem umas com as outras e pelo menos entenderem o que as diferentes pessoas no projeto fazem e por que seu trabalho é importante.
E quando falamos de DevOps, alguém vai te dizer que DevOps é quando o projeto tem integração contínua; alguém dirá que DevOps ocorre se o projeto implementar a prática de “infraestrutura como código”; alguém dirá que o primeiro passo para o DevOps é a ramificação de recursos, sinalizadores de recursos.
Essencialmente, tudo isso é verdade à sua maneira. Mas essas são apenas as práticas definitivas que temos. Antes de passar para essas práticas, sugiro dar uma olhada neste slide, que mostra as 3 etapas de implementação da metodologia Dev-Ops no seu projeto, na sua empresa.
Este slide também tem um segundo nome não oficial. Você pode pesquisar online para descobrir quais são os três mosqueteiros do DevOps. É possível que você encontre este artigo. Por que 3 Mosqueteiros? Abaixo diz: pessoas, processos e produtos, ou seja. PPP – Porthos, Porthos e Porthos. Aqui estão os 3 Mosqueteiros do DevOps. Este artigo descreve com mais detalhes por que isso é importante e o que isso implica.
Quando você começa a implementar uma cultura DevOps, é muito importante que ela seja implementada na seguinte ordem.
Inicialmente você precisa conversar com as pessoas. E você precisa explicar às pessoas o que é e como elas podem obter alguns benefícios com isso.
Nossa conferência se chama DotNet Fest. E como os organizadores me disseram, convidamos principalmente um público de desenvolvedores para cá, então espero que a maioria das pessoas presentes esteja envolvida no desenvolvimento.
Falaremos sobre pessoas, falaremos sobre o que os desenvolvedores querem fazer todos os dias. O que eles mais desejam? Eles querem escrever algum código novo, usar estruturas inovadoras, criar novos recursos. O que os desenvolvedores menos desejam? Corrija bugs antigos. Espero que você concorde comigo. Isso é o que os desenvolvedores querem. Eles querem escrever novos recursos, não querem consertar bugs.
O número de bugs que um determinado desenvolvedor produz depende de quão retos são seus braços e de quanto eles crescem em seus ombros, e não em seus bolsos traseiros. Mas mesmo assim, quando temos um projeto grande, às vezes acontece que é impossível acompanhar tudo, então seria bom usarmos algumas abordagens que nos ajudarão a escrever um código mais estável e de maior qualidade.
O que os QAs mais desejam? Não sei se eles estão no corredor. É difícil para mim dizer que quero um controle de qualidade, porque nunca fui um. E sem ofensa aos rapazes, dirão que espero nunca o fazer. Mas não porque considero o seu trabalho sem sentido e inútil, mas porque não me considero uma pessoa que possa fazer este trabalho com eficiência, por isso nem vou tentar fazê-lo. Mas pelo que entendi, o que o QA mais não gosta é trabalhar pela manhã, executando constantemente algum tipo de teste de regressão, pisando nos mesmos bugs que relataram aos desenvolvedores há 3 sprints e dizendo: “Quando você vai , Monsieur D 'Artagnan, corrija esse bug.' E Monsieur D'Artagnan lhe responde: “Sim, sim, sim, já consertei”. E aconteceu que eu consertei um bug e fiz 5 ao longo do caminho.
As pessoas que apoiam esta solução em produção querem que esta solução funcione sem bugs, para que não tenham que reiniciar o servidor todas as sextas-feiras, quando todas as pessoas normais vão para o bar. Os desenvolvedores implantaram na sexta-feira, os administradores ficam até sábado, tentando configurar e consertar essa implantação.
E quando você explica às pessoas que elas visam resolver os mesmos problemas, você pode passar à formalização dos processos. É muito importante. Por que? Porque quando dizemos “formalização”, é importante que você descreva como seus processos ocorrem, pelo menos em algum lugar de um guardanapo. Você precisa entender que se você, por exemplo, implantar em um ambiente de controle de qualidade ou em um ambiente de produção, isso sempre acontecerá nesta ordem; nesses estágios executamos, por exemplo, testes de unidade automáticos e testes de UI. Após a implantação, verificamos se a implantação foi boa ou ruim. Mas você já tem uma lista clara de ações que devem ser repetidas continuamente ao implantar na produção.
E somente quando seus processos estão formalizados é que você começa a selecionar produtos que vão te ajudar a automatizar esses processos.
Infelizmente, muitas vezes vejo isso acontecer ao contrário. Assim que alguém ouve a palavra “DevOps”, imediatamente sugere instalar o Jenkins, pois acredita que assim que instalar o Jenkins, terá DevOps. Eles instalaram o Jenkins, leram os artigos “Como fazer” no site do Jenkins, tentaram inserir processos nesses artigos Como fazer e então se aproximaram das pessoas e as curvaram, dizendo que o livro diz que você precisa fazer dessa maneira, então fazemos assim.
Não é que Jenkins seja uma ferramenta ruim. Não quero dizer isso de forma alguma. Mas este é apenas um dos produtos. E qual produto você usa deve ser sua última decisão, e de forma alguma a primeira. Seu produto não deve ser impulsionado pela implementação de cultura e abordagens. É muito importante entender isso, por isso passo tanto tempo neste slide e explico tudo isso por tanto tempo.
Vamos falar sobre práticas DevOps em geral. O que eles são? Qual é a diferença? Como experimentá-los? Por que eles são importantes?
A primeira prática da qual você já deve ter ouvido falar é chamada de Integração Contínua. Talvez alguém no projeto tenha Integração Contínua (CI).
O maior problema é que na maioria das vezes quando pergunto a uma pessoa: “Você tem CI no projeto?” e ele diz: “Sim”, então quando pergunto o que ele faz, ele me descreve absolutamente todo o processo de automação. Isso não é inteiramente verdade.
Na verdade, a prática da CI visa apenas integrar o código que diferentes pessoas escrevem em algum tipo de base de código única. Isso é tudo.
Junto com a CI, geralmente existem outras práticas ao longo do caminho – como Implantação Contínua, Gerenciamento de Liberação, mas falaremos sobre isso mais tarde.
A própria CI nos diz que diferentes pessoas escrevem código e esse código deve ser continuamente integrado em uma única base de código.
O que isso nos dá e por que é importante? Se tivermos DotNet, então tudo bem, é uma linguagem compilada, podemos compilar nossa aplicação. Se compilar, isso já é um bom sinal. Isso ainda não significa nada, mas é o primeiro bom sinal de que podemos pelo menos compilar.
Depois podemos executar alguns testes, o que também é uma prática separada. Os testes estão todos verdes – este é o segundo bom sinal. Mas, novamente, isso não significa nada.
Mas por que você faria isso? Todas as práticas das quais falarei hoje têm aproximadamente o mesmo valor, ou seja, aproximadamente os mesmos benefícios e também são medidas aproximadamente da mesma forma.
Primeiro, permite acelerar a entrega. Como isso permite que você acelere a entrega? Quando fazemos algumas alterações em nossa base de código, podemos imediatamente tentar fazer algo com esse código. A gente não espera até quinta porque na quinta liberamos para QA Environment, fazemos aqui mesmo e aqui mesmo.
Vou contar uma história triste da minha vida. Foi há muito tempo, quando eu ainda era jovem e bonito. Agora já sou jovem, bonita e inteligente e modesta. Há algum tempo eu estava em um projeto. Tínhamos uma grande equipe de cerca de 30 desenvolvedores. E tivemos um grande projeto empresarial que se desenvolveu por cerca de 10 anos. E tínhamos filiais diferentes. No repositório tínhamos um branch por onde os desenvolvedores andavam. E tinha uma branch que exibia a versão do código que está em produção.
O ramo de produção estava 3 meses atrás do ramo que estava disponível para os desenvolvedores. O que isto significa? Isso significa que assim que eu tiver um bug em algum lugar que vai para produção por culpa dos desenvolvedores, porque eles permitiram, e por culpa do controle de qualidade, porque eles olharam para ele, então isso significa que se eu receber um tarefa de hotfix para produção, então terei que reverter minhas alterações de código há 3 meses. Tenho que lembrar o que tinha há 3 meses e tentar consertar aí.
Se você ainda não teve essa experiência, pode experimentá-la no projeto da sua casa. O principal é não tentar fazer isso comercialmente. Escreva algumas linhas de código, esqueça-as por seis meses e depois volte e tente explicar rapidamente do que se trata essas linhas de código e como você pode corrigi-las ou otimizá-las. É uma experiência muito, muito emocionante.
Se tivermos uma prática de Integração Contínua, isso nos permitirá verificá-la com uma série de ferramentas automatizadas aqui e agora, assim que eu tiver escrito meu código. Isto pode não me dar uma visão completa, mas mesmo assim eliminará pelo menos alguns dos riscos. E se houver algum bug em potencial, saberei agora mesmo, ou seja, literalmente em alguns minutos. Não precisarei reverter 3 meses. Só precisarei reverter 2 minutos. Uma boa máquina de café não terá tempo de preparar o café em 2 minutos, então isso é muito legal.
Isso tem o valor de poder ser repetido repetidas vezes em cada projeto, ou seja, não apenas aquele em que você configurou. Você pode repetir a prática em si e o próprio CI será repetido para cada nova alteração feita no projeto. Isso permite otimizar recursos porque sua equipe trabalha com mais eficiência. Você não terá mais uma situação em que um bug venha do código com o qual você trabalhou há 3 meses. Você não terá mais troca de contexto quando sentar e passar as primeiras duas horas tentando entender o que aconteceu e entrar na essência do contexto antes de começar a corrigir algo.
Como podemos medir o sucesso ou fracasso desta prática? Se você relatar ao chefão o que implementamos no projeto de CI, ele ouvirá blá, blá, blá. Nós implementamos, tudo bem, mas por que, o que isso trouxe para nós, como medimos, quão correta ou incorretamente estamos implementando?
A primeira é que, graças à CI, podemos implantar cada vez com mais frequência, e com mais frequência precisamente porque nosso código é potencialmente mais estável. Da mesma forma, nosso tempo para encontrar um erro é reduzido e o tempo para corrigir esse erro é reduzido justamente porque recebemos uma resposta do sistema aqui e agora, o que há de errado com nosso código.
Outra prática que temos é a prática de Testes de Automação, que na maioria das vezes vem junto com a prática de CI. Eles andam de mãos dadas.
O que é importante entender aqui? É importante entender que nossos testes são diferentes. E cada teste automatizado visa resolver seus próprios problemas. Temos, por exemplo, testes unitários que nos permitem testar um módulo separadamente, ou seja, Como funciona no vácuo? Isso é bom.
Também temos testes de integração que nos permitem compreender como diferentes módulos se integram entre si. Também é bom.
Podemos ter testes de automação de UI que nos permitem verificar se o trabalho com a UI atende a determinados requisitos definidos pelo cliente, etc.
Os testes específicos executados podem afetar a frequência com que você os executa. Os testes de unidade geralmente são escritos de forma curta e pequena. E eles podem ser lançados regularmente.
Se estamos falando de testes de automação de UI, então é bom que seu projeto seja pequeno. Seus testes de automação de IU podem levar algum tempo adequado. Mas geralmente um teste de automação de UI é algo que leva várias horas em um projeto grande. E é bom se demorar algumas horas. A única coisa é que não faz sentido executá-los para cada compilação. Faz sentido executá-los à noite. E quando todos vieram trabalhar pela manhã: tanto testadores quanto desenvolvedores, eles receberam algum tipo de relatório informando que executamos o autoteste da IU à noite e obtivemos esses resultados. E aqui, uma hora de trabalho de um servidor que irá verificar se seu produto atende a alguns requisitos será muito mais barata do que uma hora de trabalho do mesmo engenheiro de QA, mesmo que ele seja um engenheiro de QA Junior que trabalha por comida e obrigado. Mesmo assim, uma hora de operação da máquina será mais barata. É por isso que faz sentido investir nisso.
Tenho outro projeto em que estou trabalhando. Tivemos sprints de duas semanas neste projeto. O projeto era grande, importante para o setor financeiro e não era possível cometer erros. E depois de um sprint de duas semanas, o ciclo de desenvolvimento foi seguido por um processo de teste, que durou mais 4 semanas. Tente imaginar a escala da tragédia. Escrevemos o código por duas semanas, depois fazemos isso como CodeFreeze, empacotamos em uma nova versão do aplicativo e o lançamos para os testadores. Os testadores testam por mais 4 semanas, ou seja, Enquanto eles testam, temos tempo para preparar mais duas versões para eles. Este é um caso muito triste.
E dissemos a eles que se você quiser ser mais produtivo, faz sentido implementar práticas de Teste Automatizado, porque é isso que prejudica você aqui e agora.
Pratique a implantação contínua. Ótimo, você construiu. Isso já é bom. Seu código foi compilado. Agora seria bom implantar esta compilação em algum ambiente. Digamos que em um ambiente para desenvolvedores.
Por que isso é importante? Primeiro, você pode verificar seu sucesso com o próprio processo de implantação. Já conheci projetos assim, quando pergunto: “Como você implanta uma nova versão do aplicativo?”, os caras me dizem: “Nós montamos e empacotamos em um arquivo zip. Enviamos para o administrador por correio. O administrador baixa e expande este arquivo. E todo o escritório começa a rezar para que o servidor receba a nova versão.”
Vamos começar com algo simples. Por exemplo, eles se esqueceram de colocar CSS no arquivo ou de alterar a hashtag no nome do arquivo java-script. E quando fazemos uma solicitação ao servidor, o navegador pensa que já possui esse arquivo java-script e decide não baixá-lo. E havia uma versão antiga, faltava alguma coisa. Em geral, pode haver muitos problemas. Portanto, a prática de Implantação Contínua permite pelo menos testar o que aconteceria se você pegasse uma imagem de referência limpa e a carregasse em um novo ambiente completamente limpo. Você pode ver aonde isso leva.
Além disso, quando você integra código entre si, ou seja, entre o comando, isso permite que você também veja como fica na interface do usuário.
Um dos problemas que ocorre quando muitos scripts java vanilla são usados é que dois desenvolvedores declararam precipitadamente uma variável com o mesmo nome no objeto window. E então, dependendo da sua sorte. Cujo arquivo java-script for extraído em segundo lugar substituirá as alterações do outro. Também é muito emocionante. Você entra: uma coisa funciona para uma pessoa, outra não funciona para outra. E é “maravilhoso” quando tudo sai em produção.
A próxima prática que temos é a prática de Restauração Automática, ou seja, reverter para a versão anterior do aplicativo.
Por que isso é importante para os desenvolvedores? Ainda há quem se lembre dos longínquos anos 90, quando os computadores eram grandes e os programas pequenos. E a única forma de desenvolvimento web era através do PHP. Não é que o PHP seja uma linguagem ruim, embora seja.
Mas o problema era diferente. Quando implantamos uma nova versão do nosso site php, como a implantamos? Na maioria das vezes abrimos o Far Manager ou qualquer outra coisa. E carreguei esses arquivos no FTP. E de repente percebemos que tínhamos algum pequeno bug, por exemplo, esquecemos de colocar ponto e vírgula ou esquecemos de alterar a senha do banco de dados, e há uma senha para o banco de dados, que está no host local. E decidimos conectar-nos rapidamente ao FTP e editar os arquivos ali mesmo. Isso é apenas fogo! Isso é o que era popular nos anos 90.
Mas, se você não olhou o calendário, os anos 90 foram há quase 30 anos. Agora tudo está acontecendo de forma um pouco diferente. E tente imaginar a dimensão da tragédia quando lhe disserem: “Entramos em produção, mas algo deu errado lá. Aqui está seu login e senha de FTP, conecte-se à produção e corrija-o rapidamente.” Se você é Chuck Norris, isso funcionará. Caso contrário, você corre o risco de, se corrigir um bug, ganhar mais 10. É exatamente por isso que essa prática de reverter para a versão anterior permite que você consiga muito.
Mesmo que algo ruim de alguma forma tenha ocorrido em algum lugar, então é ruim, mas não fatal. Você pode reverter para a versão anterior que possui. Chame isso de backup, se for mais fácil perceber nessa terminologia. Você pode reverter para esta versão anterior e os usuários ainda poderão trabalhar com seu produto e você terá tempo de buffer adequado. Você pode com calma, sem pressa, pegar tudo isso e testar localmente, consertar e depois fazer upload de uma nova versão. Realmente faz sentido fazer isso.
Agora vamos tentar combinar de alguma forma as duas práticas anteriores. Teremos um terceiro chamado Release Management.
Quando falamos em Continuous Deployment em sua forma clássica, dizemos que devemos extrair código de alguma ramificação do repositório, compilá-lo e implantá-lo. É bom se tivermos o mesmo ambiente. Se tivermos vários ambientes, isso significa que teremos que extrair o código todas as vezes, até mesmo do mesmo commit. Iremos retirá-lo sempre, iremos construí-lo sempre e iremos implantá-lo em um novo ambiente. Em primeiro lugar, é hora, porque para construir um projeto, se você tem um grande e veio da década de 90, pode demorar várias horas.
Além disso, há outra tristeza. Ao compilar, mesmo na mesma máquina, você construirá as mesmas fontes, ainda não tem garantia de que esta máquina esteja no mesmo estado que estava durante a última compilação.
Digamos que alguém entrou e atualizou o DotNet para você ou, inversamente, alguém decidiu excluir algo. E então você tem dissonância cognitiva de que a partir deste commit há duas semanas estávamos construindo uma compilação e estava tudo bem, mas agora parece a mesma máquina, o mesmo commit, o mesmo código que estamos tentando construir, mas não está funcionando . Você vai lidar com isso por muito tempo e não é fato que vai descobrir. No mínimo, você vai estragar muito os seus nervos.
Portanto, a prática de Gerenciamento de Liberação sugere a introdução de uma abstração adicional chamada repositório de artefatos, galeria ou biblioteca. Você pode chamá-lo do que quiser.
A ideia principal é que assim que tivermos algum tipo de commit aí, digamos, em um branch que estamos prontos para implantar em nossos diferentes ambientes, coletemos aplicações desse commit e tudo que precisamos para essa aplicação, nós embalamos em um arquivo zip e salve-o em algum armazenamento confiável. E deste armazenamento podemos obter este arquivo zip a qualquer momento.
Em seguida, pegamos e implantamos automaticamente no ambiente de desenvolvimento. Corremos lá e, se tudo estiver bem, subimos ao palco. Se tudo estiver bem, implantamos o mesmo arquivo em produção, os mesmos binários, compilados exatamente uma vez.
Além disso, quando temos uma galeria como essa, ela também nos ajuda a abordar os riscos que abordamos no último slide quando falamos em rollback para a versão anterior. Se você acidentalmente implantou algo errado, você sempre pode pegar qualquer outra versão anterior desta galeria e desimplantá-la nesses ambientes da mesma maneira. Isso permite que você reverta facilmente para a versão anterior se algo der errado.
Existe outra ótima prática. Todos vocês e eu entendemos que quando revertemos nossos aplicativos para uma versão anterior, isso pode significar que também precisaremos da infraestrutura da versão anterior.
Quando falamos em infraestrutura virtual, muitas pessoas pensam que isso é algo que os administradores configuram. E se você precisar, digamos, de obter um novo servidor no qual deseja testar uma nova versão do seu aplicativo, deverá escrever um ticket para os administradores ou devops. Devops levará 3 semanas para isso. E depois de 3 semanas eles vão te dizer que instalamos uma máquina virtual para você, com um núcleo, dois gigabytes de RAM e um servidor Windows sem DotNet. Você diz: “Mas eu queria DotNet”. Eles: “Ok, volte em 3 semanas.”
A ideia é que, ao usar práticas de Infraestrutura como Código, você possa tratar sua infraestrutura virtual como apenas mais um recurso.
Talvez, se algum de vocês estiver desenvolvendo aplicativos em DotNet, já tenha ouvido falar de uma biblioteca chamada Entity Framework. E você pode até ter ouvido falar que o Entity Framework é uma das abordagens que a Microsoft está promovendo ativamente. Para trabalhar com um banco de dados, esta é uma abordagem chamada Code First. É quando você descreve no código como deseja que seu banco de dados fique. E então você implanta o aplicativo. Ele se conecta ao banco de dados, determina quais tabelas estão lá e quais não estão e cria tudo o que você precisa.
Você pode fazer o mesmo com sua infraestrutura. Não há diferença entre você precisar de um banco de dados para um projeto ou de um servidor Windows para um projeto. É apenas um recurso. E você pode automatizar a criação desse recurso, você pode automatizar a configuração desse recurso. Assim, toda vez que você quiser testar algum novo conceito, alguma nova abordagem, você não precisará escrever um ticket para devops, você pode simplesmente implantar uma infraestrutura isolada para você a partir de modelos prontos, de scripts prontos e implementá-la aí estão todos os seus experimentos. Você pode excluir isso, obter alguns resultados e relatar mais sobre isso.
A próxima prática, que também existe e também é importante, mas que poucas pessoas utilizam, é o Monitoramento de Desempenho de Aplicações.
Eu queria dizer apenas uma coisa sobre o monitoramento de desempenho de aplicativos. O que há de mais importante nesta prática? Isso é o que o Monitoramento de Desempenho de Aplicativos é quase o mesmo que consertar um apartamento. Este não é um estado final, é um processo. Você precisa fazer isso regularmente.
No bom sentido, seria bom realizar o monitoramento de desempenho de aplicativos em quase todas as compilações, embora, como você entende, isso nem sempre seja possível. Mas, no mínimo, precisa ser realizado para cada lançamento.
Por que isso é importante? Porque se você experimentar uma queda repentina no desempenho, precisará entender claramente o porquê. Se sua equipe tem, digamos, sprints de duas semanas, pelo menos uma vez a cada duas semanas você deve implantar seu aplicativo em algum servidor separado, onde você tenha um processador, RAM, discos claramente fixos, etc. . Você obtém o resultado. Veja como isso mudou em relação ao sprint anterior.
E se você descobrir que a redução caiu drasticamente em algum lugar, isso significará que foi apenas por causa das mudanças que ocorreram nas últimas duas semanas. Isso permitirá que você identifique e resolva o problema com muito mais rapidez. E, novamente, essas são aproximadamente as mesmas métricas pelas quais você pode medir o quão bem-sucedido você fez isso.
A próxima prática que temos é a prática de Gerenciamento de Configuração. São poucos os que levam isso a sério. Mas acredite, isso é realmente uma coisa muito séria.
Houve uma história engraçada recentemente. Os caras vieram até mim e disseram: “Ajude-nos a realizar uma auditoria de segurança em nosso aplicativo”. Analisamos o código juntos por muito tempo, eles me falaram sobre o aplicativo, desenharam diagramas. E mais ou menos tudo era lógico, compreensível, seguro, mas havia um MAS! Eles possuíam arquivos de configuração em seu controle de origem, inclusive os de produção com banco de dados IP, com logins e senhas para conexão a esses bancos de dados, etc.
E eu digo: “Gente, ok, vocês fecharam seu ambiente de produção com firewall, mas o fato de você ter o login e a senha do banco de dados de produção direto no controle de origem e qualquer desenvolvedor poder ler já é um risco enorme de segurança . E não importa o quão super seguro seu aplicativo seja do ponto de vista do código, se você deixá-lo no controle de origem, você nunca passará em nenhuma auditoria em lugar nenhum.” É disso que estou falando.
Gerenciamento de configurações. Podemos ter configurações diferentes em ambientes diferentes. Por exemplo, podemos ter logins e senhas diferentes para bancos de dados para controle de qualidade, demonstração, ambiente de produção, etc.
Esta configuração também pode ser automatizada. Deve estar sempre separado do próprio aplicativo. Por que? Como você construiu o aplicativo uma vez e o aplicativo não se importa se você se conecta ao servidor SQL por meio de tal e tal IP ou tal e tal IP, ele deve funcionar da mesma forma. Portanto, se de repente um de vocês ainda estiver codificando a string de conexão no código, lembre-se de que irei encontrá-lo e puni-lo se você estiver no mesmo projeto que eu. Isto é sempre colocado em uma configuração separada, por exemplo, em web.config.
E essa configuração já é gerenciada separadamente, ou seja, é exatamente nesse momento que um desenvolvedor e um administrador podem entrar e sentar na mesma sala. E o desenvolvedor pode dizer: “Olha, aqui estão os binários da minha aplicação. Eles trabalham. O aplicativo precisa de um banco de dados para funcionar. Aqui ao lado dos binários existe um arquivo. Neste arquivo, este campo é responsável pelo login, este é pela senha, este é pelo IP. Implante-o em qualquer lugar." E é simples e claro para o administrador. Ele pode implantá-lo em qualquer lugar gerenciando essa configuração.
E a última prática sobre a qual gostaria de falar é uma prática que está muito, muito relacionada com nuvens. E traz efeito máximo se você trabalhar na nuvem. Esta é a remoção automática do seu ambiente.
Eu sei que há várias pessoas nesta conferência das equipes com as quais trabalho. E com todas as equipes com quem trabalho, usamos essa prática.
Por que? Claro, seria ótimo se cada desenvolvedor tivesse uma máquina virtual que funcionasse 24 horas por dia, 7 dias por semana. Mas talvez isso seja novidade para você, talvez você não tenha prestado atenção, mas o próprio desenvolvedor não trabalha 24 horas por dia, 7 dias por semana. Um desenvolvedor geralmente trabalha 8 horas por dia. Mesmo que chegue cedo ao trabalho, ele almoça bastante e vai à academia. Que sejam 12 horas por dia quando o desenvolvedor realmente usa esses recursos. De acordo com a nossa legislação, temos 5 dos 7 dias da semana que são considerados dias úteis.
Assim, durante a semana esta máquina não deve funcionar 24 horas, mas apenas 12, e nos finais de semana esta máquina não deve funcionar. Parece que tudo é muito simples, mas o que é importante dizer aqui? Ao implementar esta prática simples neste cronograma básico, você pode reduzir o custo de manutenção desses ambientes em 70%, ou seja, você pegou o preço do seu dev, QA, demo, ambiente e dividiu por 3.
A questão é: o que fazer com o restante do dinheiro? Por exemplo, os desenvolvedores deveriam comprar o ReSharper, caso ainda não o tenham feito. Ou faça um coquetel. Se antes você tinha um ambiente em que tanto o desenvolvedor quanto o controle de qualidade pastavam e pronto, agora você pode criar 3 ambientes diferentes que ficarão isolados e as pessoas não interferirão umas nas outras.
Em relação ao slide com medição contínua de desempenho, como podemos comparar o desempenho se tivéssemos 1 registros no banco de dados do projeto, dois meses depois já são um milhão? Como entender por que e qual o sentido de medir o desempenho?
Esta é uma boa pergunta, porque você deve sempre medir o desempenho nos mesmos recursos. Ou seja, você implementa um novo código e mede o desempenho do novo código. Por exemplo, você precisa testar diferentes cenários de desempenho, digamos que deseja testar o desempenho do aplicativo em uma carga leve, onde há 1 usuários e o tamanho do banco de dados é de 000 gigabytes. Você mediu e obteve os números. A seguir, pegamos outro cenário. Por exemplo, 5 usuários, tamanho do banco de dados de 5 terabyte. Recebemos os resultados e nos lembramos deles.
O que é importante aqui? O importante aqui é que dependendo do cenário, do volume de dados, da quantidade de usuários simultâneos, etc., você pode esbarrar em certos limites. Por exemplo, até o limite de uma placa de rede, ou até o limite de um disco rígido, ou até o limite das capacidades do processador. Isto é o que é importante que você entenda. Em diferentes cenários você encontra certos limites. E você precisa entender os números quando os atinge.
Estamos falando de medir o desempenho em um ambiente de teste especial? Ou seja, isso não é produção?
Sim, isso não é produção, é um ambiente de teste, que é sempre o mesmo para que você possa comparar com medições anteriores.
Entendi, obrigado!
Se não houver perguntas, acho que podemos terminar. Obrigado!
Fonte: habr.com