A Forma Ideal de Projetos Web | Os 12 Fatores

o Olá pessoal Fabio Akita no episódio anterior eu me dei ao trabalho de fazer o passo a passo de um tutorial simples de primeiros passos usando o heroku para fazer depois de um projetinho de exemplo em PHP o objetivo foi mostrar o processo de depoimento de uma aplicação moderna para iniciantes que talvez nunca tenha ouvido falar de heroku qualquer desenvolvedor que já trabalha com certeza já conhecia então se você não sabe o que é heroku Assista o Episódio anterior antes de ver este porque precisa saber o que eu disse lá para entender esse hoje eu

quero falar sobre um troço conhecido como os doze fatores que é meio momento do logia que pode ser aplicada a projetos web escritos em qualquer linguagem de programação e qualquer Framework web Além disso eu quero complementar com alguns fatores que Originalmente não se menciona mas meio que ficam implícitos se você quer um projeto web que tem a capacidade de escalar é meio que obrigatório que no mínimo esses doze fatores estejam satisfeitos satisfa Um dos fatores não torna nenhum aplicação automaticamente escalável mas não satisfazer eles quase garante que não vai escalar de jeito nenhum né E

aí e se você já é programador de sistemas legados eu tenho certeza que quando viu o tutorial de her o cu pela primeira vez brilhou seus olhos de vontade de poder trabalhar desse jeito se você é de uma agência asinha porcaria e eu defino como porcaria todas que ainda atualizam sites via FTP como eu falei antes mesma coisa deve estar se coçando de vontade de poder trabalhar assim todo mundo que trabalha em techstar tacos hoje em dia ou Empresas Grandes que se modernizaram já trabalham dessa forma mas cuidado que você não trabalha assim mesmo assistindo

até aqui acho tudo desnecessário o mesmo ruim eu repensaria carreira você vai se tornar obsoleto muito em breve e quem acha que isso tudo é só mais uma novidade passageira que vai acabar daqui a pouco tá bem enganado eu trabalho desse jeito desde aproximadamente 2010 portanto mais de uma década eu ajudei o quanto pude a difundir esse estilo de trabalho por anos e finalmente isso se tornou o padrão muitos tentaram m um pouco mais até hoje eu acho impressionante que poucos conseguiram chegar perto só Resumindo se você não lembra do Episódio Passado O Grande Lance

é você não configurar um servidor manualmente se tudo automatizado e principalmente não instalar todos os componentes da aplicação no mesmo lugar deixar cada coisa não contém né separado como serviços externos Independentes Além disso consegui fazer depois frequentes a cada nova funcionalidade ou correção de bug tudo tão fácil quanto fazer um Beach push literalmente na mesma época que o heroku surgiu o Google tinha acabado de lançar um produto que fez muito barulho o Google Apps em Gene para rodar aplicações feitas em Python usando os serviços do Google o problema é que você não podia usar componentes

padrão de Linux como o banco de dados postgis precisava usar o banco do Google que era o Big table um novo ciclo que só existe no Google e não dá para rodar em outro lugar além disso precisava programar de formas específicas para o app Engine é uma vez que funcionasse não dava para rodar em nenhum outro lugar era super simples de subir aplicação mas a super limitado restritivo e você ficava preso a grande sacada do reino que foi abrir os padrões e ajudar a criar uma forma onde ao mesmo tempo você queria ficar no heroku

porque tudo era muito simples e seguro mas não precisava lobotomizar seu código para fazer rodar se quisesse sair instalar sua própria empresa estrutura sua aplicação não tinha nada proprietário eu te prendendo além disso eles criaram o conceito de Marketplace de software as a service para desenvolvedores você podia sair do heroku instalar sua aplicação manualmente no VPS Donald e ainda usar o mesmo serviço de hipertreino que eu mostrei antes lá por exemplo os é dons também são independentes do heroku mas se ainda não ficou o meu você não escolhe em infraestrutura querendo que seja barato demais

