Você usa Jenkins? Provavelmente sim, porque este é o projeto mais popular desta classe até o momento. Eu sempre estava interessado em conversar com um dos desenvolvedores e fazer algumas perguntas difíceis. Aqui, não temos apenas um desenvolvedor, mas o criador do próprio Jenkins - Kohsuke Kawaguchi .
Como você sabe, Jenkins é um projeto de código aberto com uma licença MIT. Mais recentemente, foi realizada a conferência FOSDEM - a maior conferência do mundo dedicada ao software livre. Gratuito, aberto, com dezenas de alto-falantes de todo o mundo. Isso significa que você pode encontrar alguém lá - até o criador do Jenkins. Com um pequeno grupo de amigos e colegas do grupo JUG.ru, fizemos um pouso surpresa lá e pudemos gravar uma boa entrevista com o criador de Jenkins.
Portanto, em nosso estúdio virtual, Koske Kawaguchi (que se apresentará e explicará tudo em mais detalhes abaixo), Ruslan Akhmetzyanov ARG89 do Grupo JUG.ru e Kirill Tolkachev tolkkv da CIAN , nosso orador constante, guru Groovy, Gradle, Spring e a pilha de tecnologia Netflix, a quem você pode saber no podcast Debriefing.
Ruslan: Olá. Primeiro, conte-nos um pouco sobre você e sobre Jenkins?
Kosuke: Meu nome é Koske, conhecido principalmente como criador de Jenkins e CTO do CloudBees. Jenkins é uma ferramenta com a qual os desenvolvedores automatizam vários estágios do processo de entrega do software. Eu, pessoalmente, conheço vários programadores da Rússia que usam Jenkins e ficarei feliz em conhecer outros.
Kirill: Eu também vou me apresentar - sou desenvolvedor e também organizo o Moscow Jenkins Area Meetup (JAM). Tenho uma vasta experiência no uso do Jenkins, especialmente o pipeline com script / declarativo. Você pode me dizer o que o CTO da empresa que está desenvolvendo Jenkins está fazendo?
Kosuke: Uma das tarefas da minha equipe é interagir com a comunidade. O sucesso de nossa empresa depende muito do sucesso do projeto de código aberto. Outra tarefa importante é educar o restante das pessoas da empresa sobre como o código aberto funciona. Em geral, temos um relacionamento muito interessante entre a empresa e a comunidade: todos aprendem algo um com o outro e prestamos muita atenção a essa interação.
Você também perguntou qual função o diretor técnico desempenha. O fato é que essa função evoluiu à medida que a empresa cresceu. No começo, eu era como um programador líder e fazia muito trabalho técnico. Mas à medida que a empresa se desenvolveu, outras pessoas começaram gradualmente a fazer esse trabalho. Por exemplo, uma equipe separada começou a lidar com o Pipeline. Eu me comunico periodicamente com eles para ter uma idéia do que eles estão fazendo, às vezes eu dou conselhos. Mas eles tomam todas as decisões relacionadas ao design e desenvolvimento por conta própria. Em geral, essa evolução do meu papel foi muito interessante, tenho que me adaptar constantemente.
Kirill: Se bem entendi, seu foco mudou de questões técnicas para trabalhar com a comunidade.
Kosuke: Sim, muito do que estou fazendo está relacionado a isso. Há coisas que apenas o fundador de uma empresa pode dizer. Portanto, parte da minha atividade é, relativamente falando, acenar uma bandeira e chamar a comunidade em uma determinada direção quando uma mudança de rumo é necessária., Como foi, por exemplo, no ano passado. Além disso, nós e a equipe estamos envolvidos na promoção de Jenkins: explicamos quais são nossos objetivos, que dificuldades estamos tentando superar. Além disso, quando preciso fazer uma apresentação sobre o estado geral das coisas, inspiro mais confiança. É assim que minha atividade é resumida.
Kirill: E há quantos anos essa partida do trabalho técnico para o trabalho organizacional começou? Você pode contar a história de Jenkins e como seu papel mudou à medida que o projeto cresceu?
Kosuke: O projeto apareceu em 2004, e no começo eu trabalhava à noite e nos fins de semana, ou seja, era um tipo de hobby. Mas gradualmente o projeto cresceu. Passei bastante tempo criando essa plataforma na qual outras pessoas poderiam escrever seus aplicativos. Com o tempo, surgiu um ecossistema e uma comunidade de desenvolvedores, alguns dos quais eram da Rússia - por exemplo, Oleg Nenashev (Twitter: @oleg_nenashev ), que escreveu um subsistema muito interessante sobre Jenkins. À medida que o projeto ganhou popularidade, a necessidade de melhor interação com os usuários e seu treinamento se tornou mais aguda. Portanto, comecei a fazer mais com essas coisas. Finalmente, por volta de 2010, Jenkins se tornou tão popular que decidi dedicar todo o meu tempo a ele e criar uma empresa. A partir deste momento, foi adicionado um trabalho de organização da empresa para trabalhar com a comunidade. A empresa estava crescendo e comecei a me perguntar: que tipo de atividade ninguém pode realizar, exceto eu? Tanto na empresa como na comunidade, há muitas pessoas capazes que estão felizes por estarem prontas para assumir responsabilidades adicionais. Gradualmente, eles começaram a fazer muito do que eu costumava fazer. Então, em geral, nosso caminho parecia.
Kirill: Obrigado. Hoje, o Jenkins é o sistema de CI mais popular. E quão comum é a versão comercial do Jenkins em comparação com outros sistemas comerciais de IC? Por exemplo, com o Travis Enterprise ou com sistemas que podem funcionar localmente?
Kosuke: O código-fonte aberto Jenkins é um projeto grande, tem muitos usuários. CloudBees tem uma escala muito menor. Portanto, se conseguirmos transformar até um por cento da base de usuários do Jenkins em usuários do CloudBees, esse será um resultado muito grande. Todas as empresas baseadas em produtos de código aberto trabalham com esse princípio. Outra questão importante é quanto conseguimos ajudar as pessoas cujos problemas nosso produto deve resolver. Calculamos a eficácia do nosso suporte técnico e, se me lembro bem das estatísticas, em geral, nossos serviços as satisfazem.
Kirill: Você quer dizer aqueles que usam a versão paga? Ou aqueles que têm livre também?
Kosuke: Ambos. Ou seja, se uma pessoa compra um produto, ele recebe suporte, mas também pode ser obtido sem o uso de software proprietário.
Kirill: Ou seja, você atua como intermediário entre desenvolvedores e seus usuários, de código aberto e comercial. Entendo corretamente que você também tem as tarefas de visão de produto?
Kosuke: Isso não é totalmente verdade, temos uma equipe de produtos separada. Não sou um representante do usuário, mas tenho reuniões constantemente com muitas pessoas, usuários e não apenas, ou seja, mantenho contato com a comunidade. Por exemplo, eu tenho uma coluna "Resumo com avançado" para outros funcionários da empresa. Nessas postagens, falo sobre como nossos usuários escrevem software e o que isso significa para Jenkins. Então, estou tentando influenciar as decisões que a equipe de produto toma.
Kirill: Aparentemente, você desempenha um papel importante na empresa. Vamos passar para questões mais pessoais. Qual é o seu recurso favorito de Jenkins sobre o qual você poderia falar da manhã à noite?
Kosuke: Bem, falar de manhã à noite será difícil. Agora estou mais interessado em como a organização funciona - acho que isso se deve à minha função nela. Quando eu trabalhava sozinho, minha atenção estava muito mais focada em recursos individuais. Agora, acho que não, por isso é difícil responder a sua pergunta.
Kirill: Então, talvez, você se lembre de algum recurso implementado anos atrás e que estava muito orgulhoso?
Kosuke: Posso falar sobre um dos recentes recursos significativos em que trabalhamos - acho que será mais interessante para os usuários. Este é um projeto do ano passado, Jenkins Configuration as Code . Vimos que nossos usuários estavam passando gradualmente do gerenciamento do Jenkins com um clique do mouse na GUI para a configuração através do arquivo de configuração no repositório git. A necessidade de um projeto Configuration as Code foi sentida por um longo tempo, e muitas muletas temporárias foram escritas para executar essa função. Mas nenhuma dessas empresas era grande o suficiente. Finalmente, conseguimos reunir as pessoas da comunidade que estavam interessadas neste novo projeto e criar uma ferramenta bastante ampla e atenciosa. Muitos aspectos deste projeto resultaram muito bem e ganharam popularidade bastante ampla, que não pode deixar de se alegrar.
Você pode se lembrar de outro projeto, o Jenkins X, que é uma evolução em uma direção completamente diferente. Foi criado especificamente para trabalhar com o Kubernetes. Graças a essa especialização, podemos obter uma integração suave e ocultar a complexidade que surge devido à integração e à conexão de processos de entrega contínua. Como resultado, facilitamos a implementação das melhores práticas, em nossa opinião,. Penso que, graças a este projeto, Jenkins estará disponível para um grande número de pessoas que executam ações bastante padrão e não desejam gastar muito tempo na configuração, que precisa de tudo para funcionar.
Ruslan: Você usa Jenkins ao escrever Jenkins?
Kosuke: Sim, o projeto Jenkins tem seu próprio Jenkins. De fato, temos uma instância grande que executa uma revisão pull-rique em cada plug-in e núcleo. Além disso, há uma cópia para trabalhos especialmente importantes relacionados à segurança e vulnerabilidades, pois o desenvolvimento de recursos para segurança ocorre em um repositório proprietário separado. Por fim, existe uma terceira instância para tarefas ainda mais importantes, como assinar chaves e itens relacionados a liberações. Além desses três, uma cópia separada funciona em minha casa o tempo todo.
Kirill: Você mencionou o Jenkins X. O próprio Jenkins é como uma faca suíça, com plugins que podem fazer qualquer coisa. Mas o Jenkins X, pelo contrário, é altamente especializado, existe para o Pipeline e trabalha com o Kubernetes. Que tipo de estratégia técnica você e sua empresa adotam? Você suporta apenas Jenkins e Jenkins X? Ou, além disso, também haverá Jenkins XX para clusters Mesos, Jenkins XXX para Cloud Foundry e assim por diante?
Kosuke: Eu acho que depende muito da reação da comunidade. Ter uma plataforma universal é, obviamente, muito importante. A questão é quem implementa exatamente essa flexibilidade. Hoje, os usuários geralmente têm acesso direto a ele. Isso é conveniente se você é uma empresa grande e está fazendo algo incomum. Mas, ao mesmo tempo, conheço muitas pessoas que não precisam de tanta flexibilidade. Imagine que você veio à sala de jantar e pediu para fazer um sanduíche. Você pode escolher entre sete tipos de pão, cinco tipos de manteiga, quatro tipos de queijo e precisa decidir sobre todos os ingredientes. Mas você não precisa de toda essa escolha, só precisa de um sanduíche saboroso e não quer descobrir como fazer isso direito. Sei que muitas pessoas têm essa atitude em relação a Jenkins e querem que toda a flexibilidade permaneça do nosso lado. Jenkins X é o primeiro passo sério nessa direção. Se esse projeto continuar com sucesso, eu adoraria tentar fazer algo semelhante para firmware e IoT, plataformas móveis ou aprendizado de máquina. Eu acho que existem muitos mercados verticais em que as pessoas precisam apenas de uma ferramenta que lhes permita levar rapidamente o produto à produção. Você é da Rússia, provavelmente conhece o JetBrains?
Kirill: Claro.
Kosuke: Eu acho que eles seguem uma estratégia semelhante. Eles têm uma base muito flexível, sobre a qual existem muitos complementos mais especializados, nos quais, em essência, os mesmos elementos são montados de maneiras diferentes. Os usuários são gratos a eles por isso, e eu realmente gosto da abordagem deles.
Kirill: Por muitos anos, tenho observado a mesma imagem em muitas comunidades quando aconselho a usar um ou outro plug-in - a propósito, agora https://plugins.jenkins.io me ajuda muito, todos os plug-ins aprovados estão lá. O problema é que as pessoas estão tentando em todos os casos usar uma ferramenta universal, que geralmente não é adequada para um caso específico. Portanto, agora eu normalmente recomendo apenas uma ferramenta - Pipeline, que é uma ferramenta ideal que é adequada em todas as situações. Mas um novo problema surge. As pessoas tentam usar o pipeline com script ou pipeline declarativo sem entender como eles são organizados internamente. Existem problemas com a infraestrutura, com o estabelecimento de correspondência entre nós, compartilhamento de dados, tráfego incomum entre o agente e o mestre ou problemas com a escala no mestre. Qual ferramenta, do seu ponto de vista, é melhor: a que indica a única maneira correta de resolver o problema, como o Jenkins X? Ou uma ferramenta como o Scripted Pipeline que pergunta exatamente o que você tinha em mente?
Kosuke: Não sei se entendi direito, mas tentarei responder. Em japonês, há a palavra "kata", não sei como traduzi-lo com precisão. É usado, entre outras coisas, no judô. Estamos falando de movimentos estritamente definidos que os alunos aprendem: por exemplo, levantar a mão de uma certa maneira para evitar um certo golpe. Eu fiz um pouco disso, então eu sei o mais simples deles. O desafio é memorizar um conjunto de movimentos simples, algum tipo de padrão ou melhores práticas. Mas isso é apenas o começo. Conhecendo essa base, você pode continuar deixando-a corretamente se a situação exigir, sem violar os movimentos básicos. Você estuda seu próprio espaço, seu território, mas, ao mesmo tempo, conhecer a base comum ajuda você de qualquer maneira. Se você não a conhece, sempre se perguntará: estou fazendo a coisa certa? Mesmo que o que você escreveu funcione, você ainda tem dúvidas.
Em geral, sua pergunta me lembrou kata. Acho que temos uma situação semelhante com Jenkins. O Jenkins X fornece uma base e, à medida que você começa a entendê-lo mais profundamente, pode deixá-lo, se necessário, com a ajuda de plugins e outras coisas. Obviamente, o Jenkins X precisa sacrificar a flexibilidade para proporcionar uma melhor experiência com o Kubernetes. Mas o fato de o Jenkins X estar empurrando você para as melhores práticas não significa que você está sendo privado de uma escolha. Em geral, isso é verdade em relação a qualquer software. Só que, com o Jenkins X, tivemos uma importante mudança de mentalidade. Anteriormente, criamos apenas os elementos principais do sistema - a plataforma e os plugins, cabia ao usuário montá-los. Com o Jenkins X, a comunidade mudou para uma nova abordagem e, na minha opinião, esse é um passo muito importante.
Kirill: Se você não se importa, terei mais duas perguntas. Qual recurso trouxe mais problemas para você no ano passado? Cada projeto tem períodos difíceis - você pode nos dizer como eles eram?
Kosuke: Nós realmente arruinamos nossas vidas várias vezes. O problema é que, à medida que a Jenkins crescia, nosso projeto começou a atrair cada vez mais atenção de outras empresas e de suas equipes de segurança que começaram a procurar buracos na Jenkins. Portanto, o número de relatórios de vulnerabilidade vindos de fora começou a crescer exponencialmente. Às vezes, ficou um pouco assustador com isso, especialmente quando você considera que algumas dessas solicitações chegaram com um prazo, para o qual precisávamos fechar a vulnerabilidade. Isso foi especialmente difícil quando se tratava de recursos criados pela comunidade. Além disso, ao instalar atualizações com vulnerabilidades corrigidas, os usuários às vezes são interrompidos. Estamos trabalhando duro para impedir que isso aconteça, porque, caso contrário, os usuários terão medo de instalar atualizações de segurança, o que é extremamente indesejável.
Kirill: Você tem algum órgão que decide quais recursos serão incluídos no lançamento? Diga-nos como essas decisões são tomadas e os usuários podem pedir para incluir alguns recursos no lançamento? Se puderem, quem terá prioridade - para os usuários do CouldBees ou do Jenkins de código aberto? Por fim, se possível, conte-nos sobre seus planos para os próximos seis meses a um ano.
Koske: Há um ponto interessante aqui: o CloudBees não é o proprietário de Jenkins, esses são dois projetos separados, cada um com sua própria estrutura de tomada de decisão. CloudBees é simplesmente o maior colaborador de Jenkins, com muitos CloudBees trabalhando ao mesmo tempo na comunidade. Nos últimos anos, tentamos criar estruturas de controle mais claras na Jenkins que fazem exatamente o que você acabou de pedir. Para isso, criamos o Jenkins Enhancement Process ...
Cyril: Desculpe interromper - é abreviado como JEP, assim como em Java?
Kosuke: Absolutamente. Obviamente, não inventamos esse conceito, mas o emprestamos do Python, Java e de algumas outras comunidades, porque lá já se estabeleceu. A idéia principal aqui é que a comunidade possa expressar sua opinião e chegar a um consenso antes que o trabalho principal em um recurso comece. É exatamente isso que fazemos quando o CloudBees criar um novo recurso, por isso temos a oportunidade de mudar o curso, dependendo da resposta recebida. Esse é o elemento de planejamento que pudemos implementar em nosso trabalho. Como somos um projeto de código aberto, não podemos dizer diretamente a outros participantes do projeto o que fazer. Às vezes eles ouvem nossa voz, às vezes não.
Quanto aos nossos planos para os próximos seis meses, provavelmente continuaremos trabalhando em muitos de nossos empreendimentos atuais, incluindo Jenkins X. Alguns funcionários do CloudBees e muitos colaboradores de terceiros trabalham nele. Espero que a Configuração como Código se torne mais popular entre os desenvolvedores de plugins. De modo geral, já criamos a base para isso, agora precisamos configurar alguns plugins para que possam ser conectados corretamente através deste sistema. Finalmente, se surgirem novos PEC, trabalharemos neles.
Kirill: Bem, vamos torcer para que o JEP não seja patenteado :) Pergunta para você como o autor de Jenkins - cuja idéia foi o Scripted Pipeline?
Kosuke: Esta é uma pergunta interessante. O fato é que muitas iniciativas na comunidade geralmente não atingem uma massa crítica e permanecem no nível experimental. Antes de começarmos a trabalhar no Pipeline, no mesmo espaço, as pessoas já tentavam fazer algo semelhante e tivemos a oportunidade de nos familiarizar com essas tentativas. Portanto, não fomos, de fato, os inventores do Pipeline. Um desses antecessores foi o plug-in Build Flow, criado por um dos funcionários da CloudBees antes de ingressar na empresa. Eu acho que o termo "ecossistema" é muito bem-sucedido - tudo realmente acontece como em um ecossistema real, uma tecnologia criada por alguém em constante evolução e mudança.
Ruslan: Você influenciou a implementação do pipeline com script?
Kosuke: Sim, em sua versão original.
Kirill: Como sabemos, existem duas maneiras de implementar qualquer DSL - estaticamente e dinamicamente. Por que a abordagem dinâmica foi escolhida para o pipeline com script?
Kosuke: Receio não entender bem o que exatamente você quer dizer com abordagens estáticas e dinâmicas.
Kirill: Com uma DSL estática, temos alguma confiança em nosso código antes da execução. Por exemplo, com o DSL em Java, você precisa conhecer todas as APIs e interfaces com antecedência. Com uma abordagem dinâmica, realizamos a verificação diretamente na execução. Mesmo se o código for inválido, a máquina ainda tentará executá-lo, apenas gera um erro, se necessário. A versão declarativa do pipeline permite eliminar muitos erros, restringindo a variabilidade no script de construção.
Kosuke: Para ser sincero, isso realmente não importa para mim exatamente quando a compilação acontece. Mas posso falar sobre as configurações gerais que seguimos ao projetar o pipeline com script. Em um certo estágio, um número significativo de usuários do Jenkins foi bastante prejudicado pela complexidade da automação. Era necessário garantir a interação correta de muitos componentes. O código é compilado, os testes são executados e é necessário aguardar até a implantação ser confirmada e assim por diante. , — Infrastructure as Code. , . Scripted Pipeline. , Pipeline , , Scripted Pipeline, . , , . Declarative Pipeline.
: , -, Jenkins, API . -, Scripted Pipeline, DSL. Declarative Pipeline , . — Pipeline Jenkins? , Jenkins.
: , , . , Pipeline, , , . Freestyle Job, Jenkins, . - , , Freestyle Job . , , . , Pipeline . - — , Shared Libraries. , . . , .
: Jenkins. Jenkins 2. API . Jenkins , , , , . , , ?
: , . , . Jenkins. , 800 , 1600 — , , . , . , . « » , , , , , . , , .
: , Java? 15-, 20- . Python 2 Python 3, ? ?
: , , , Java Python. , . , Jenkins , . , . , , . , , , . , , , Jenkins X. , , .
: , !
5-6 JPoint «Superpowers coming to your Jenkins» . , . JPoint ( , ).