Kohsuke Kawaguchi, criador de Jenkins e CTO da CloudBees, palestrou no Jenkins World, em Nice, sobre cinco iniciativas em curso para modernizar a popular ferramenta CI/CD. O objetivo é abordar as dores do envelhecimento que Kawaguchi discutiu em um post no início deste ano, em particular, o que ele chamou de "Jenkinsteins" que surgiram: instalações centralizadas inchadas da ferramenta usada por um grande número de projetos e equipes, levando a um mau desempenho, bem como dependências e pesadelos de administração. As iniciativas giram em torno de Jenkins Evergreen, Jenkins Pipeline (Blue Ocean), Jenkins Configuration-as-Code, Jenkins X e Cloud-Native Jenkins. Cada um deles está em um estágio diferente de desenvolvimento e evoluirá independentemente dos outros.
Uma experiência pronta para uso mais rápida é o objetivo da Jenkins Evergreen, fornecendo baterias pré-montadas, incluídas em distribuições que exigem menos esforço de administração e configuração. Além disso, o Blue Ocean (um plug-in amplamente usado hoje em dia com visualização mais limpa dos pipelines) se tornará a interface do usuário padrão (uma linha de tempo específica não foi anunciada), removendo a necessidade atual de alternar para a interface do usuário clássica toda vez que uma modificação for necessária. O Jenkins Evergreen também trará recursos de auto-atualização, principalmente transparentes para os usuários, disse Kawaguchi. Evergreen está atualmente em beta e não é recomendado para uso em produção ainda.
Kawaguchi disse ao InfoQ que a Evergreen finalmente permitirá a entrega contínua do próprio Jenkins. Ele permitirá a execução de autotestes e diagnósticos pós bootstrap, enviando informações para as equipes correspondentes para monitorar erros e tendências. O retrocesso automático em caso de falha de atualização também será incorporado. Quando perguntado se os usuários poderiam adicionar seus próprios diagnósticos pós-bootstrap, Kawaguchi disse que a equipe que trabalha neste projeto deve considerar essa possibilidade.
O Jenkins Configuration as Code (também conhecido como JCasC) tem como objetivo apoiar a codificação da configuração do Jenkins (com padrões sensíveis) no YAML, para que a instalação e as atualizações do sistema de entrega possam ser totalmente automatizadas. As alterações na configuração do Jenkins podem ser tratadas por uma equipe como qualquer outra solicitação de confirmação e recebimento de código e revertidas em caso de problemas. Finalmente, remover dependências na interface do usuário do Jenkins acelera sua configuração e administração, é menos propenso a erros e mais repetitivo. A versão 1.0 do plugin JCasC foi lançada no início de setembro e está pronta para uso em produção.
O Jenkins X é uma solução separada da Jenkins (embora eles compartilhem o mesmo mecanismo de pipeline nos bastidores) que foi apresentada no início deste ano. Ele fornece uma visão fortemente opinativa para o fornecimento de aplicativos nativos (baseados no Docker e Kubernetes) baseados em uma abordagem GitOps. Um de seus pontos fortes é integrar rapidamente os recém-chegados usando ferramentas comuns de terceiros (Helm charts, Skaffold e Prow a partir da versão 1.3) e automatizando pipelines comuns para pilhas específicas com o recurso de início rápido. A ferramenta de linha de comando jx suporta ainda a automação de tarefas de administração e a configuração de pipelines, bem como clusters e ambientes do Kubernetes. Jenkins X está pronto para uso em produção.
Quando perguntado se criar uma solução separada como Jenkins X poderia ser confuso ou aumentar o atrito para adoção, Kawaguchi disse à InfoQ que Jenkins X "carrega o mesmo DNA" do Jenkins, apenas com uma distribuição diferente. O Jenkins X é direcionado para casos de uso e fluxo de trabalho específicos, com uma superfície de interface do usuário reduzida. Ele também acredita que em algum momento Jenkins X será empacotado com o clássico Jenkins, à medida que a adoção cresce. Kawaguchi prefere ver o ecossistema como um todo:
Jenkins está se tornando maior do que apenas um aplicativo da web e um monte de plugins. É uma plataforma para automação. O que realmente faz Jenkins ter esse poder do ecossistema que muitas pessoas constroem por cima e experimentam e seguem em direções diferentes. Se olhar para Jenkins X, esse DNA está muito presente.
Por fim, a modernização do Jenkins para funcionar como um aplicativo nativo completo da nuvem no Kubernetes, beneficiando-se do aumento da disponibilidade e do desempenho, é o objetivo do grupo de interesse especial do Cloud Native. Esse grupo fará melhorias incrementais na arquitetura do Jenkins para se afastar do design tradicional de cliente/servidor. Por exemplo, suporte a armazenamento externo plugável para dados Jenkins (atualmente mantidos no sistema de arquivos do servidor) e se movendo em direção a um serviço Jenkins sem estado. Não há cronograma no momento para a conclusão desta iniciativa, ou qualquer de suas partes.
No InfoQ, estamos ansiosos para receber informações de nossos leitores. Você já experimentou dores crescentes com o clássico Jenkins? Acha que as iniciativas em andamento vão acabar com essas dores?