porque você recebe exatamente aquilo que paga se paga barato não espere te garantir de nada aí Não espere que seu sistema vai cair quando mais precisa dele e vai sair super caro colocar tudo no ar de novo para aguentar a carga é por isso que sempre que possível a recomendação é começar no heroku no outro extremo Você tem dinheiro sobrando não recomendem direto para um kubernet começa no heroku só faz entre estrutura customizada quando tem dados de uso que realmente justificam isso o heroku mantém as coisas atualizadas Pets de segurança e tudo mais são aplicados

na sua influem na maioria dos casos não posso fazer nada o jeito que morreram que obriga organizar seu projeto Não esperem nada de proprietário mas ao mesmo tempo de força fazer as coisas do jeito certo é a principal vantagem quando alguma coisa não funciona no heroku normalmente não é um problema do heroku é problema da sua aplicação que foi feita de um jeito porco e para facilitar Educação do jeito certo de programar aplicações web o co-fundador Adam melling escreveu um site chamado de tú el Factor que estão os doze fatores que tu a web deve

ter para ser minimamente possível instalar no infraestrutura escalável com morrer oco é como se fossem 12 pattern de gerenciamento de arquitetura de projeto esse site foi publicado Acho que em 2011 e tudo que tá nele continua válido igualzinho até hoje quem acompanha este canal e conseguiu acompanhar o tutorial de louco até aqui já entendi a maioria mas eu quero comentar. A ponto desses doze fatores se você é iniciante preste muita atenção é isso que se espera que todo programador web saiba de cor e salteado independente da linguagem ou frame que escolhi aliás todos os fremax

modernos de hoje facilita você implementar esses dois fatores um frame Por que que não é compatível com esses fatores é um péssimo Frei porque você não deveria estar usando vamos lá o ponto um declara que todo o código-fonte deve estar no repositório de versionamento de código hoje em dia isso só tem uma resposta e se chama DIT Tudo pode estar no único eu posso se você completo gigantesco Talvez seja dividido em múltiplos repositórios ou mono ricoh não importa contanto que esteja em 20 que todo mundo da equipe tem acesso e que se faça depois com

frequência esse ponto é chave no próprio tutorial do episódio passado eu fiz pelo menos uma meia dúzia de depois enquanto e adicionando novas funcionalidades antigamente fazer depois era um processo demorado manual cheio de erros humanos hoje em dia o certo é que se faça depois continuamos múltiplos por semana múltiplos por dia no mínimo em um ambiente que chamamos de Stadium que é tipo um ambiente de testes onde tudo moda como se fosse um ambiente de produção não pode existir uma dúzia de desenvolvedores fazendo o código semanas inteiras e levar mais semanas para subir esse código

não é infraestrutura de testes é inadimissível e é sinal Claro de incompetência da gerência das equipe o segundo fator se chama dependências e foi por isso que me along tô falando de gerenciamento de dependências durante o tutorial é fator fundamental que todas as dependências de um projeto web não dependam de pacotes específicos de sistema operacional instalado na máquina isso porque o sistema operacional dos containers do Servidor e o sistema na máquina de cada desenvolvedor sempre vão ser diferentes e versões diferentes de cada pacote vão estar sendo usados em cada lugar aí a gente nunca sabe

de onde tá vindo muitos bugs se é problema no código ou se é dependência conversões erradas repetindo toda dependência deve está declarada no arquivo de Manifesto como o kompozer ponto de isso no nosso projeto de exemplo ou pack de ponto já sou um projeto longe e tanto na máquina do desenvolvedor quanto o script de depois como do heroku Vamos mudar o mesmo comando para baixar as dependências como composé pendente o npm instal da vida e em todos os lugares vamos garantidamente ter as mesmas dependências na Sesau e depois necessárias isso é essencial e novamente projetos

