Se voc\u00ea est\u00e1 lendo isso, provavelmente est\u00e1 pensando em fazer a transi\u00e7\u00e3o para Continuous Deployment (CD)<\/strong>. Ou talvez voc\u00ea j\u00e1 tenha feito a transi\u00e7\u00e3o, mas ainda n\u00e3o sinta que est\u00e1 utilizando todo o potencial do seu pipeline de CD<\/strong>.<\/p>\n\n\n\n Fazer a transi\u00e7\u00e3o de releases<\/em> mensais (ou semestrais\u2026 ou anuais \ud83d\ude35\u200d\ud83d\udcab) para Continuous Deployment<\/strong> \u00e9 uma mudan\u00e7a recompensadora que trar\u00e1 benef\u00edcios para toda a sua organiza\u00e7\u00e3o. Mas, como em qualquer novo processo de desenvolvimento de software que voc\u00ea adota, h\u00e1 passos concretos que voc\u00ea precisar\u00e1 seguir para alcan\u00e7ar um pipeline de CD<\/strong> totalmente funcional.<\/p>\n\n\n\n Vamos gui\u00e1-lo por essas etapas para que sua equipe possa adotar o CD<\/strong>, independentemente da frequ\u00eancia com que voc\u00ea faz deploy<\/strong> de c\u00f3digo atualmente. Em seguida, explicaremos como essa mudan\u00e7a pode trazer benef\u00edcios tang\u00edveis para sua equipe ao fazer a transi\u00e7\u00e3o para o Continuous Deployment<\/strong> e alcan\u00e7ar um fluxo de trabalho mais eficiente e \u00e1gil.<\/p>\n\n\n\n Antes de entrarmos em como alcan\u00e7ar o Continuous Deployment<\/em><\/strong>, precisamos entender o que \u00e9 Continuous Deployment<\/em><\/strong> e onde ele se encaixa em todo o fluxo de trabalho de Continuous Integration<\/em>\/Continuous Delivery<\/em>\/Continuous Deployment<\/em><\/strong>.<\/p>\n\n\n\n Todos os pipelines de CI\/CD<\/em><\/strong> come\u00e7am com Continuous Integration (CI)<\/em><\/strong>. CI<\/em><\/strong> \u00e9 o processo de construir, verificar e executar testes automatizados que o seu c\u00f3digo precisa passar para ser mesclado \u00e0 branch principal.<\/p>\n\n\n\n A partir da\u00ed, passamos para Continuous Delivery<\/em><\/strong>, que \u00e9 o processo de garantir que o c\u00f3digo na branch principal esteja sempre em um estado implant\u00e1vel para que voc\u00ea possa fazer deploy<\/em><\/strong> quando quiser. O c\u00f3digo \u00e9 automaticamente enviado para um ambiente de testes nesta etapa, mas n\u00e3o \u00e9 implantado para os usu\u00e1rios finais at\u00e9 que voc\u00ea aperte manualmente o bot\u00e3o de “deploy”.<\/p>\n\n\n\n O passo final \u00e9 o Continuous Deployment<\/em><\/strong>. Continuous Deployment<\/em><\/strong> \u00e9 o processo de implantar automaticamente o c\u00f3digo para os seus usu\u00e1rios finais se ele tiver passado por todos os testes e etapas at\u00e9 a produ\u00e7\u00e3o. Quando falamos sobre transi\u00e7\u00e3o para CD neste artigo, estamos falando de Continuous Deployment<\/em><\/strong>. Este \u00e9 o objetivo final para a maioria das organiza\u00e7\u00f5es que desejam lan\u00e7ar c\u00f3digo v\u00e1rias vezes ao dia.<\/p>\n\n\n\n Pense no CI\/CD<\/strong> como o processo de eliminar a cerim\u00f4nia de release<\/em> de c\u00f3digo. Os dias de grandes releases<\/em> no final do m\u00eas, com uma quantidade massiva de mudan\u00e7as, ficaram para tr\u00e1s. Com CD<\/strong>, releases<\/em> pequenos e deploys<\/strong> acontecem com tanta frequ\u00eancia (idealmente v\u00e1rias vezes ao dia) que se tornam parte do tecido da sua empresa.<\/p>\n\n\n\n\n Ao conversar com l\u00edderes de engenharia, a maioria concorda que a transi\u00e7\u00e3o para CI\/CD<\/strong> deve ser gradual. (Portanto, n\u00e3o espere implantar continuamente 3 novas funcionalidades no segundo dia de ado\u00e7\u00e3o do CI\/CD<\/em><\/strong> \u2014 isso vai acabar muito, muito mal.)<\/p>\n\n\n\n \u00c9 recomend\u00e1vel come\u00e7ar com mudan\u00e7as menores e pequenos blocos de trabalho. Em vez de tentar passar de realizar releases<\/strong> tr\u00eas vezes por ano para v\u00e1rias vezes por dia, defina uma meta para realizar releases<\/strong> a cada duas semanas, depois semanalmente, depois diariamente, e, eventualmente, voc\u00ea estar\u00e1 fazendo releases<\/strong> v\u00e1rias vezes ao dia.<\/p>\n\n\n\n Nossa outra sugest\u00e3o \u00e9 se aproximar primeiro do Continuous Delivery<\/em><\/strong> antes de chegar ao Continuous Deployment<\/em><\/strong>. Claro, Continuous Deployment<\/em><\/strong> \u00e9 o objetivo final, mas o Continuous Delivery<\/em><\/strong> \u00e9 um pouco mais f\u00e1cil de estabelecer (e precisa estar bem estabelecido para que o Continuous Deployment<\/em><\/strong> aconte\u00e7a, de qualquer forma).<\/p>\n\n\n\n Lembre-se de que o Continuous Delivery<\/em><\/strong> \u00e9 o processo de garantir que seu c\u00f3digo na branch principal esteja sempre em um estado de implanta\u00e7\u00e3o \u2014 ou seja, voc\u00ea pode fazer deploy<\/em><\/strong> quando quiser, mas ele n\u00e3o ser\u00e1 automaticamente implantado. A partir daqui, voc\u00ea ainda ter\u00e1 que apertar manualmente “deploy” para liberar o c\u00f3digo para os usu\u00e1rios finais. Recomendamos almejar o Continuous Delivery<\/em><\/strong> antes do Continuous Deployment<\/em><\/strong> por algumas raz\u00f5es.<\/p>\n\n\n\n Primeiro, passar direto para o Continuous Deployment<\/em><\/strong> \u00e9 um grande salto para equipes acostumadas a releases<\/em><\/strong> manuais e a revisar manualmente seu c\u00f3digo antes de ser lan\u00e7ado para os usu\u00e1rios. O Continuous Delivery<\/em><\/strong> \u00e9 uma adapta\u00e7\u00e3o mais f\u00e1cil, pois permite que voc\u00ea verifique tudo antes de ser liberado para seus usu\u00e1rios finais.<\/p>\n\n\n\n Al\u00e9m disso, tornar-se confort\u00e1vel com o Continuous Delivery<\/em><\/strong> antes do Continuous Deployment<\/em><\/strong> d\u00e1 a chance de validar e confiar em seus testes. Quando voc\u00ea configura o Continuous Deployment<\/em><\/strong>, seus usu\u00e1rios finais veem todo e qualquer c\u00f3digo que tenha passado pelos seus testes, ent\u00e3o voc\u00ea precisa ter certeza de que seus testes s\u00e3o s\u00f3lidos (ou seja, que eles n\u00e3o est\u00e3o deixando passar c\u00f3digo com bugs e\/ou que os bugs que passam n\u00e3o s\u00e3o cr\u00edticos).<\/p>\n\n\n\n Com o Continuous Delivery<\/em><\/strong>, voc\u00ea tem a chance de ver como o seu c\u00f3digo est\u00e1 funcionando e valid\u00e1-lo manualmente depois de ter sido testado. Se voc\u00ea notar muitos erros e bugs no seu c\u00f3digo no ambiente de produ\u00e7\u00e3o, isso provavelmente significa que algo est\u00e1 errado com seus testes. Assim, come\u00e7ar com Continuous Delivery<\/em><\/strong> lhe d\u00e1 a chance de validar e garantir que seus testes est\u00e3o realmente cumprindo seu papel e n\u00e3o deixando passar c\u00f3digo com bugs antes de voc\u00ea avan\u00e7ar para o Continuous Deployment<\/em><\/strong>.<\/p>\n\n\n\n\n Nosso \u00faltimo conselho \u00e9 come\u00e7ar com mudan\u00e7as simples e atualiza\u00e7\u00f5es de baixo risco ao se ajustar ao CI\/CD<\/em><\/strong>. Admitidamente, ajustar-se ao CI\/CD<\/em><\/strong> leva tempo, confian\u00e7a e ades\u00e3o de toda a sua organiza\u00e7\u00e3o. Automatizar seus testes e deploys<\/em><\/strong> pode parecer assustador no in\u00edcio \u2014 especialmente para aqueles respons\u00e1veis por construir os testes. Come\u00e7ar com pequenas mudan\u00e7as de c\u00f3digo e atualiza\u00e7\u00f5es de baixo risco permite que sua equipe se ajuste ao processo e ganhe confian\u00e7a nele antes de passar para releases<\/em><\/strong> de funcionalidades maiores.<\/p>\n\n\n\n Uma vez que voc\u00ea se sinta confort\u00e1vel com Continuous Integration<\/em><\/strong> e Continuous Delivery<\/em><\/strong>, o Continuous Deployment<\/em><\/strong> o aguarda. Aqui est\u00e3o alguns passos pr\u00e1ticos que voc\u00ea pode seguir para configurar um pipeline de CI\/CD<\/em><\/strong> adequado (mesmo nas bases de c\u00f3digo mais antigas e complexas):<\/p>\n\n\n\n O primeiro passo \u00f3bvio \u00e9 configurar um pipeline de CI<\/em><\/strong>. Isso requer a constru\u00e7\u00e3o de seus testes e a configura\u00e7\u00e3o de um pipeline que garante que seu c\u00f3digo pode ser mesclado uma vez que tenha passado por esses testes.<\/p>\n\n\n\n O segundo passo \u00e9 ter um conjunto de testes (que voc\u00ea confie!) em vigor.<\/p>\n\n\n\n Uma vez que seu c\u00f3digo passe por esses testes automatizados com CD, ele ser\u00e1 liberado. Portanto, voc\u00ea precisa garantir que seus testes sejam confi\u00e1veis o suficiente para que voc\u00ea n\u00e3o precise revisar manualmente seu c\u00f3digo depois, porque voc\u00ea n\u00e3o apertar\u00e1 manualmente “deploy” uma vez que seu c\u00f3digo passe por eles.<\/p>\n\n\n\n No in\u00edcio, seus testes n\u00e3o precisam ser extremamente complexos, pois o CD<\/strong> n\u00e3o ser\u00e1 usado para mudan\u00e7as complexas de imediato. O foco deve estar em testes de ponta a ponta que, no m\u00ednimo, confirmem que o site ou plataforma funciona conforme o esperado pela equipe. Por exemplo, esses testes b\u00e1sicos de ponta a ponta garantiriam que os usu\u00e1rios possam acessar, fazer login e realizar a\u00e7\u00f5es essenciais dentro da plataforma.<\/p>\n\n\n\n Eventualmente \u2014 quando voc\u00ea tiver um pipeline de CI\/CD<\/em><\/strong> totalmente desenvolvido e estiver usando-o para quase todos os deploys<\/em><\/strong>, independentemente do tamanho e impacto \u2014 voc\u00ea vai querer ter testes mais complexos e abrangentes. Mas para o prop\u00f3sito de hoje de apenas come\u00e7ar com CI\/CD<\/em><\/strong>, testes b\u00e1sicos s\u00e3o tudo o que voc\u00ea precisa.<\/p>\n\n\n\n Isso garante que, quando um erro acontecer (ou seja, quando um c\u00f3digo com bugs passar por todos os seus testes automatizados e for liberado para seus usu\u00e1rios finais), voc\u00ea seja capaz de rastrear de onde ele veio e corrigi-lo rapidamente. N\u00e3o estamos de forma alguma sugerindo isso para criar uma cultura de culpa. \u00c9 simplesmente um passo necess\u00e1rio quando voc\u00ea est\u00e1 automatizando grande parte do seu processo de teste e deploy<\/em><\/strong>.<\/p>\n\n\n\n Al\u00e9m disso, a boa not\u00edcia sobre CI\/CD<\/em><\/strong> \u00e9 que voc\u00ea est\u00e1 implantando mudan\u00e7as de c\u00f3digo menores e incrementais v\u00e1rias vezes ao dia, em vez de grandes mudan\u00e7as de c\u00f3digo com um impacto massivo de mudan\u00e7as uma vez por m\u00eas. Assim, usar uma plataforma de gerenciamento de erros com CI\/CD<\/em><\/strong> \u00e9 um processo muito mais simples, j\u00e1 que as releases<\/em><\/strong> s\u00e3o t\u00e3o pequenas que \u00e9 mais f\u00e1cil encontrar exatamente onde est\u00e1 o problema.<\/p>\n\n\n\n J\u00e1 mencionamos que a transi\u00e7\u00e3o para Continuous Deployment<\/em><\/strong> pode ser um grande ajuste para equipes acostumadas a revisar manualmente cada detalhe.<\/p>\n\n\n\n Automatizar o processo de testes e deploys<\/em> acelera tudo, eliminando a necessidade de interven\u00e7\u00e3o humana, o que permite que seus desenvolvedores passem mais tempo codificando. No entanto, abrir m\u00e3o dessa interven\u00e7\u00e3o manual pode ser assustador. Usar feature flags<\/em><\/strong> junto com o CI\/CD<\/em><\/strong> \u00e9 como adicionar uma camada extra de seguran\u00e7a, uma rede de prote\u00e7\u00e3o que aumenta a confian\u00e7a da equipe nos deploys<\/em> autom\u00e1ticos.<\/p>\n\n\n\n As feature flags<\/em><\/strong> permitem que os desenvolvedores ativem ou desativem funcionalidades sem a necessidade de fazer um novo deploy<\/em> do c\u00f3digo. Elas funcionam como uma rede de seguran\u00e7a para qualquer equipe de desenvolvimento que utiliza CI\/CD<\/em><\/strong>, j\u00e1 que facilitam o processo de desativar uma funcionalidade que n\u00e3o est\u00e1 se comportando corretamente. Assim, caso um c\u00f3digo com defeito passe pelos testes automatizados e chegue \u00e0s m\u00e3os dos seus usu\u00e1rios, voc\u00ea pode simplesmente desligar a funcionalidade e seus usu\u00e1rios voltar\u00e3o a utilizar a funcionalidade anterior \u2014 tudo isso sem a necessidade de fazer um novo deploy<\/em> ou atualizar a aplica\u00e7\u00e3o.<\/p>\n\n\n\n A ado\u00e7\u00e3o de CI\/CD<\/strong> em uma base de c\u00f3digo completamente nova \u00e9 geralmente mais simples, pois permite a escolha de ferramentas e processos desde o in\u00edcio, al\u00e9m de possibilitar a cria\u00e7\u00e3o de testes do zero. No entanto, \u00e9 perfeitamente poss\u00edvel implementar CI\/CD<\/strong> em bases de c\u00f3digo existentes e mais antigas, mesmo que sejam sistemas legados.<\/p>\n\n\n\n Muitas organiza\u00e7\u00f5es j\u00e1 conseguiram migrar grandes bases de c\u00f3digo para um pipeline de CI\/CD<\/strong> funcional. Esse processo envolve a transi\u00e7\u00e3o de releases<\/strong> espor\u00e1dicas, como a cada poucos meses, para um pipeline de Continuous Delivery<\/strong>, que possibilita realizar releases<\/strong> com muito mais frequ\u00eancia, como semanalmente. Durante essa transi\u00e7\u00e3o, aprendem-se li\u00e7\u00f5es valiosas sobre o que testar, como otimizar as builds<\/strong>, e como automatizar os deploys<\/strong>, preparando o caminho para a implementa\u00e7\u00e3o de um pipeline de Continuous Deployment<\/strong> totalmente funcional.<\/p>\n\n\n\n\n O Continuous Deployment<\/em><\/strong> nos permitiu colocar c\u00f3digo em produ\u00e7\u00e3o em apenas 15 minutos. Esse \u00e9 um grande aumento na frequ\u00eancia de deploys<\/em> em compara\u00e7\u00e3o ao ciclo de lan\u00e7amento de 3,5 meses que t\u00ednhamos com o Taplytics. Agora, podemos lan\u00e7ar e iterar mais r\u00e1pido, responder ao feedback dos usu\u00e1rios em tempo real e fazer deploys<\/em> de c\u00f3digo v\u00e1rias vezes ao dia.<\/p>\n\n\n\n Quando seus desenvolvedores n\u00e3o precisam testar e implantar o c\u00f3digo manualmente, eles ganham muito mais tempo para realmente escrever c\u00f3digo. O Continuous Deployment<\/em> (CD) alivia significativamente os desenvolvedores do processo de QA e deploy, permitindo que eles concentrem seu tempo e energia no desenvolvimento de novas funcionalidades e melhorias.<\/p>\n\n\n\n Automatizar os testes e deploys<\/em> com CI\/CD<\/em><\/strong> fez com que nossos desenvolvedores realmente refletissem sobre o trabalho que est\u00e3o fazendo. Eles precisam se perguntar “Este c\u00f3digo est\u00e1 bem testado?” e “Ele est\u00e1 bem planejado?” j\u00e1 que dependem do sistema de verifica\u00e7\u00f5es que eles mesmos criaram para os testes automatizados.<\/p>\n\n\n\n Qualquer release<\/em> feita com CD<\/em><\/strong> \u00e9 pequena o suficiente para que seja muito f\u00e1cil identificar bugs. Em releases<\/em> grandes, com mudan\u00e7as extensas, pode levar semanas para encontrar um bug. Com o CD<\/em><\/strong>, se algo der errado, voc\u00ea sabe a qual release<\/em> o bug pertence, e a corre\u00e7\u00e3o do problema leva menos tempo.<\/p>\n\n\n\n Como fazemos deploys<\/em> de pequenas e incrementais mudan\u00e7as com CD<\/em><\/strong>, os riscos s\u00e3o muito menores e nossos desenvolvedores n\u00e3o sofrem mais com a “ansiedade p\u00f3s-lan\u00e7amento” que sentiam com os lan\u00e7amentos mensais. Sem os grandes lan\u00e7amentos, podemos enviar o c\u00f3digo com confian\u00e7a, sabendo que, provavelmente, nenhuma de nossas mudan\u00e7as ir\u00e1 impactar ou quebrar toda a nossa plataforma. E se houver algum problema no c\u00f3digo, sabemos que podemos facilmente reverter as mudan\u00e7as ou desativar a funcionalidade com feature flags<\/em><\/strong>.<\/p>\n\n\n\n A transi\u00e7\u00e3o para o Continuous Deployment<\/em><\/strong> \u00e9 uma grande mudan\u00e7a que requer o comprometimento de toda a sua organiza\u00e7\u00e3o para funcionar. Embora possa levar algum tempo para se ajustar e possa haver um per\u00edodo de tentativas e erros na configura\u00e7\u00e3o do pipeline, o per\u00edodo de adapta\u00e7\u00e3o vale a pena. Uma vez que seu pipeline de CD<\/em><\/strong> esteja configurado e funcionando corretamente, voc\u00ea estar\u00e1 implantando com mais frequ\u00eancia e automatizando mais do que jamais imaginou ser poss\u00edvel.<\/p>\n\n\n\n Introdu\u00e7\u00e3o A transi\u00e7\u00e3o para Continuous Deployment (CD) \u00e9 uma jornada que pode parecer desafiadora \u00e0 primeira vista, mas os benef\u00edcios para a sua organiza\u00e7\u00e3o s\u00e3o incontest\u00e1veis. Se voc\u00ea est\u00e1 acostumado a ciclos de lan\u00e7amento prolongados, como mensal, semestral ou at\u00e9 anual, a ado\u00e7\u00e3o do CD pode transformar completamente o modo como voc\u00ea entrega software. Ao […]<\/p>\n","protected":false},"author":1,"featured_media":1720,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[299,296,294,26,295,297,298],"tags":[301,302,303,300,304],"_links":{"self":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1646"}],"collection":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1646"}],"version-history":[{"count":21,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1646\/revisions"}],"predecessor-version":[{"id":1711,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1646\/revisions\/1711"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media\/1720"}],"wp:attachment":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1646"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1646"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1646"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/www.erudio.com.br\/blog\/wp-content\/uploads\/2024\/09\/senior-developer-vs-lead-developer-1128x635-1-1024x576.jpg\")
<\/figure>\n\n\n\nO que \u00e9 Continuous Deployment?<\/strong><\/h3>\n\n\n\n
![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/27_CICD_JavaAWS.png\" "\\"Java")
\n<\/a>\n\n\n\nComo Alcan\u00e7ar o Continuous Deployment<\/strong><\/h3>\n\n\n\n
Fa\u00e7a uma transi\u00e7\u00e3o gradual<\/strong><\/h4>\n\n\n\n
Almeje o Continuous Delivery primeiro, depois mova-se para o Continuous Deployment<\/strong><\/h4>\n\n\n\n
![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/28_CICD_JavaAzure.png\" "\\"Java")
\n<\/a>\n\n\n\nComece com mudan\u00e7as simples e de baixo risco<\/strong><\/h4>\n\n\n\n
Passo 1: Configure seu pipeline<\/strong><\/h4>\n\n\n\n
Passo 2: Testes<\/strong><\/h4>\n\n\n\n
Passo 3: Configure logging<\/em> centralizado ou gerenciamento de erros<\/strong><\/h4>\n\n\n\n
Passo 4: Use feature flags<\/em><\/strong><\/h4>\n\n\n\n
Implementa\u00e7\u00e3o de CI\/CD em Sistemas Legados<\/strong><\/h4>\n\n\n\n
![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/07-rest-spring-java.png\" "\\"REST")
\n<\/a>\n\n\n\nOs Benef\u00edcios do Continuous Deployment<\/strong><\/h3>\n\n\n\n
Aumenta a frequ\u00eancia de deploys e diminui o tempo de ciclo<\/strong><\/h4>\n\n\n\n
Aumenta a produtividade dos desenvolvedores<\/strong><\/h4>\n\n\n\n
Melhora a qualidade do trabalho dos desenvolvedores<\/strong><\/h4>\n\n\n\n
Facilita a depura\u00e7\u00e3o<\/strong><\/h4>\n\n\n\n
Menos estresse, mais confian\u00e7a<\/strong><\/h4>\n\n\n\n
Conclus\u00e3o<\/strong><\/h3>\n\n\n\n
Treinamentos relacionados com essa postagem<\/h2>\n\n\n
\n<\/a>\n
\n\t![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/09-docker.png\" "\\"Docker")
\n<\/a>\n\n ![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/14-microservices-java.png\" "\\"Microservices")
\n<\/a>\n\n ![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/22-ms-kotlin.png\" "\\"Microsservi\u00e7os")
\n<\/a>\n\n ![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/15-microservices-dotnet.png\" "\\"Arquitetura")
\n<\/a>\n\n ![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/24-tests_java.png\" "\\"Java")
\n<\/a>\n\n \n<\/a>\n\n \n<\/a>\n\n ![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/01-rest-asp.png\" "\\"REST")
\n<\/a>\n\n ![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/18-rest-spring-kotlin.png\" "\\"REST")
\n<\/a>\n![](\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/10-docker-to-aws.png\" "\\"Docker")
\n<\/a>\n","protected":false},"excerpt":{"rendered":"