O DevOps se tornou a solução padrão para corrigir processos de desenvolvimento de software lentos, desconectados ou interrompidos. O problema é que, se você é novo no DevOps e não sabe por onde começar, poderá não entender essas técnicas. Este artigo orientará você na definição de um pipeline do DevOps e fornecerá instruções sobre como criá-lo em cinco etapas. Embora este tutorial não seja abrangente, ele deve fornecer uma base para você começar e expandir seu conhecimento no futuro. Mas vamos começar com a história.
Minha jornada de DevOps
Eu costumava trabalhar na equipe de nuvem do Citi Group desenvolvendo um aplicativo da Web Infraestrutura como Serviço (IaaS) para gerenciar a infraestrutura de nuvem do Citi, mas sempre me perguntei como tornar o processo de desenvolvimento mais eficiente e trazer mudanças culturais positivas para a equipe de desenvolvimento. Encontrei a resposta em um livro recomendado por Greg Lavender, CTO do Citi para arquitetura e infraestrutura em nuvem. O livro foi intitulado The Phoenix Project e explica os princípios do DevOps enquanto se lê como um romance.
A tabela na parte de trás do livro mostra com que frequência diferentes empresas implantam seus sistemas em um ambiente de lançamento:
Amazon: 23.000 por dia
Google: 5.500 por dia
Netflix: 500 por dia
Facebook: Uma vez por dia
Twitter: 3 vezes por semana
Empresa típica: Uma vez a cada 9 meses
Como são possíveis as frequências da Amazon, Google e Netflix? Isso ocorre porque essas empresas descobriram como criar um pipeline de DevOps quase perfeito.
Estávamos muito longe disso até a implementação do DevOps no Citi. Minha equipe tinha ambientes diferentes na época, mas a implantação no servidor de desenvolvimento era completamente manual. Todos os desenvolvedores tiveram acesso a apenas um servidor de desenvolvimento baseado no IBM WebSphere Application Server Community Edition. O problema era que o servidor desligava sempre que vários usuários tentavam implantar ao mesmo tempo; portanto, os desenvolvedores tinham que comunicar suas intenções uns aos outros, o que era bastante doloroso. Além disso, houve problemas com cobertura de código de teste de baixo nível, processos de implantação manual complicados e incapacidade de rastrear a implantação de código associado a uma tarefa específica ou história do usuário.
Percebi que precisava fazer algo e encontrei um colega com a mesma opinião. Decidimos colaborar no pipeline inicial do DevOps - ele configurou uma máquina virtual e um servidor de aplicativos Tomcat enquanto eu trabalhava no Jenkins, integrou o Atlassian Jira e o BitBucket e trabalhou na cobertura do código de teste. Esse projeto paralelo foi muito bem-sucedido: automatizamos quase completamente muitos processos, alcançamos quase 100% de tempo de atividade do nosso servidor de desenvolvimento, fornecemos rastreamento e melhoramos a cobertura do código de teste e também adicionamos a capacidade de vincular filiais no Git a problemas no Jira ou implantações. A maioria das ferramentas que usamos para construir nosso pipeline de DevOps era de código aberto.
Agora eu entendo o quão simples nosso pipeline de DevOps era: não usamos extensões como arquivos Jenkins ou Ansible. No entanto, esse pipeline simples funcionou bem, possivelmente devido ao princípio de Pareto (também conhecido como regra 80/20).
Uma rápida introdução ao DevOps e ao pipeline de CI / CD
Se você perguntar a várias pessoas: "O que é o DevOps?", Provavelmente obterá várias respostas diferentes. O DevOps, como o Agile, evoluiu para abranger muitas disciplinas diferentes, mas a maioria das pessoas concorda em algumas coisas: O DevOps é uma prática de desenvolvimento de software ou um ciclo de vida de desenvolvimento de software (SDLC) que se concentra em mudar a cultura na qual desenvolvedores e não desenvolvedores existem em um ambiente em que:
Operações automatizadas que foram executadas anteriormente manualmente;
Todo mundo faz o que sabe melhor;
O número de implementações por um determinado período de tempo aumenta; A taxa de transferência aumenta;
A flexibilidade do desenvolvimento é aumentada.
Embora ter as ferramentas de software certas não seja a única coisa que você precisa para criar um ambiente DevOps, algumas ferramentas são necessárias. A ferramenta principal é a integração contínua e a implantação contínua (CI / CD). Nesse pipeline, os ambientes têm estágios diferentes (por exemplo, DEV, INT, TST, QA, UAT, STG, PROD), muitas operações são automatizadas e os desenvolvedores podem escrever código de alta qualidade, obter flexibilidade de desenvolvimento e alta frequência de implantação.
Este artigo descreve uma abordagem em cinco etapas para a criação de um pipeline de DevOps semelhante ao mostrado no diagrama a seguir, usando ferramentas de código aberto.
Etapa 1: métodos de CI / CD
A primeira coisa que você precisa é de uma ferramenta de CI / CD. Jenkins, uma ferramenta baseada em Java de código aberto lançada sob a licença MIT, é a ferramenta que popularizou a direção do DevOps e se tornou o padrão de fato.
Então, o que é Jenkins? Pense nisso como um tipo de controle remoto universal mágico que pode conversar e organizar vários serviços e ferramentas. Uma ferramenta de CI / CD como Jenkins é inútil por si só, mas fica mais poderosa à medida que se conecta a várias ferramentas e serviços.
Jenkins é apenas uma das muitas ferramentas de CI / CD de código aberto que você pode usar para criar seu pipeline de DevOps.
Jenkins: Creative Commons e MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
É assim que os processos do DevOps se parecem com uma ferramenta de CI / CD:
Você tem uma ferramenta de CI / CD em execução no host local, mas não há muito o que fazer neste momento. Vamos para a próxima etapa da jornada do DevOps.
Etapa 2: gerenciar sistemas de controle de origem
A melhor (e mais fácil) maneira de testar se sua ferramenta de CI / CD pode fazer a mágica é integrar-se a uma ferramenta de controle de código-fonte (SCM). Por que você precisa de controle de origem? Digamos que você esteja desenvolvendo um aplicativo. Sempre que você cria um aplicativo, programa, não importa se você usa Java, Python, C ++, Go, Ruby, JavaScript ou qualquer um dos zilhões de linguagens de programação. O código que você escreve é chamado de código fonte. No começo, especialmente quando você está trabalhando sozinho, provavelmente pode colocar tudo em um diretório local. Porém, à medida que o projeto aumenta, e você convida outras pessoas a colaborar, você precisa de uma maneira de evitar conflitos enquanto compartilha modificações com eficiência. Você também precisa de uma maneira de restaurar versões anteriores,porque criar backups e copiar / colar neles já é obsoleto. Você (e seus colegas de equipe) precisam de algo melhor.
É aqui que o controle de origem se torna praticamente uma necessidade. Essa ferramenta armazena seu código em repositórios, acompanha as versões e coordena o trabalho dos participantes do projeto.
Embora existam muitas ferramentas de controle de fontes por aí, o Git é o padrão e com razão. Eu recomendo usar o Git, embora existam outras opções de código aberto, se quiser.
Git: GPLv2 e LGPL v2.1
Subversion: CVS (Apache 2.0
Concurrent Versions System): GNU
Vesta: LGPL
Mercurial: GNU GPL v2 +
É assim que um pipeline do DevOps se parece com os controles de fonte adicionados.
A ferramenta CI / CD pode automatizar os processos de verificação, recuperação do código fonte e colaboração entre os membros. Não é ruim? Mas como você o torna um aplicativo funcional para que bilhões de pessoas possam usá-lo e apreciá-lo?
Etapa 3: criar uma ferramenta de automação de construção
Bem! Você pode verificar o código e fazer alterações no sistema de controle de origem, bem como convidar seus amigos para colaborar no desenvolvimento. Mas você ainda não criou o aplicativo. Para criar um aplicativo Web, ele deve ser compilado e empacotado em um formato de lote implementável ou executado como um arquivo executável. (Observe que uma linguagem de programação interpretada como JavaScript ou PHP não precisa ser compilada.)
Use uma ferramenta de automação de construção. Independentemente de qual ferramenta de automação de construção você escolher, todos têm o mesmo objetivo: criar código-fonte no formato que desejar e automatizar a tarefa de limpeza, compilação, teste e implantação em um ambiente específico. As ferramentas de compilação variam dependendo da sua linguagem de programação, mas aqui estão algumas opções comuns de código aberto.
Nome | Licença | Linguagem de programação |
---|---|---|
Maven | Apache 2.0 | Java |
Formiga | Apache 2.0 | Java |
Gradle | Apache 2.0 | Java |
Bazel | Apache 2.0 | Java |
Faço | GNU | N / D |
Grunhido | MIT | Javascript |
Gole | MIT | Javascript |
Buildr | Apache | Rubi |
Ancinho | MIT | Rubi |
AAP | GNU | Pitão |
SCons | MIT | Pitão |
BitBake | GPLv2 | Pitão |
Bolo | MIT | C # |
ASDF | Expatriados (MIT) | LISP |
Cabala | BSD | Haskell |
Ótimo! Você pode colocar os arquivos de configuração da ferramenta de automação de construção em um sistema de controle de origem e permitir que sua ferramenta de CI / CD junte tudo.
Está tudo bem, não está? Mas onde implantar seu aplicativo?
Etapa 4: servidor para aplicativos da web
Até agora, você tem um arquivo compactado que pode ser executável ou instalável. Para que um aplicativo seja realmente útil, ele deve fornecer algum tipo de serviço ou interface, mas você precisa de um contêiner para hospedar seu aplicativo.
O servidor de aplicativos da web é exatamente esse contêiner. O servidor fornece um ambiente no qual a lógica do pacote implementado pode ser definida. O servidor também fornece uma interface e oferece serviços da Web abrindo soquetes para o mundo externo. Você precisa de um servidor HTTP e de algum ambiente (como uma máquina virtual) para instalá-lo. Por enquanto, vamos supor que você aprenda mais sobre isso (embora eu fale sobre os contêineres abaixo).
Existem vários servidores de aplicativos da web de código aberto.
Nome | Licença | Linguagem de programação |
---|---|---|
Tomcat | Apache 2.0 | Java |
Jetty | Apache 2.0 | Java |
Vôo selvagem | Público Menor do GNU | Java |
Peixe de vidro | CDDL e GNU menos públicos | Java |
Django | BSD de 3 cláusulas | Pitão |
Tornado | Apache 2.0 | Pitão |
Gunicorn | MIT | Pitão |
Pitão | MIT | Pitão |
Trilhos | MIT | Rubi |
Node.js | MIT | Javascript |
Seu pipeline do DevOps está quase pronto para uso. Bom trabalho!
Embora você possa parar por aí e se integrar, a qualidade do código é algo importante para um desenvolvedor de aplicativos se preocupar.
Etapa 5: cobertura de teste de código
A implementação de testes pode ser outro requisito complicado, mas os desenvolvedores devem detectar erros no aplicativo mais cedo e melhorar a qualidade do código para garantir que os usuários finais sejam satisfeitos. Felizmente, existem muitas ferramentas de código aberto disponíveis para testar seu código e fazer recomendações para melhorar sua qualidade. Melhor ainda, a maioria das ferramentas de CI / CD pode se conectar a essas ferramentas e automatizar o processo.
O teste de código consiste em duas partes: estruturas de teste de código que ajudam a escrever e executar testes e ferramentas de sugestão que ajudam a melhorar a qualidade do seu código.
Sistemas de teste de código
Nome | Licença | Linguagem de programação |
---|---|---|
JUnit | Licença Pública Eclipse | Java |
EasyMock | Apache | Java |
Mockito | MIT | Java |
PowerMock | Apache 2.0 | Java |
Pytest | MIT | Pitão |
Hipótese | Mozilla | Pitão |
Tox | MIT | Pitão |
Sistemas de recomendação de aprimoramento de código
Nome | Licença | Linguagem de programação |
---|---|---|
Cobertura | GNU | Java |
CodeCover | Público do Eclipse (EPL) | Java |
Coverage.py | Apache 2.0 | Pitão |
Emma | Licença Pública Comum | Java |
JaCoCo | Licença Pública Eclipse | Java |
Hipótese | Mozilla | Pitão |
Tox | MIT | Pitão |
Jasmim | MIT | Javascript |
Carma | MIT | Javascript |
Mocha | MIT | Javascript |
Jest | MIT | Javascript |
Observe que a maioria das ferramentas e estruturas mencionadas acima são escritas para Java, Python e JavaScript, pois C ++ e C # são linguagens de programação proprietárias (embora o GCC seja de código aberto).
Agora que você implementou as ferramentas de cobertura de teste, seu pipeline do DevOps deve ser semelhante ao diagrama mostrado no início deste tutorial.
Etapas adicionais
Contêineres
Como eu disse, você pode hospedar seu servidor em uma máquina ou servidor virtual, mas os contêineres são uma solução popular.
O que são contêineres? A breve explicação é que uma máquina virtual precisa de uma quantidade enorme de memória do sistema operacional que exceda o tamanho do aplicativo, enquanto o contêiner precisa apenas de algumas bibliotecas e configurações para executar o aplicativo. Obviamente, ainda existem usos importantes para uma máquina virtual, mas um contêiner é uma solução leve para hospedar um aplicativo, incluindo um servidor de aplicativos.
Embora existam outras opções de contêiner, as mais populares são Docker e Kubernetes.
Docker: Apache 2.0
Kubernetes: middleware do Apache 2.0
Automation
Nosso pipeline de DevOps está focado principalmente na co-criação e implantação de aplicativos, mas há muitas outras coisas que podem ser feitas usando as ferramentas de DevOps. Um deles é o uso de ferramentas de Infraestrutura como Código (IaC), também conhecidas como ferramentas de middleware. Essas ferramentas ajudam a automatizar a instalação, o gerenciamento e outras tarefas do middleware. Por exemplo, uma ferramenta de automação pode buscar aplicativos como o servidor de aplicativos da web, o banco de dados e a ferramenta de monitoramento com as configurações corretas e implementá-los no servidor de aplicativos.
Aqui estão algumas ferramentas de middleware de código aberto:
Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache ou GPL
Descubra os detalhes de como obter uma profissão de alto nível do zero ou subir de nível em habilidades e salário fazendo os cursos on-line pagos do SkillFactory:
- Curso DevOps (12 meses)
mais cursos
- Machine Learning (12 )
- Data Science (12 )
- (9 )
- «Python -» (9 )