que não estão assim demonstra a incapacidade da gerência do projeto o terceiro fator se chama configuração em resumo foi o que eu expliquei no tutorial sobre a diferença de configuração na máquina de desenvolvimento usando recursos do Frei porque carrega arquivos como ponto envie o algum arquivo Jason da vida variáveis de ambiente todo Frei porque competente permite Executar a aplicação em ambientes distintos para desenvolvimento testes e produção no mínimo isso porque em desenvolvimento Queremos mais detalhes de erros mais bibliotecas de de bang monitoramento mas em produção não queremos divulgar nenhum detalhe de erros e nem desperdiçar

memória carregando bibliotecas que só servem em desenvolvimento em cada um desses ambientes precisamos de variáveis de configuração diferentes para um ambiente de testes precisamos conectar no banco de dados de teste por exemplo um não mandar sms ou É verdade estou lugar que tem tomada Tudo isso precisa tá facilmente configurável em variáveis de ambiente leia os detalhes sobre configuração do seu Framework tem muitas nuances que você precisa estudar e testar com calma o fator quatro é mais relevante se você já é um programador das antigas Quem estava tudo no servidor Como já expliquei inúmeras vezes que

não deveria com estético muhlenkamp para você havia diferença no banco de dados que rodam no mesmo local rosto da sua aplicação web é um serviço externo de enviar e-mails por exemplo uma aplicação 12 fatores não existe essa distinção tudo é um serviço externo ou um recurso externo acessível bioma URL nada a roda junto do container da sua aplicação web tudo roda externamente Esse é o quarto fator backing Services é estritamente proibido instalar o servidor mais seco junto com o redes um sistema de fios como have time to Kill no mínimo do se tiver um hardware

parrudo cada serviço deve tá rodando isolado no seu próprio container ou máquina virtual mesmo na sua máquina de desenvolvimento se possível não estar e tudo junto pode cada coisa não container docker e Orquestra tudo com docker-compose estúdio sobre docker-compose Experimente transformar seu projeto tradicional um conjunto de container é até uma boa forma de garantir que você não larga o conexões hardcoded para local rosto que vai funcionar na sua máquina de desenvolvimento mas vai falhar em produção o fator 5 é mais específico para quem mexe com infra mas é sobre separar a fase de Build a

fase de execução lembra como toda vez que fazemos de tipo xeroco eu falei que o heroku criar uma nova imagem semelhante ao que o docker faz quando executamos docker build é isso que eu quero dizer antigamente a gente fazia o equivalente bild manualmente copiando arquivos via FTP E logo na sequência já executaremos a aplicação e deixaríamos o pior se tivesse alguma vizinho normal era abrir um SSH para o servidor ou Deus me livre via telnet editar algum arquivo manualmente direto lá e pronto era super fácil e também a raiz de milhares de problemas primeiro porque

tudo que você editou na mão direto no servidor não tá no repositório de código se der pau no servidor você perde a modificação e tudo para de funcionar e ninguém sabe por quê Voltamos ao fator um que declaro aqui sem por cento de tudo deve sempre estar um repositório Git segundo porque Digamos que queremos voltar uma renise como expliquei que o heroku faz não tem como porque todo o novo depois sobre escreve em cima da versão antiga de maneira permanente mais gerando builds Sempre vamos ter uma cópia da imagem antiga e podemos facilmente voltar para

ela e como cada imagem não depende de pacotes específicos do sistema operacional tudo que ela precisa para rodar tá na imagem portanto trocar imagens é uma operação trivial é feita dezenas de vezes e vai funcionar em todas as vezes sem depender de nenhuma pessoa entrando no servidores subindo coisas manualmente o fator 6 provavelmente é um dos mais difíceis de entender se você é um iniciante ela se chama processos mas na verdade é o fator que define que sua aplicação deve ser cherfen ou mais corretamente stations sem Estado o exemplo mais simples ele só aplicação nunca

deve gravar nada no sistema de arquivos por exemplo Digamos que você faça uma página para fazer upload de fotos para colocar na página de perfil de cada usuário você segue um tutorial qualquer que manda aí gravando tudo um diretório chamado uploads no servidor e tudo vai funcionar perfeitamente até você fazer um novo depois morrer ou outro sistema de container E aí vai descobrir que todas as suas fotos sumiram os únicos arquivos que existem na sua aplicação são aqueles que existiam na fase de Bill de da imagem que é o código-fonte do Barcelona Beach as bibliotecas

