Para que serve Jenkins, e o que ele pode fazer?
Em quase todas as discussões sobre integração contínua de código aberto ou ferramentas de entrega contínua (CI / CD – continuous integration or continuous delivery), o Jenkins inevitavelmente será mencionado. Mas para que é usado o Jenkins, especificamente, e como funciona?
Neste artigo, damos uma visão geral do Jenkins, como ele é usado e dicas para equipes prontas para avançar na integração desta popular ferramenta de CI / CD de código aberto.
Para que o Jenkins é usado?
Jenkins é usado para construir e testar o seu produto continuamente, para que os desenvolvedores possam integrar continuamente as mudanças na construção. Jenkins é a ferramenta de CI / CD de código aberto mais popular no mercado hoje e é usado no suporte de DevOps, junto com outras ferramentas nativas da nuvem.
Automação, incluindo CI / CD e automação de teste, é uma das principais práticas que permitem que as equipes de DevOps entreguem soluções de tecnologia “mais rápidas, melhores e mais baratas”.
Portanto, Jenkins se tornou uma ferramenta indispensável para ajudá-lo a atingir esses objetivos. Jenkins tem sido uma tecnologia de capacitação chave que está ajudando cada vez mais as práticas de DevOps a serem amplamente adotadas em muitas organizações em todo o mundo.
Jenkins é uma ferramenta de integração/entrega contínua?
Embora seja usado por muitas equipes de DevOps avançadas que oferecem aplicativos nativos de nuvem de última geração, o Jenkins já existe há um bom tempo. O projeto (originalmente chamado de Hudson) foi desenvolvido em 2004 por Kohsuke Kawaguchi enquanto trabalhava na Sun Microsystems e lançado em 2005. Depois que a Oracle adquiriu a Sun, o projeto foi bifurcado para permanecer open source e o fork foi nomeado Jenkins em 2011.
Embora Kohsuke tenha desenvolvido originalmente o Jenkins para facilitar a integração contínua para aplicativos Java, Jenkins desde então evoluiu para orquestrar todo o pipeline de entrega de software para as linguagens e tecnologias mais populares usadas por desenvolvedores em todo o mundo hoje. Escrito em Java, com extensibilidade no núcleo de sua arquitetura, existem centenas de plug-ins disponíveis que estendem o Jenkins para fornecer a flexibilidade de automatizar todos os aspectos do pipeline de entrega de software.
Antes do Jenkins …
Antes do Jenkins, muitas equipes de desenvolvimento empregavam um build noturno como parte do processo de entrega de software. O processo de construção noturno exigia que as equipes enviassem seu código ao repositório de código-fonte em um determinado horário de corte todos os dias. Isso foi um desafio ainda maior ao trabalhar com equipes geograficamente dispersas. Um horário noturno de, digamos, 23h PST equivaleria a 12h30 IST na Índia.
Portanto, os desenvolvedores na Índia seriam forçados a comprometer o seu código no meio do dia e, em seguida, esperar que a construção “noturna” fosse executada, afetando sua produtividade. Então, uma vez que o build fosse concluído, as equipes de desenvolvimento frequentemente se deparariam com a pergunta: “Quem quebrou o build?”. Nesse ponto, as equipes de desenvolvimento se esforçariam para determinar quem foi o commit que quebrou a compilação e a acusação começaria. Tinha que haver uma maneira melhor.
Como funciona o Jenkins?
O Jenkins aciona uma construção a cada confirmação para o repositório de código-fonte, normalmente para um branch de desenvolvimento.
Jenkins pode ser configurado para executar um conjunto inicial de testes de unidade para garantir que o commit não “quebrou a compilação”. Se os testes não passarem, o desenvolvedor pode ser notificado imediatamente para tomar uma ação corretiva. Isso põe de lado a questão de “Quem quebrou o build?” pois é fácil determinar qual confirmação causou a falha da compilação. Se todos os testes de unidade forem aprovados, o pipeline de construção pode prosseguir para a próxima fase com testes de integração que geralmente levam mais tempo para serem executados.
O Jenkins oferece a capacidade de executar um build em paralelo em várias máquinas para minimizar o tempo total necessário para concluir muitas dessas atividades. Por fim, o Jenkins pode implantar o build em um ambiente que permite qualquer teste de aceitação do usuário (UAT – user acceptance testing) necessário antes de liberá-lo para produção. Essas etapas simplificadas abrangem o espírito de um ambiente de integração contínua (CI).
Para alcançar o Santo Graal da entrega contínua (CD), esses testes UAT também podem ser automatizados usando uma ferramenta como Selenium, onde se esses testes passarem, o código pode ser mesclado no branch master onde uma compilação “dourada” pode ser criada e implantado diretamente na produção sem intervenção manual. As empresas que alcançaram o marco de entrega contínua podem implantar na produção muitas vezes ao dia, como Amazon, Facebook e Google.
Avançando com Jenkins para DevOps
Olhando para o futuro, Jenkins encontrou um ponto ideal em muitos ambientes DevOps. Alguns até o chamaram de “o motor do DevOps”, o uso da nuvem e dos contêineres. Jenkins pode ser executado na nuvem (AWS, Google, Azure, IBM, etc.) e tecnologias de aproveitamento como Docker e Kubernetes fornecem ao Jenkins flexibilidade, velocidade e confiabilidade adicionais para atender às demandas dos aplicativos modernos nativos da nuvem e baseados nos micros serviços de hoje. O futuro parece muito promissor com o Jenkins como uma tecnologia de capacitação chave para pipelines de CI / CD para empresas em todo o mundo.
Referencia: https://www.openlogic.com/blog/what-is-jenkins-used-for