Guia de DevOps para iniciantes!

1. Introdução ao DevOps: Bem-vindo a esta aula da Skillshare sobre DevOps para iniciantes. Se você está curioso sobre o que é DevOps, as ferramentas e tecnologias que ele envolve e como ele está moldando o setor de tecnologia, você chegou ao lugar perfeito Nesta aula, abordaremos os fundamentos do DevOps, o é e por que ele é importante, os principais objetivos de aprendizado, como entender a automação, o CSED e a infraestrutura como código, e a infraestrutura como código, um roteiro claro para guiá-lo passo a passo em sua jornada de aprendizado sobre DevOps, uma introdução às ferramentas e tecnologias que impulsionam o DevOps, uma introdução às ferramentas e como Jenkins, Doc ou Kubints and Moore como Jenkins Dando a você uma compreensão sólida sobre o que é usado no setor. Esta aula foi projetada para iniciantes absolutos, seja você um estudante, um desenvolvedor que deseja crescer ou um novato em tecnologia. Este curso permitirá que, ao final desta aula, você entenderá os conceitos essenciais do DevOps, tenha insights sobre as ferramentas e a tecnologia e esteja equipado com o roteiro para continuar aprendendo e desenvolvendo habilidades do mundo real e estar equipado com a função Então, vamos mergulhar e começar sua jornada de DevOps. 2. 0101 A criação do momento de DevOps: DevOps Os desenvolvedores trabalham para operações de TI. Os desenvolvedores tendem a ter o seguinte conjunto de responsabilidades. Eles codificam o aplicativo de acordo com os requisitos ou as histórias de usuário desse sprint Em seguida, eles criarão o projeto para criar um artefato ou um executável, que poderá ser implantado no servidor ou na inscrição de desenvolvimento para Eles também são responsáveis por testar todo o aplicativo, certificando-se de que todos os recursos estejam funcionando conforme o esperado e que nenhum dos recursos tenha sido interrompido devido às mudanças introduzidas recentemente. Se você tiver uma equipe de garantia de qualidade separada, eles se encarregarão de testar minuciosamente o aplicativo. Por outro lado, a equipe de operações de TI teria um conjunto diferente de responsabilidades. Eles são responsáveis por implantar o aplicativo no ambiente de teste ou de produção para que o aplicativo agora possa ser usado pelo cliente ou pelo usuário final Eles também são responsáveis por manter a infraestrutura necessária para implantar o aplicativo. Eles garantirão que sejam servidores e recursos adequados para ajudar a executar o aplicativo sem problemas Eles também monitoram constantemente o aplicativo quanto ao desempenho, integridade, utilização de recursos, avisos, erros, etc. Não, implantar o aplicativo não é uma tarefa fácil. Não é que você copie o artefato para o seu servidor e ele funcione magicamente Você precisa cuidar das dependências, bibliotecas e configurações que ajudarão a executar o aplicativo Muitas vezes, a equipe de operações não está familiarizada com essas etapas e, portanto, recebe ajuda dos desenvolvedores Assim, os desenvolvedores forneceriam um guia de implantação com instruções claras passo sobre como implantar o aplicativo. Ostam seguiria essas etapas, implantaria o aplicativo e o aplicativo estaria funcionando muito bem Até uma noite, o aplicativo trava ou alguns dos recursos quebravam Isso leva ao infame jogo de culpa o OpsTeam diria que em que o OpsTeam diria que seguiu todas as instruções do guia de implantação e, se o aplicativo ainda não estiver funcionando, cabe aos desenvolvedores Por outro lado, os desenvolvedores atribuirão a culpa ao OpsTeam , dizendo que seguiram as etapas exatas do guia de implantação e que funcionou para eles na inscrição no desenvolvimento Então, a culpa iria e voltaria , desperdiçaria muito tempo. Mas a verdade é que o erro pode ser de qualquer um. Pode ser que os desenvolvedores perdido uma etapa do guia de implantação, ou pode ser que a equipe de operações não tenha seguido bem as instruções, ou talvez tenha algo a ver com a alocação de recursos, ou talvez o OpsTeam tenha instalado uma versão diferente do software que não é suportada ou, na verdade, também pode ser um bug no código Talvez os desenvolvedores tenham cometido um erro. Por exemplo, os desenvolvedores podem ter escrito um código incorreto, que consome constantemente a memória a ponto de o sistema ficar sem memória e o aplicativo travar Isso pode não acontecer no registro de desenvolvimento porque eles não executam o aplicativo por tempo suficiente para que ele falhe, pois continuam reimplantando o aplicativo como quando introduzem alterações No entanto, isso pode acontecer no registro da produção, que o aplicativo ficaria em execução constante por um longo período de tempo Sendo eu mesmo um desenvolvedor no passado, verdade é muito frustrante ouvir algo assim da equipe de operações porque, de um modo geral, os desenvolvedores já estão ocupados implementando os novos recursos Eles têm novos compromissos, respondem perante o chefe e não estão dispostos a vasculhar os registros antigos que podem afetar seus compromissos atuais com o projeto Então, eles tentam evitar esses problemas simplesmente culpando a outra parte E o mesmo também é feito pela equipe de operações. Mas esse jogo de culpa desperdiça muito tempo e muitos problemas ficariam sem solução por um longo período de Portanto, até mesmo o lançamento seria adiado por semanas ou, às vezes, por meses, o que causaria frustração ao cliente, e você pode adivinhar as consequências disso Isso significa perda de receita e reputação para a empresa. Esse é o gatilho e o ponto de partida para o momento Da WOPs 3. 0102 O que é DevOps: Então, o que é DevOps? Qualquer coisa que possamos fazer para melhorar a eficiência da equipe, reduzir as chances de erro durante a produção, melhorar a comunicação entre as equipes e incentivar a comunicação entre equipes multifuncionais, reduzir o tempo de lançamento ou melhorar o processo geral é o que é DevOps E tudo isso pode ser feito com a combinação de mentalidade, filosofias e práticas culturais, ferramentas e automação com a combinação de mentalidade, filosofias e práticas culturais, ferramentas e automação. E se você me perguntar, o DevOps evoluiu tanto hoje em dia que tem menos a ver com mentalidade e filosofias culturais, mas mais a ver O que inicialmente começou como uma mudança de mentalidade agora evoluiu para ferramentas e automação, sobre as quais falaremos a seguir 4. 0103 Filosofias e práticas de mentalidade: Vamos falar sobre o aspecto mental do DevOps. Antes do DevOps, havia uma barreira psicológica entre os desenvolvedores e as operações de TI, na qual os desenvolvedores se concentravam mais em escrever o código e não se preocupavam com a inscrição na qual o aplicativo seria uma barreira psicológica entre os desenvolvedores e as operações de TI, na qual os desenvolvedores se concentravam mais em escrever o código e não se preocupavam com a inscrição na qual o na qual o A equipe de operações, por outro lado, nunca se preocupa em entender como o aplicativo funciona, suas dependências ou qualquer coisa relacionada ao Com o DeWOps, essa barreira seria quebrada e as duas equipes chegariam ao entendimento comum de que realmente trabalham juntas Agora eles começam a acreditar que são, na verdade, uma equipe. Se houver alguém a ser culpado em caso de problema, então não há ninguém a ser culpado, exceto Eles resolverão os problemas juntos como uma entidade. Na verdade, em certas organizações, não há uma equipe separada de desenvolvedores e operações. Eles podem se autodenominar desenvolvedores, mas na verdade fazem o trabalho tanto dos desenvolvedores quanto das operações de TI. Agora, esse é o aspecto mental do DevOps. Agora, vamos falar sobre algumas das filosofias e práticas culturais do DevOps incentiva a comunicação aberta e a colaboração entre as equipes, compartilhamento de conhecimento entre os membros da equipe Assim, os desenvolvedores podem ter uma sessão de compartilhamento de conhecimento com a equipe de operações e vice-versa, OpSTem pode ter uma sessão de compartilhamento de conhecimento com a equipe de desenvolvimento Reuniões regulares com equipes multifuncionais , como equipe de testes, equipe de segurança, etc Na verdade, antes do DevOps, Optim on nunca se preocupou em participar de nenhuma das reuniões de Mas agora eles estão realmente envolvidos em todo o ciclo de vida do produto, desde a coleta de requisitos. Na verdade, eles também comparecem à reunião para discussões de requisitos. Ampliando seu conjunto de habilidades. Assim, os desenvolvedores podem adquirir algumas das habilidades de operações e vice-versa. A equipe Oops adquire algumas das habilidades dos desenvolvedores. Uso de ferramentas colaborativas, sobre as quais falaremos daqui a pouco Uma coisa que devo mencionar é que o DevOps não é praticado da mesma forma em todas as organizações Dependendo do escopo do projeto e do tipo de tecnologia que eles estão usando, práticas e ferramentas do DevOp podem ser diferentes 5. 0104 Ambientes e ferramentas de DevOps: Os desenvolvedores precisariam de uma inscrição de desenvolvedor para testar suas alterações ou para suas atividades diárias Da mesma forma, a equipe de teste precisaria de uma inscrição para testar minuciosamente o aplicativo Da mesma forma, o IT OpStam também precisaria preparação ou inscrição na produção para implantar o implantar Para obter todas essas inscrições, provavelmente precisaríamos de servidores Anteriormente, costumávamos adquirir servidores e mantê-los por conta própria. Mas hoje em dia, usamos provedores de serviços em nuvem como o AWS Azure GCP Forneça infraestrutura como serviço, o que significa que, em vez de mantermos os servidores , eles farão isso por nós e fornecerão recursos como serviços como RAM, CPU, disco rígido, etc A vantagem de usar um provedor de serviços em nuvem é que ele é mais escalável, mais seguro também mais confiável e econômico em comparação com a compra de servidores físicos e manutenção deles por conta própria Criar uma infraestrutura não significa apenas lançar várias máquinas virtuais. Também precisamos cuidar de definir as configurações de rede, anexar volumes de armazenamento e até mesmo configurar outros serviços necessários, configurar outros serviços necessários como bancos de dados, etc Portanto, criar a infraestrutura forma consistente em todas as equipes sem cometer erros é na verdade, uma tarefa muito desafiadora e demorada. Para resolver esse problema, temos o terraform. O TerraForm oferece infraestrutura como código, o que significa que permitirá que você crie infraestrutura escrevendo código Por exemplo, você pode escrever um código dizendo que precisa um número N de servidores com mais ou menos RAM e mais ou menos disco rígido, e ele vai fazer exatamente isso. Isso nos permite criar inscrições semelhantes e consistentes em todas as equipes Você pode até mesmo reproduzir a mesma inscrição executando o script Depois de ter a infraestrutura ou os servidores, a próxima coisa que queremos fazer é instalar o sistema operacional. Agora, todos esses provedores de serviços em nuvem nos fornecem uma imagem de VM pronta que vem com o sistema operacional Portanto, ao iniciar as máquinas observadoras usando o Terraform, podemos escolher essa imagem para que a infraestrutura ou os servidores sejam criados junto com o sistema operacional Ou, alternativamente, você também pode usar uma ferramenta de gerenciamento de configuração como o NZB para instalar o sistema operacional nos servidores Falaremos sobre ansib daqui a pouco. Agora temos a infraestrutura e o sistema operacional. Tecnicamente, agora podemos implantar o aplicativo e colocá-lo em funcionamento Como membro da equipe DO, você pode fazer isso facilmente porque é uma pessoa técnica. Você conhece todas as bibliotecas, dependências e configurações necessárias para ajudar a executar o aplicativo No entanto, se você falar sobre algumas pessoas não técnicas, como da equipe de testes ou da equipe de operações de TI, elas não sabem como implantar o aplicativo e, portanto, confiam nos desenvolvedores para obter as instruções. E já falamos sobre as consequências dessa abordagem. Se a equipe do fornecer um guia de implantação , pode acontecer que não haja instruções suficientes no guia de implantação. Ou pode acontecer que a equipe de testes ou a equipe de operações não tenham implementado essas instruções exatamente como deveriam ser. Instruções exatamente como deveriam ser. E isso faria com que o aplicativo não funcionasse conforme o esperado e, eventualmente, levaria à culpa pelo atraso no lançamento do jogo, e assim por diante. Portanto, para resolver esse problema, agora temos o Docker Então, desta vez, em vez de implantar o aplicativo diretamente no sistema operacional instalando software, configurações, etc., ou fornecendo o guia de implantação para as outras equipes, agora vamos criar a chamada imagem do Docker Uma imagem Docker é essencialmente uma combinação de código, bibliotecas de tempo de execução Na verdade, é um pacote independente que inclui todas as dependências, bibliotecas e arquivos necessários para executar o aplicativo E usando essas imagens do Docker, podemos criar contêineres em diferentes ambientes Agora, para criar contêineres a partir dessas imagens, precisamos de uma plataforma que suporte isso, e é aí que a plataforma Docker entraria em cena Vamos instalar a plataforma Docker em cima do sistema operacional e agora poderemos criar contêineres ou imagens do Dockery Um contêiner do Docker é essencialmente uma instância em tempo de execução de uma imagem do Docker Se você estiver familiarizado com a tecnologia VMware , o Docker Image é equivalente ao VM Snapshot, e o contêiner Docker é equivalente uma versão em execução do Mas, diferentemente de uma máquina virtual, as imagens do docker são leves Ele não vem com um sistema operacional. Em vez disso, ele usaria o sistema operacional do host. De qualquer forma, esse será o tópico de outra palestra. Agora, em geral, talvez não tenhamos apenas uma imagem do Dockery que teria todo o aplicativo Se você estiver seguindo a arquitetura Microsovice, na qual seu aplicativo seria dividido em vários módulos menores, talvez você acabe tendo centenas de Manter essas imagens dockery manualmente é uma tarefa difícil, e é por isso que temos soluções de repositório de artefatos como Nexus atua como um repositório centralizado onde as equipes de desenvolvimento podem armazenar, compartilhar ou recuperar artefatos de software, como o Dockery Images Basicamente, permite fácil compartilhamento, colaboração entre equipes e até mesmo controle de versão de artefatos dentro das equipes de desenvolvimento ou em toda a organização E várias equipes da organização escolherão as imagens mais escuras dessas plataformas e criarão contêineres a partir e criarão contêineres a dessas imagens Então, você pode acabar tendo centenas de contêineres em execução, mas quando você tem tantos contêineres em execução, fica muito difícil gerenciá-los manualmente, e é aí que o Kubinidis entra Basicamente, ele fornece uma plataforma para orquestração de contêineres, facilitando a implantação, a escala ou gerenciamento dos contêineres do Docker a partir de um único painel Sem o Kubintis, é realmente impossível gerenciar tantos Até agora, temos uma inscrição consistente em todas as equipes Temos a infraestrutura, sistema operacional e até mesmo o aplicativo instalado e funcionando. Agora, e se eu quiser instalar um software, atualizar um software ou alterar uma configuração nessas inscrições Bem, não podemos entrar em todos os sistemas e fazer isso manualmente. É muito demorado, propenso a erros e seria muito inconsistente Então, para resolver esse mesmo problema, temos ferramentas como o Azb Chef Papet Com o AZB, você pode automatizar várias tarefas, como implantar o aplicativo, instalar um software, alterar uma configuração, etc Enquanto o Docker permite que você crie um registro de tempo de execução isolado com código de aplicativo, dependências, etc., o NZB, por outro lado, trabalha em cima do sistema existente para realizar várias tarefas no sistema para realizar várias tarefas Podemos usar o NZB para instalar o sistema operacional e até mesmo a plataforma Docker Essas são algumas das ferramentas usadas no DevOps para criar a inscrição Também temos várias outras ferramentas e falaremos sobre elas quando falarmos sobre as fases do DevOps, que virão logo em seguida 6. 0105 Fases de DevOps e suas ferramentas: Vamos falar sobre várias fases do DevOps e também entender os diferentes tipos de ferramentas usadas em cada uma dessas fases Primeiro, temos a fase de planejamento, envolve basicamente definir os requisitos do projeto, estabelecer as metas, dar capacidade individual e decidir quem fará o quê, etc E aqui podemos usar essas ferramentas. Precisamos de uma ferramenta de acompanhamento de projetos como o Jira, por exemplo, que é uma das ferramentas mais populares para acompanhar o projeto Aqui, podemos rastrear histórias de usuários, correções de bugs, etc. Além disso, temos ferramentas colaborativas como Slack, Confluence, Google Docs, Microsoft Teams, etc., para enviar mensagens entre os funcionários ou para gerenciar requisitos, compartilhar conhecimento, colaborar com equipes cruzadas, O Confluence é como uma Wikipédia para uma organização. Em seguida, temos a fase de codificação, e é aqui que, obviamente os desenvolvedores escreveriam e revisariam o código Eles garantirão sua qualidade e aderência aos padrões de codificação. E aqui, eles usarão um sistema de controle de versão como Git e repositórios de código como GitHub, Bitbucket, GitLab, etc E eles normalmente tendem a seguir o desenvolvimento orientado por testes escrevendo unidades J ou realizando qualquer análise de código estático usando ferramentas como o Sonar cube análise estática do código significaria que analisaríamos o código-fonte quanto à qualidade, confiabilidade e segurança sem precisar executar o código. E, obviamente, sem falar que para que os desenvolvedores trabalhem em suas atividades diárias, eles precisarão se inscrever, e podemos obter essa inscrição usando todas as tecnologias que falamos anteriormente Em seguida, temos a fase de construção, e é aqui que podemos usar algumas ferramentas do CICD Falaremos sobre o CICD mais detalhes na próxima palestra Mas uma das ferramentas populares do CICD é o Jenkins. Também temos outras ferramentas, como Circle CI ou Gitlab CICD, que fazem exatamente o mesmo trabalho Como parte da fase de construção, Jenkins realmente usaria algumas das ferramentas adicionais, como o Maven Gradle, para criar um projeto para que obtivéssemos um artefato ou um artefato implantável Jenkins também criará uma imagem do Docker usando a CLI do Docker Com isso, obviamente, precisamos um local para armazenar as imagens, e é aí que temos o Nexus e Docker Hub para hospedar e manter os Em seguida, temos a fase de testes. É aqui que faríamos o teste completo do aplicativo. Então, aqui fazemos testes de regressão, garantindo que os novos recursos não quebrem nenhum dos existentes. Fazemos testes de aceitação. Também fazemos análises de segurança e vulnerabilidade. Fazemos testes de desempenho, testes de configuração, etc Selenium é uma das ferramentas populares para automatizar o processo de teste do aplicativo O Apache Jometer é uma das ferramentas populares para realizar E mais uma vez, para testar coisas, precisamos de um ambiente para testes, e é aí que, mais uma vez veremos todas essas tecnologias entrando em cena. Já falamos sobre tudo isso anteriormente. Em seguida, temos a fase de implantação, qual usaremos o Jenkins para automatizar o processo de implantação do artefato ou, especificamente, da imagem do Docker no ambiente na qual usaremos o Jenkins para automatizar o processo de implantação do artefato ou, especificamente, da imagem do Docker no ambiente de produção. Então, depois que tudo for testado e garantir que tudo esteja funcionando conforme o esperado, o Jenkins selecionará automaticamente o artefato de poster artificial, como o Nexus ou o Docker hub, e o implantará no ambiente de preparação ou produção e o implantará no ambiente de o Mais uma vez, veremos todas as tecnologias que nos ajudarão a criar a inscrição Em seguida, temos a fase de operação. Assim, depois que o software for implantado, a equipe de operações fará seu trabalho para gerenciar a infraestrutura, solucionar quaisquer problemas e monitorar o Seu foco principal é manter uma inscrição estável e confiável, garantindo alta disponibilidade, desempenho e segurança Em seguida, vem a fase de monitoramento, que envolve coletar e analisar métricas, registros, rastrear o desempenho dos aplicativos, a integridade e a utilização de recursos, etc Basicamente, a equipe de operações monitorará tudo e, se encontrar algum problema, encaminhará para as equipes relevantes Nagios e prometios são algumas das ferramentas populares para monitoramento, e o Dynatrace e a dinâmica de aplicativos são algumas das ferramentas para monitoramento de desempenho Em seguida, vem a fase de aprendizado. E aqui, basicamente, coletamos feedback de usuários, partes interessadas e ferramentas de monitoramento para sugerir melhorias, correções de bugs ou até mesmo introduzir novos recursos com o objetivo de refinar e aprimorar o software, e todo o ciclo agora se repete desde a fase de planejamento É um processo contínuo e novos lançamentos continuariam acontecendo para sempre, pelo menos até o momento em que o projeto fosse abandonado. E essa é a razão pela qual o logotipo do DevOps parece um símbolo do infinito, porque esse processo continuaria acontecendo para sempre, e o software evoluiria e melhoraria a cada vez Um ponto importante que quero destacar aqui, que também mencionei anteriormente, é que o DevOps não é DevOps não é praticado da mesma forma em todas as organizações As ferramentas e metodologias seriam diferentes dependendo do projeto Mas o que falamos até agora são os mais populares. Se você não tem certeza do que aprender , aprenda esses populares, os que eu mencionei. A seguir, falaremos sobre a palavra mais enfatizada em DevOps Contínuo. Te vejo em seguida. 7. 0106 Integração contínua entrega contínua: Tradicionalmente, os desenvolvedores costumavam trabalhar no recurso ou no Bfix e , em seguida, enviavam essas alterações para um repositório de código centralizado, como GitHub, bitbucket, recurso ou no Bfix e , em seguida, enviavam essas alterações para um repositório de código centralizado, como GitHub, bitbucket, GitLab. Suponho que você não esteja familiarizado com essas ferramentas, então não vou usar nenhuma das terminologias associadas a Mas, essencialmente, os desenvolvedores contribuiriam com suas mudanças e somente no final do ciclo de vida do desenvolvimento todas essas alterações de código seriam mescladas Em outras palavras, todas essas alterações de código seriam mescladas ou integradas e as tornariam parte da base de código principal Depois de concluído, supondo que não haja conflitos, passaríamos para a próxima fase em que a equipe de teste testaria todas as alterações, faria um teste completo do aplicativo na inscrição do teste e, supondo que tudo correu bem e que a equipe de teste não encontrou nenhum problema, que é muito improvável, prosseguiremos com a implantação do aplicativo em implantação a encenação ou a inscrição na produção. No entanto, esse é o melhor cenário possível, mas, com toda a probabilidade, você verá os seguintes problemas. Você verá problemas de integração porque, ao mesclar tantas alterações de uma só vez, provável que você se depare com conflitos, significa que mais de um desenvolvedor pode ter trabalhado no mesmo código, e esses conflitos precisam ser resolvidos antes de e esses conflitos precisam continuar Ou pode acontecer que as mudanças feitas por um desenvolvedor tenham impacto negativo nas mudanças feitas por outro desenvolvedor. Também é muito difícil rastrear os problemas porque, quando você integra tantas mudanças, caso encontre um problema, é muito difícil saber qual alteração específica realmente causou o problema. Portanto, resolver os conflitos e identificar a causa raiz dos problemas se torna mais desafiador, o que pode levar a esforços de integração potencialmente demorados e propensos a erros Agora, se a equipe de teste encontrar algum problema crítico , isso pode até resultar em atraso no lançamento, e mesmo que o ciclo de feedback seja mais longo Os desenvolvedores não saberão de conflitos ou bugs até a fase final do ciclo de desenvolvimento, o pode levar a tempos de resolução mais longos e dificultar a capacidade de resolver o problema em tempo hábil No entanto, vamos seguir uma abordagem diferente, e aqui está o que acontece. Então, após a fase de planejamento, os desenvolvedores começariam a programar. Cada desenvolvedor contribuiria com suas mudanças para o repositório centralizado, então temos o Jenkins, que é um CSCdtol que constantemente Ao identificar um novo commit, Jenkins iniciará um processo criação para criar os artefatos ou a imagem do Docker, que será então implantada automaticamente implantada Jenkins também acionará testes automáticos de mérito para testar minuciosamente o aplicativo e as alterações E uma vez feito isso, Jenkins notificará os revisores para que revisem as alterações no código Os revisores examinarão as alterações no código, fornecerão o feedback necessário, sugerirão melhorias, etc., e os desenvolvedores abordarão o feedback recebido durante a revisão do código Eles fazem todas as modificações necessárias, acrescentam esclarecimentos ou discutem abordagens alternativas, ou discutem abordagens alternativas, e esse processo iterativo continua até que as alterações no código atendam aos padrões de qualidade exigidos Quando tudo estiver bem, depois que os revisores aprovarem o código, passaremos para a próxima fase, na qual mesclaremos todas essas alterações ou, em outras palavras, integraremos todas essas alterações na base de código principal E antes de realmente mesclar as alterações, talvez tenhamos uma tarefa no Jenkins para realizar qualquer um dos testes ou validações adicionais antes de mesclar as alterações antes de mesclar Ao mesclar as alterações ou integrá-las à base de código principal, podemos iniciar o processo de implantação dessas alterações no produção ou de preparação E mais uma vez, Jenkins fará o trabalho por nós. Ele construirá o projeto, implantará os artefatos necessários no ambiente de preparação ou produção e colocará o aplicativo em funcionamento Agora, o processo de contribuir o código, executar testes automatizados e, eventualmente, mesclar as alterações ou integrá-las à base de código principal é o que chamamos de integração contínua Ou, mais especificamente, também temos um desenvolvimento contínuo em que os desenvolvedores continuamente fazem melhorias, introduzem novas mudanças, e o processo de testar continuamente as alterações com testes automatizados é um teste contínuo. O que costumávamos fazer manualmente anteriormente agora são vários testes automatizados. E o processo de entrega das mudanças na preparação ou no ambiente de produção é chamado de entrega contínua Também costumamos confundir termo chamado implantação contínua. A diferença entre entrega contínua e implantação contínua é muito simples. Quando interferimos manualmente para permitir que o Jenkins escolha o código da base de código principal e, eventualmente implante o aplicativo no ambiente de produção, isso é chamado de entrega contínua Se automatizarmos esse processo, ou seja, logo após integrarmos as alterações na base de código principal, o Jenkins automaticamente pegará o código e o implantará no ambiente de produção, isso é chamado de implantação contínua E depois que o aplicativo é implantado, a equipe de operações faz o monitoramento contínuo e todo o processo se repete como parte do ciclo de vida do DevOps Portanto, diferentemente da abordagem tradicional, em que aprimoramos o software em um grande lote, no caso do DevOps, as atualizações são feitas continuamente, peça por peça, permitindo que o código do software seja entregue aos clientes assim que for concluído e testado Obviamente, como não estamos integrando grande quantidade de mudanças de uma só vez, não teremos tantos conflitos e, como não teremos tantos conflitos e, como os testes são realizados quase imediatamente após fazerem um comentário, os desenvolvedores receberão feedback instantâneo se houver algum problema com o código e, portanto, terão tempo suficiente para resolver o o fim do ciclo de desenvolvimento. Então, toda vez que alguém faz um cometa, vamos repetir todo o processo novamente porque tudo é praticamente automatizado, isso vai ser muito rápido. Jenkins está no centro de todo o processo e está conectando todos os pontos seguir, teremos um rápido resumo que realizamos com o D Wops 8. 0107 Vantagens do DevOps: Vamos falar sobre algumas das vantagens dos DEWAPs. Colaboração aprimorada e cultura aprimoradas, obviamente com a mudança de mentalidade e a incorporação de certas filosofias e práticas culturais , juntamente com ferramentas colaborativas, melhoramos significativamente a colaboração entre equipes multifuncionais e a entre Inovação e resolução de problemas mais rápidas Com muita ênfase na automação e com integração e entrega contínuas, reduzimos significativamente o tempo necessário para lançar o software e, devido a essas iterações mais rápidas, podemos inovar mais rapidamente e também resolver problemas em tempo hábil Inscrições operacionais mais estáveis. Com o uso de várias ferramentas e tecnologias, conseguimos criar inscrições estáveis em todas as equipes Portanto, se o aplicativo funcionar em uma única matrícula, é provável que ele também funcione em outro ambiente sem causar nenhum problema Vamos lidar com os problemas e o tempo de inatividade. Ao realizar consistentemente testes automáticos de mérito frequentes e regulares e também ao sermos capazes de manter ambientes estáveis e confiáveis, podemos reduzir as chances de ocorrência de problemas ou tempo de inatividade durante a produção Melhor eficiência operacional, usando várias ferramentas como o Ansible para gerenciamento de configuração e usando ferramentas de monitoramento como Nagios e com melhor colaboração com outros membros da equipe, também melhoramos a eficiência operacional geral várias ferramentas como o Ansible para gerenciamento de configuração e usando ferramentas de monitoramento como o Nagios e com uma melhor colaboração com outros membros da equipe, também melhoramos a eficiência operacional geral. Econômico. Obviamente, com muita ênfase na automação, o que costumava ser feito manualmente ou agora automatizado e também usando provedores de serviços em nuvem, vamos reduzir significativamente o custo. E é por isso que, se você tem experiência em testes ou operações de TI, precisa considerar seriamente a atualização de suas habilidades para o DevOps Satisfação do cliente. Obviamente, quando você segue as metodologias de DevOps, considerando todos os seus benefícios, em última análise, isso resultará em uma melhor satisfação do cliente porque eles não precisam esperar tanto pelos lançamentos e, obviamente, isso se traduz melhor receita e melhor reputação Também ajudará você a ficar à frente de seus concorrentes no mercado. Espero que você tenha entendido a visão geral do DevOps. Te vejo em seguida.