O Pensador de dependências como com ponto baixo e outros arquivos gerados por scripts executados no bild como arquivos JavaScript compilados por um webpack uma vez que a bild foi fechada ela não pode mais ser modificada é para ser considerada brinde homem daí vocês vão lembrar que eu falei durante o tutorial que o heroku vai derrubar os danos que estavam executando a versão antiga e subindo novos dai-nos com a imagem nova entenderam quando o container desligado tudo que tava nele é perdido por exemplo as fotos no diretório upload quando um novo dai no subir os únicos

arquivos que vão ser carregados são os que estão na imagem que acabamos de construir o caso de um docker na sua máquina local a mesma coisa mas você tem a opção de material um diretório externo fora do contêiner e remontar esse diretório quando subiu container de novo daí os arquivos ainda persistem mas sempre fora do contêiner tudo dentro do container deve ser considerado efêmero o que você quer que sobreviva um depois deve Obrigatoriamente estar no armazenamento externo um back in service como descrito no fator 4 por exemplo um banco de dados como post visou redes

E no caso de arquivos um serviço como a ws-3 ou azure blob um google-cloud-storage da vida tem várias outras opções mesma coisa Love Is por isso certo adicionar é dons como um tempero treino qualquer log que foi gravado com o arquivo dentro do container vai ser perdido no próximo depois e esse é o jeito certo de fazer aplicações web vamos falar mais sobre o login no final o fator 7 não é tanto uma preocupação para nós desenvolvedores esse pessoalmente hoje em dia ele só declara que todo serviço que precisamos deve estar exposto numa porta de

rede como Nossa aplicação web Que costuma estar exposta em portos com 13 mil 8080 ou mais cinco Que costuma tá lá porta 3601 e assim por diante isso eu acho que é mais para dizer que não devemos usar serviços que não estejam expostos em pó e pense no serviço Crohn que existe em todos os meninos e serve para esquerdo lá tarefas a gente configura no arquivo para executar algum comando em alguma determinada hora do dia ou periodicamente tipo todo dia às quatro da manhã se for um backup único ponto de contato com esse serviço é

vinho arquivo de configuração por isso não podemos usar Chrome uma infraestrutura dessas com vários com tênis que não permite modificar arquivos localmente em vez disso vamos usar um software as a service um saco que adiciona uma aplicação web na frente do cron ele vai ser instalado como um back in service um serviço externo e nossa aplicação web vai interagir com esse serviço via http conectando na porta web dele assim a requisição pode sair de qualquer um dos nossos contêineres web e todos vão consistentemente chegar no mesmo serviço sempre assim como já chegam em outro serviço

ficou no banco de dados o fator 8 se chama concorrência e meio que só deriva dos fatores anteriores ele declara que as a escala é horizontal ou seja como Nossa aplicação é chernoff ou seja não depende nem um estado específico da máquina Onde está e como já é tudo organizado como Bill diz que podemos subir como container em qualquer maker' podemos rapidamente aumentar ou diminuir a quantidade de container horizontalmente esse fator é inspirado no jeito em Unix de pensar onde tudo são processos EA forma de escalar da forte em mais processo mesmo quando usamos algumas

linguagens como Java Script o inixi que permite fazer Multiplex envia trade ou assíncronos dentro de cada processo ainda assim sempre vai está limitado pelo tamanho da máquina Onde está rodando e quando esses recursos exaurir vai precisar escalar o horizontalmente de qualquer jeito escalabilidade exige expansão e contração horizontal que é mexer na quantidade de container e ou na quantidade de máquinas físicas particularmente o heroku facilitar isso porque quando você escala horizontal o percebe vai precisar de um load balancer na frente para distribuir a carga de requisições é algo que se você só subiu aplicações pequenas nunca

