¿Usas Jenkins? Lo más probable es que sí, porque este es el proyecto más popular de esta clase hasta la fecha. Siempre me interesó hablar con uno de los desarrolladores y hacerle un par de preguntas difíciles. Aquí, no solo tenemos un desarrollador, sino el creador del propio Jenkins: Kohsuke Kawaguchi .
Como saben, Jenkins es un proyecto de código abierto con una licencia MIT. Más recientemente, se celebró la conferencia FOSDEM, la conferencia más grande del mundo dedicada al software libre. Gratis, abierto, con docenas de oradores de todo el mundo. Esto significa que puedes conocer a cualquiera allí, incluso al creador de Jenkins. Con un pequeño grupo de amigos y colegas en el Grupo JUG.ru, hicimos un aterrizaje sorpresa allí y pudimos grabar una buena entrevista con el creador de Jenkins.
Entonces, en nuestro estudio virtual, Koske Kawaguchi (quien se presentará y explicará todo con más detalle a continuación), Ruslan Akhmetzyanov ARG89 del Grupo JUG.ru y Kirill Tolkachev tolkkv de CIAN , nuestro orador constante, gurú Groovy, Gradle, Spring y la pila de tecnología Netflix, a quien puedes saber del podcast Debriefing.
Ruslan: Hola. Primero, cuéntanos un poco sobre ti y sobre Jenkins.
Kosuke: Mi nombre es Koske, conocido principalmente como el creador de Jenkins y CTO de CloudBees. Jenkins es una herramienta con la cual los desarrolladores automatizan varias etapas del proceso de entrega de software. Personalmente, conozco a varios programadores de Rusia que usan Jenkins, y estaré encantado de conocer a otros.
Kirill: También me presentaré, soy desarrollador y también organizo el Moscow Jenkins Area Meetup (JAM). Tengo una amplia experiencia en el uso de Jenkins, especialmente la canalización con guión / declarativa. ¿Me puede decir qué está haciendo el CTO de la compañía que desarrolla Jenkins?
Kosuke: Una de las tareas de mi equipo es interactuar con la comunidad. El éxito de nuestra empresa depende en gran medida del éxito del proyecto de código abierto. Otra tarea importante es educar al resto de las personas de la empresa sobre cómo funciona el código abierto. En general, tenemos una relación muy interesante entre la empresa y la comunidad: todos aprenden algo unos de otros, y prestamos mucha atención a esta interacción.
También preguntó qué función desempeña el director técnico. El hecho es que esta función ha evolucionado a medida que la empresa ha crecido. Al principio, era algo así como un programador principal e hice mucho trabajo técnico. Pero a medida que la compañía se desarrolló, otras personas gradualmente comenzaron a hacer este trabajo. Por ejemplo, un equipo separado comenzó a tratar con Pipeline. Periódicamente me comunico con ellos para tener una idea de lo que están haciendo, a veces doy consejos. Pero toman todas las decisiones relacionadas con el diseño y el desarrollo por su cuenta. En general, esta evolución de mi papel fue muy interesante, constantemente tengo que adaptarme.
Kirill: ¿ Si te entiendo correctamente, entonces tu enfoque ha cambiado de problemas técnicos a trabajar con la comunidad?
Kosuke: Sí, mucho de lo que estoy haciendo está relacionado con esto. Hay cosas que solo el fundador de una empresa puede decir. Por lo tanto, parte de mi actividad es, relativamente hablando, agitar una bandera y alentar a la comunidad en una determinada dirección cuando es necesario un cambio de rumbo. Como sucedió, por ejemplo, el año pasado. Además, nosotros y el equipo estamos comprometidos con la promoción de Jenkins: explicamos cuáles son nuestros objetivos, qué dificultades estamos tratando de superar. Además, cuando necesito hacer una presentación sobre el estado general de las cosas, inspiro más confianza. Así es como se ve mi actividad en breve.
Kirill: ¿Y cuántos años atrás comenzó esta desviación del trabajo técnico hacia el trabajo organizacional? ¿Puedes contar la historia de Jenkins y cómo ha cambiado tu papel a medida que el proyecto creció?
Kosuke: El proyecto apareció en 2004, y al principio trabajé en él por las tardes y los fines de semana, es decir, era una especie de pasatiempo. Pero gradualmente el proyecto creció. Pasé bastante tiempo creando esta plataforma en la que otras personas podrían escribir sus aplicaciones. Con el tiempo, surgió un ecosistema y una comunidad de desarrolladores, algunos de los cuales eran de Rusia, por ejemplo, Oleg Nenashev (Twitter: @oleg_nenashev ), quien escribió un subsistema muy interesante sobre Jenkins. A medida que el proyecto ganó popularidad, la necesidad de una mejor interacción con los usuarios y su capacitación se agudizó. Por lo tanto, comencé a hacer más con estas cosas. Finalmente, alrededor de 2010, Jenkins se hizo tan popular que decidí dedicar todo mi tiempo a él y establecer una empresa. A partir de este momento, se agregó el trabajo en la organización de la empresa para trabajar con la comunidad. La empresa estaba creciendo y comencé a hacerme la pregunta: ¿qué tipo de actividad no puede realizar nadie excepto yo? Tanto en la empresa como en la comunidad hay muchas personas capaces que están felices de estar listas para asumir responsabilidades adicionales. Poco a poco, comenzaron a hacer mucho de lo que yo solía hacer. Entonces, en general, nuestro camino se parecía.
Kirill: gracias. Hoy, Jenkins es el sistema de CI más popular. ¿Y qué tan común es la versión comercial de Jenkins en comparación con otros sistemas comerciales de CI? Por ejemplo, ¿con Travis Enterprise o con sistemas que pueden funcionar localmente?
Kosuke: El código abierto Jenkins es un gran proyecto, tiene muchos usuarios. CloudBees tiene una escala mucho más pequeña. Por lo tanto, si logramos convertir incluso el uno por ciento de la base de usuarios de Jenkins en usuarios de CloudBees, este será un resultado muy grande. Todas las empresas basadas en productos de código abierto trabajan con este principio. Otra pregunta importante es cuánto podemos ayudar a las personas cuyos problemas debe resolver nuestro producto. Calculamos cuán efectivo es nuestro soporte técnico y, si recuerdo las estadísticas correctamente, en general, nuestros servicios los satisfacen.
Kirill: ¿Te refieres a aquellos que usan la versión paga? ¿O los que también tienen libre?
Kosuke: Los dos. Es decir, si una persona compra un producto, se le proporcionará asistencia, pero también se puede obtener sin utilizar software privativo.
Kirill: Es decir, usted actúa como intermediario entre los desarrolladores y sus usuarios, de código abierto y comercial. ¿Entiendo correctamente que también tiene las tareas de visión del producto?
Kosuke: Esto no es del todo cierto, tenemos un equipo de producto separado. No soy un representante del usuario, pero constantemente tengo reuniones con muchas personas, usuarios y no solo me mantengo en contacto con la comunidad. Por ejemplo, tengo una columna "Resumen con avanzado" para otros empleados de la empresa. En estas publicaciones, hablo sobre cómo nuestros usuarios escriben software y lo que significa para Jenkins. Así que estoy tratando de influir en las decisiones que toma el equipo del producto.
Kirill: Aparentemente, juegas un papel importante en la empresa. Pasemos a temas más personales. ¿Cuál es su característica favorita de Jenkins de la que podría hablar de la mañana a la noche?
Kosuke: Bueno, hablar de la mañana a la noche será difícil. Ahora estoy más interesado en cómo funciona la organización, creo que esto se debe a mi función en ella. Cuando trabajaba solo, mi atención estaba mucho más centrada en las características individuales. Ahora no lo creo, así que es difícil para mí responder tu pregunta.
Kirill: Entonces, quizás, ¿recuerdas alguna característica que se implementó hace años y de la que estabas muy orgulloso?
Kosuke: Puedo hablar sobre una de las características importantes recientes en las que trabajamos, creo que será más interesante para los usuarios. Este es un proyecto del año pasado, Jenkins Configuration as Code . Vimos que nuestros usuarios estaban pasando gradualmente de administrar Jenkins con un clic del mouse en la GUI a configurar a través del archivo de configuración en el repositorio de git. La necesidad de un proyecto de configuración como código se sintió durante mucho tiempo, y se escribieron muchas muletas temporales para realizar esta función. Pero ninguna de estas empresas era lo suficientemente grande. Finalmente, logramos reunir a las personas de la comunidad que estaban interesadas en este nuevo proyecto y crear una herramienta bastante grande y reflexiva. Muchos aspectos de este proyecto resultaron muy bien, y ganó una popularidad bastante amplia, que no puede dejar de alegrarse.
Puedes recordar otro proyecto, Jenkins X, que es una evolución en una dirección completamente diferente. Fue creado específicamente para trabajar con Kubernetes. Gracias a esta especialización, podemos lograr una integración fluida y ocultar la complejidad que surge debido a la integración y a la conexión de los procesos de entrega continua. Como resultado, facilitamos la implementación de las mejores prácticas, en nuestra opinión. Creo que gracias a este proyecto, Jenkins estará disponible para una gran cantidad de personas que realizan acciones bastante estándar y no quieren perder mucho tiempo en la configuración, que necesita que todo funcione.
Ruslan: ¿Usas Jenkins cuando escribes Jenkins?
Kosuke: Sí, el proyecto Jenkins tiene su propio Jenkins. De hecho, tenemos una gran instancia que ejecuta una revisión pull-rique en cada complemento y núcleo. Además, hay una copia para el trabajo especialmente importante relacionado con la seguridad y las vulnerabilidades, ya que el desarrollo de características para la seguridad se lleva a cabo en un repositorio propietario y separado. Finalmente, hay una tercera instancia para tareas aún más importantes como firmar claves y cosas relacionadas con los lanzamientos. Además de estos tres, una copia separada funciona en mi casa durante todo el día.
Kirill: Mencionaste a Jenkins X. Jenkins en sí es como un cuchillo suizo, con complementos que puede hacer cualquier cosa. Pero Jenkins X, por el contrario, es altamente especializado, existe para Pipeline y trabaja con Kubernetes. ¿A qué tipo de estrategia técnica se adhieren usted y su empresa? ¿Soportan solo Jenkins y Jenkins X? ¿O, además de esto, también habrá Jenkins XX para los grupos de Mesos, Jenkins XXX para Cloud Foundry y así sucesivamente?
Kosuke: Creo que mucho depende de la reacción de la comunidad. Tener una plataforma universal es, por supuesto, muy importante. La pregunta es quién implementa exactamente esta flexibilidad. Hoy, los usuarios suelen tener acceso directo a él. Esto es conveniente si usted es una gran empresa y está haciendo algo inusual. Pero al mismo tiempo, conozco a muchas personas que no necesitan tanta flexibilidad. Imagina que vienes al comedor y pides que hagas un sándwich. Se le ofrece la opción de siete tipos de pan, cinco tipos de mantequilla, cuatro tipos de queso y debe decidir sobre todos los ingredientes. Pero no necesita todas estas opciones, solo necesita un sabroso sándwich y no quiere descubrir cómo hacerlo bien. Sé que muchas personas tienen esta actitud hacia Jenkins y quieren toda la flexibilidad para permanecer de nuestro lado. Jenkins X es el primer paso serio en esta dirección. Si este proyecto continúa siendo exitoso, me encantaría intentar hacer algo similar para firmware e IoT, plataformas móviles o aprendizaje automático. Creo que hay muchos mercados verticales donde las personas solo necesitan una herramienta que les permita llevar rápidamente el producto a producción. Usted es de Rusia, ¿es muy probable que sepa sobre JetBrains?
Kirill: por supuesto.
Kosuke: Creo que siguen una estrategia similar. Tienen una base muy flexible, sobre la cual hay muchos complementos más especializados, en los que, en esencia, los mismos elementos se ensamblan de diferentes maneras. Los usuarios les están agradecidos por esto, y realmente me gusta su enfoque.
Kirill: Durante muchos años he estado observando la misma imagen en muchas comunidades cuando te aconsejo que uses uno u otro complemento, por cierto, ahora https://plugins.jenkins.io me ayuda mucho, todos los complementos aprobados están ahí. El problema es que las personas intentan en todos los casos utilizar una herramienta universal, que a menudo no es adecuada para un caso en particular. Por lo tanto, ahora generalmente solo recomiendo una herramienta: Pipeline, que es una herramienta ideal que es adecuada en todas las situaciones. Pero surge un nuevo problema. Las personas intentan utilizar la canalización con secuencias de comandos o la canalización declarativa sin comprender cómo se organizan internamente. Hay problemas con la infraestructura, con el establecimiento de correspondencia entre nodos, el intercambio de datos, el tráfico inusual aparece entre el agente y el maestro, o problemas con el escalado en el maestro. ¿Qué herramienta, desde su punto de vista, es mejor: la que indica la única forma correcta de resolver el problema, como Jenkins X? ¿O una herramienta como Scripted Pipeline que te pregunta qué es exactamente lo que tienes en mente?
Kosuke: No estoy seguro de entenderte correctamente, pero intentaré responder. En japonés, existe la palabra "kata", no sé cómo traducirla con precisión. Se usa, entre otras cosas, en judo. Estamos hablando de movimientos estrictamente definidos que los estudiantes aprenden: por ejemplo, levantar una mano de cierta manera para desviar un cierto golpe. Hice un poco de esto, así que sé el más simple de ellos. El desafío es memorizar un conjunto de movimientos simples, algún tipo de patrones o mejores prácticas. Pero esto es solo el comienzo. Conociendo esta base, puede continuar dejándola correctamente si la situación lo requiere, sin violar los movimientos básicos. Estudias tu propio espacio, tu territorio, pero al mismo tiempo, conocer la base común te ayuda de todos modos. Si no la conoce, siempre se preguntará: ¿estoy haciendo lo correcto? Incluso si lo que escribiste funciona, aún tienes dudas.
En general, su pregunta me recordó a kata. Creo que tenemos una situación similar con Jenkins. Jenkins X proporciona una base, y a medida que comienza a comprenderlo más profundamente, puede dejarlo si es necesario con la ayuda de complementos y otras cosas. Por supuesto, Jenkins X tiene que sacrificar la flexibilidad para proporcionar una mejor experiencia con Kubernetes. Pero el hecho de que Jenkins X lo empuje hacia las mejores prácticas no significa que se le esté privando de una opción. En general, esto es cierto en relación con cualquier software. Es solo que con Jenkins X tuvimos un cambio importante en la mentalidad. Anteriormente, creábamos solo los elementos clave del sistema: la plataforma y los complementos, dependía del usuario ensamblarlos. Con Jenkins X, la comunidad ha adoptado un nuevo enfoque y, en mi opinión, este es un paso muy importante.
Kirill: Si no te importa, tendré dos preguntas más. ¿Qué característica te ha traído más problemas en el último año? Cada proyecto tiene períodos difíciles, ¿puede decirnos cómo se veían?
Kosuke: Realmente hemos arruinado nuestras vidas varias veces. El problema es que a medida que Jenkins creció, nuestro proyecto comenzó a atraer cada vez más atención de otras compañías y sus equipos de seguridad que comenzaron a buscar agujeros en Jenkins. Por lo tanto, el número de informes de vulnerabilidad que nos llegan desde el exterior comenzó a crecer exponencialmente. A veces se volvió un poco aterrador debido a esto, especialmente cuando consideras que algunas de estas solicitudes venían con una fecha límite, a la que necesitábamos cerrar la vulnerabilidad. Esto fue especialmente difícil cuando se trataba de características creadas por la comunidad. Además, al instalar actualizaciones con vulnerabilidades fijas, los usuarios a veces se ven interrumpidos. Estamos trabajando duro para evitar que esto suceda, porque de lo contrario los usuarios tendrán miedo de instalar actualizaciones de seguridad, lo cual es extremadamente indeseable.
Kirill: ¿Tienes algún órgano de gobierno que decida qué características se incluirán en el lanzamiento? Díganos cómo se toman esas decisiones y ¿pueden los usuarios solicitar incluir algunas características en el lanzamiento? Si pueden, ¿a quién se le dará prioridad: a los usuarios de couldbees o al código abierto Jenkins? Finalmente, si es posible, cuéntenos sobre sus planes para los próximos seis meses a un año.
Koske: Hay un punto interesante aquí: CloudBees no es dueño de Jenkins, estos son dos proyectos separados, cada uno con su propia estructura de toma de decisiones. CloudBees es simplemente el mayor contribuyente de Jenkins, con muchos CloudBees al mismo tiempo trabajando en la comunidad. En los últimos años, hemos estado tratando de crear estructuras de control más claras en Jenkins que hagan exactamente lo que acaba de pedir. Con este fin, creamos el Proceso de mejora de Jenkins ...
Cyril: Perdón por interrumpir, ¿se abrevia como JEP, como en Java?
Kosuke: por supuesto. Obviamente, no inventamos este concepto, sino que lo tomamos prestado de Python, Java y algunas otras comunidades, porque allí ya se ha establecido. La idea principal aquí es que la comunidad debería poder expresar su opinión y llegar a un consenso antes de que comience un trabajo importante sobre una característica. Esto es exactamente lo que hacemos cuando CloudBees va a crear una nueva función, por lo que tenemos la oportunidad de cambiar el curso dependiendo de la respuesta recibida. Este es el elemento de planificación que pudimos implementar en nuestro trabajo. Como somos un proyecto de código abierto, no podemos decir directamente a otros participantes del proyecto qué hacer. A veces escuchan nuestra voz, a veces no.
En cuanto a nuestros planes para los próximos seis meses, lo más probable es que continuemos trabajando en muchos de nuestros esfuerzos actuales, incluidos Jenkins X. Algunos empleados de CloudBees y muchos colaboradores externos trabajan en ello. Espero que Configuration as Code sea más popular entre los desarrolladores de plugins. En general, ya hemos creado la base para ello, por lo que ahora necesitamos configurar algunos complementos para que puedan conectarse correctamente a través de este sistema. Finalmente, si surgen nuevos JEP, trabajaremos en ellos.
Kirill: Bueno, esperemos que JEP no esté patentado :) Pregunta para usted como autor de Jenkins, ¿cuya idea fue Scripted Pipeline?
Kosuke: Esta es una pregunta interesante. El hecho es que muchas iniciativas en la comunidad a menudo no alcanzan una masa crítica y permanecen en el nivel experimental. Antes de comenzar a trabajar en Pipeline, en el mismo espacio las personas ya intentaron hacer algo similar, y tuvimos la oportunidad de familiarizarnos con estos intentos. Así que, de hecho, no fuimos los inventores de Pipeline. Uno de estos predecesores fue el complemento Build Flow, escrito por uno de los empleados de CloudBees antes de unirse a la empresa. Creo que el término "ecosistema" es muy exitoso: todo sucede realmente como en un ecosistema real, una tecnología creada por alguien está en constante evolución y cambio.
Ruslan: ¿Has influido en la implementación de Scripted Pipeline?
Kosuke: Sí, en su versión original.
Kirill: Como sabemos, hay dos formas de implementar cualquier DSL: estática y dinámicamente. ¿Por qué se eligió el enfoque dinámico para la canalización programada?
Kosuke: Me temo que no entiendo lo que quieres decir exactamente con enfoques estáticos y dinámicos.
Kirill: Con un DSL estático, tenemos cierta confianza en nuestro código antes de la ejecución. Por ejemplo, con DSL en Java, necesita conocer todas las API e interfaces de antemano. Con un enfoque dinámico, llevamos a cabo la verificación directamente en la ejecución. Incluso si el código no es válido, la máquina aún intentará ejecutarlo, solo arroja un error si es necesario. La versión declarativa de la tubería le permite eliminar muchos errores al reducir la variabilidad en el script de compilación.
Kosuke: Para ser honesto, no me importa exactamente cuándo ocurre la compilación. Pero puedo hablar sobre la configuración general que seguimos al diseñar la Tubería con script. En cierta etapa, un número significativo de usuarios de Jenkins se vio muy obstaculizado por la complejidad de la automatización. Era necesario asegurar la interacción correcta de muchos componentes. Se compila el código, se ejecutan las pruebas, luego debe esperar hasta que se confirme la implementación, etc. , — 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 ( , ).