teve que pensar porque só tinha um servidor web e todas as requisições irão direto para ele com mais um servidor web você precisa de um balanceador de carga Como and next to wait at proxy na frente um é louco da vida já te dá esse balanceador por padrão de forma transparente o fator nove é um pouco mais avançado de entender eu recomendo estudar sobre sinais de processos consegui Therm O que é chat dar um gracioso e conceitos como vou estar mas na prática esse fator fala sobre descartabilidade Você já viu isso na prática um tutorial

toda vez que fizemos de tipo scherrer ou ele faz a bild de uma nova imagem e descarta os conselhos antigos para subir novos é isso que significa ser descartável uma vez que garantimos que não dependemos de nada dentro do container todos os dados estão seguros no banco de dados ou outros serviços como PS3 parques remoto podemos facilmente descartar container para fazer depois de uma nova release o download Beck para realizar anteriores antigamente quando a gente está lava tudo no mesmo servidor não dava para fazer isso esse a máquina era invadida por um hacker é impossível

recuperar uma máquina comprometida o certo é jogar tudo fora e remontado 0 mas se você ainda estava coisas via SSH direto um servidor se parte do que mudava não tava no Beach esse só aplicação gravava upload log localmente como arquivos e agora como você vai conseguir reinstalar essa máquina o mais rápido possível e a resposta é simples não vai um sistema robusto precisa ser descartável você precisa conseguir apagar o servidor inteiro e reinstalar tudo automaticamente inscrito sem perder um bit de dados em poucos segundos o ponto 10 É para reforçar o que eu acabei de

falar que é manter ambientes de desenvolvimento stayed produção mais similares quanto e isso obviamente significa tudo em repositório Git significa builds automatizados significa jamais editar arquivos direto no servidor os benefícios de fazer as coisas dessa forma é que gerenciar a infraestrutura se torna muito mais fácil quase trivial em alguns casos é assim que nasce a área de devops de verdade mais do que isso esse fator significa fazer depois para esteja em produção o mais rápido quanto possível ela tá próximo do que tá rodando na máquina dos desenvolvedores nada disso De demorar um mês ou mais

para fechar uma release mandar para a produção estude sobre continue os depoimentos plataformas community hanbit Leme Tem configurações para criar builds e rodar os testes da sua aplicação a cada novo convite que aparece esse tudo passar eles fazem automaticamente o bit puxa é louco para estágio ou para produção parece perigoso esse de subir para servidores automaticamente mas só é perigoso se isso e é uma droga a quantidade de bugs em produção reflete inversamente a qualidade de comunicação da sua equipe uma equipe disfuncional vai subir porcaria para produção não importa quantos mecanismos de gerenciamento você coloca

em cima deles uma equipe saudável revisão o código do outro antes de emergir um pug Quest Na breakmen do vídeo uma equipe saudável sempre adiciona testes para cada nova funcionalidade sempre adiciona testes que simulam Bang recém reportado dessa forma esse bug não vai aparecer de novo no futuro uma equipe saudável e implementa novas funcionalidades atrás de um Fiat Flag seja Bia variável de ambiente o via permissão para determinados usuários testarem e pelos demais usuários não conseguir enxergar essa nova funcionalidade até toda equipe de chance de testar e aprovar ou seja mesmo a desculpa que uma

nova funcionalidade vai levar semanas para ficar pronto não é justificativa suficiente para e integrando o código no repositório com frequência e não tá fazendo depois com frequência quanto mais se demora para integrar e depois mais rápido aumenta a quantidade de bugs e conflitos é inevitável existem diversas estratégias de comunicação e organização que uma equipe saudável pode aplicar e eu acabei de descrever algumas estude sobre testes integração continue e depois continuo só equipes disfuncionais e um com pés em uma gerência são incapazes de trabalhar de forma integrada e contínua lembre-se não importa linguagem um frame produtividade

bancos tudo isso é Reflexo da qualidade de comunicação de uma equipe sempre o fator 11 de novo é meio específico para quem desenvolve Frei mais mas fala sobre logs serem Strings em vez de arquivo todo bom sistema Manda logo pro STD Audi se por acaso você começou aprender sobre o Logos cotação de logs e cor Não esquece de um container todo serviço deve escrever logo STD out sempre daí a porta forma de infraestrutura como o heroku vai capturar esses trens e mandar para algum serviço externo de logs como paper Trail que eu mostrei mais fica

a dica que um sistema de log que tenta fazer coisas de mais uma hora vai dar catástrofe que foi que aconteceu com o caso recente do login Ford é bem coisa de Janeiro enterprise fazer uma mísera biblioteca de log por alguma razão vou além permite executar comandos que vem no blog e ainda vem junto com bibliotecas de um cap de jndi que se conecta com o mundo exterior é um cúmulo da estupidez para dizer o mínimo um blog Ford nem precisa muito existir pelo menos não do jeito como é hoje todo log deve para STD

alcinha um serviço externo separado como logo esteche que bana e coisas assim que deveriam consumir esses logs e organizar isso é fruto daquela mentalidade a x print Pensa a esse amanhã eu precisava essa opção Isso tá errado nunca faça coisa que não precisa para hoje o dia que a necessidade aparecer aí pensa Qual a melhor forma de resolver mas não faça nada porque tem chances de amanhã precisar isso é sofre desnecessário e todo software desnecessário é um buraco de segurança esperando para ser descoberto e finalmente o fator 12 que fala de processos de administração que

eu já mostrei no tutorial para vocês a ideia que você nunca haviam SSH direto para uns container web toda a tarefa administrativa Fora do Comum deve ser executado num container isolado e separado dos demais sem concorrer com os mesmos recursos com as requisições de usuários lembram quando eu rodei heroku Run Bash que abriu um container direto no Bash ou quando eu rodei heroku p-gps Kelly que abriu o console do post para criar tabela que faltava em ambos os casos ver o consumiu um novo com e com a imagem da última release ou seja idêntico ao

conteúdo dos contêiners web mais fora do load balancer assim o rodo no mesmo ambiente quando terminar um desconectar esse container é automaticamente destruído e isso é importante lembra o fator sobre descartabilidade os doze fatores foram muito influente quando foram lançados porque na época o único frame que implementava com sucesso todos os fatores eram Ruby on rails levou um tempão para os outros não alcançarem esse mínimo produtos open source que não usavam nenhum fremmer como o WordPress é um a gente não implementavam todos os 12 fatores por padrão e também levou um tempão para se adaptarem

o rei louco foi lançado entre 2008/2009 só uns dois anos depois que a mão uma WS apareceu naquela época maioria de nós só tinha mentalidade de servidor virtual no máximo VPS ninguém pensava em particionar recurso da mesma máquina em container e muito menos precificar por container e ainda tava anos de ser lançado e na verdade muito do docker foi influenciado pelo heroku a água não estava muito à frente do seu tempo tanto que ninguém sabia exatamente qual a melhor forma de tirar proveito dessa ideia de infraestrutura elástica o que significava se elástico como lidar com

máquinas volantes e descartáveis que quando reiniciam apaga tudo que tinha dentro o heroku foi a primeira plataforma como serviço Ou passa que de fato soube aproveitar a infraestrutura que a WS estava oferecendo um sonho de muitas empresas têm um heroku privado famoso Paiva de Cláudio onde equipes internas poderiam facilmente da gente puxa eu depois aconteceria automaticamente muitas empresas já trabalham assim é o que todo mundo que tem que instalar Uber nets busca o que o relevo chama de Dai no supernet chama The Police a linha de comando cube CTL é inspirado na linha de comando

do heroku enfim se você lida com Devotos de alguma forma hoje em dia tem a certeza é uma coisa foi inspirado no heroku Esse parece Fanboy falando pode dizer que eu sou mesmo porque a imagem 10 anos entregando o projetos de verdade para cliente eu ainda não vi outra solução que chega perto em termos de simplicidade e flexibilidade organização e custo-benefício muitos acham caro a parte de 30 dólares por dai-lhe é mesmo e fazem a conta comparando com o preço bruto da hora de uma máquina no ec2 mas a conta tá errada a conta certa

é calcular quanto custa ter uma pessoa experiente de devops de plantão todo dia para manter sua entra o cálculo certo não é da máquina mas do cara de devops que você não precisa ter quando usa o heroku e aliás antes que alguém vai nos comentários dizer sim eu sei que existem soluções como do coco que implementam um erótico Light que você mesmo pode instalar no VPS da vida você também pode usar direto docker-machine para orquestrar suas vs mas de novo você precisa adicionar o custo de alguém de infra a atenção nisso nunca vai ser plug-in-play

que uma vez instalado ninguém mais precisa mexer não caia nessa armadilha Além disso tem soluções como o Google Fire base aqui como o Google é pende antes dele você programa especificamente para essa plataforma e vai depender para sempre do que o Google te oferecer esquece de querer mudar para o azure ou a WS depois esquece que usar qualquer ferramenta open-source ele me deu o teclas que a plataforma não suporta tudo tem prós e contras e o meu ponto é correr ou com oferece o melhor custo-benefício entre conveniência segurança e independência do seu projeto também vale

relembrar que gerou cwe12 fatores não são balas de prata eu tenho um caso para ilustrar lá por 2014 eu tava pessoalmente trabalhando num projeto para cliente que envolvia uma ferramenta que seria usado por vestibulandos era uma plataforma de educação e os donos tinham expectativa que havia uma montanha de alunos de cursinho por causa de algum evento que eu não lembro mais o que era mas em resumo eles pediram a mente os sistemas e escalável eu e minha equipe fizemos tudo em Ruby on rails que é o Freio que funciona melhor no heroku especialmente naquela época

porque o próprio heroku é em boa parte feito em ganhos também fizemos depoimento mas na hora do vamos ver sofremos um gargalo obviamente foi culpa minha que não estimou direito o tamanho dos bancos de dados postgres o problema é o seguinte todo o banco de dados tem um máximo de conexões simultâneas que aguenta faz de conta que são sem mesmo implementando um Connection Pool seu escala horizontalmente aplicação ou seja aumentar o número de danos web rodando todos vão ser pendurado no banco de dados e rapidamente sem conexões vão ficar ocupados e novos darmos vão ficar

travado esperando conseguir uma nova conexão para lidar com isso a gente tenta mover o que não precisa pegar direto do banco em testes como registro Esse precisa muito do banco o certo é sobre vários outros servidores que são réplicas só de leitura do principal assim cada a réplica aguenta mais sem conexões simultâneas por exemplo mas não dá para colocar réplicas infinitamente Porque quanto mais réplicas têm maior o trabalho de replicação dos dados aí vai dar gargalo na sincronia de replicação muito iniciante quente no plataforma morrer louco achando que vai colocar um é donde altos que

eu e tudo vai escalar infinitamente sozinho se decepciona que não funciona mais para escalabilidade é uma combinação de funcionalidades e infraestrutura e arquitetura bem implementada depende mais do programador do que da infraestrutura mas se você for um bom programador um heroku da tudo que você precisa com um mínimo de esforço é impressionante o que eu consigo fazer sozinho um ambiente de se em cinco minutos coisa que no começo dos anos 2000 ia me custar dias de configuração já se você for um programador ruim nenhum heroku ou solução de cloud vai te ajudar só vai ser

um bandeide temporário eu já venho repetindo isso faz alguns Episódios eu vou repetir e eu tenho projetos para clientes que funcionam assim mas o certo como eu já disse antes é que os ambientes de estende produção não estejam muito longe da versão em desenvolvimento na máquina dos desenvolvedores para que isso seja possível precisa Obrigatoriamente seguir os seguintes passos primeiro Passos toda nova funcionalidade e toda correção de bugs deve vir acompanhado no mínimo de testes unitários todo polyquest tem testes deve ser automaticamente rejeitado sem exceções Essa é a principal regra que vai garantir que seu projeto

sobreviva por muitos anos no começo com pouca gente como um pouco o código com prazos apertados parece que é uma grande perda de tempo e assim que amadores pensam E é assim que amadores se ferro quando o projeto rapidamente cresce Fora de Controle quando você satisfaz essa primeira condição agora precisamos no segundo passo que integral código constantemente e frequentemente ou seja nenhum desenvolvedor Há dias e dias com código que só existe na sua máquina demorando para dar puxa com o repositório no Git Hub um Hit lésbica todo desenvolvedor deve no mínimo uma vez por dia

da pum ou seja puxar as últimas atualizações do repositório para pegar tudo que todo mundo da equipe ou trabalhando e da re bem e com seu grande desenvolvimento e corrigir conflitos e com sua suíte de testes unitários rapidamente ver o que quebrou e consertar imediatamente se você faz isso com frequência os conflitos são simples de resolver se der conflitos quanto mais tempo demora para integrar mais difícil vai ser no para resolver os conflitos no seu código com os outros programadores da equipe e maiores as chances de fazer bosta isso Birds isso é integração contínua facilita

muito se Como regra no meu três você tiver um usando algo community Leme que tem suporte Arruda testes automaticamente no servidor ou usar qualquer outra solução como circunstanciais você deixa um Blocker falha ao configurar e o bootleg vai dilda toda vez que alguém de puxa por repositório e colocar numa fila para rodar todos os testes automatizados se falhar já notifica para todo mundo e assim garantimos que todo o código que tá na frente nem sempre têm todos os testes ou dando e passando de objetivo é esse que sempre que alguém der clone do batimento tudo

sempre vai funcionar o Brent Man tem que ser sagrado tudo que tá indo acabado deve estar imbrantes de desenvolvimento separados essa condição que permite a próxima Regra número quatro que é toda vez que todos os testes automatizados passarem deve ser feito deprimente para um ambiente de stayed o heroku suporta que a parte Lines the stadium e produção assim você sempre tem uma infraestrutura Idêntica de testes e produção da Unity leve da vida faz o de tipo xeroco automaticamente Presidente e sua equipe pode imediatamente testado navegador como usuário normal para ver se nada realmente quebrou esse

as novas funcionalidades estão mesmo tô falando recapitulando uma equipe saudável e produtiva vai sempre desenvolver código com testes automatizado vai sempre integrar continuamente vai sempre ter um servidor de testes como hiit leve que roda a cada puxe cada desenvolvedor e finalmente vai sempre ter depois automáticos para ambiente de stayed toda vez que todos os testes automatizados passam e fica com opção sumir para produção automaticamente um deixar alguém de que a por exemplo responsável por fazer testes manuais no final e apertar o botão para depois a produção e liberar para os usuários um modelo similar ao

her oco Como projeto arquitetado para atender os doze fatores e com minhas últimas quatro regras é o que eu chamo do freio aqui mínimo para toda a equipe de desenvolvimento verdadeiramente ágil toda a outra metodologia sistema de backlog controles é opcional e não relevante para produtividade de verdade lei e a qualidade do software é diretamente proporcional à qualidade da comunicação da equipe não tem como fugir disso se sua equipe se comunica mal e porcamente seu software vai ser necessariamente uma grande droga a ideia hoje foi só apresentar para quem é iniciante como que profissionais de

verdade trabalho o gostariam de trabalhar e esse nível que vocês deveriam almejar alcançar se você trabalha no lugar que não funciona assim tente evangelizar o jeito certo vai implementando um aspecto de cada vez vai fazendo limpeza um pedaço de cada vez mesmo os projetos mais antigos e mais porcos é possível transformar um projeto eficiente primeiro a equipe entende que dá para melhorar e se comprometem a fazer limpeza e não aumentar mais a sujeira e por hoje é isso aí ficaram com dúvida semana e nos comentários abaixo você curtir o vídeo deixe um joinha e assine

o canal E compartilhe o vídeo com seus amigos a gente se vê até amanhã e