Por qué Jenkins se está convirtiendo en el motor de devops

Tendencias como el desarrollo ágil, DevOps y la integración continua hablan de la necesidad de la empresa moderna de crear software de forma hipereficiente y, si es necesario, hacerlo en un momento.

Esa última maniobra es la forma en que CloudBees se convirtió en la empresa que es hoy. Una vez un proveedor independiente de PaaS en la nube pública para codificadores Java (calificado altamente por Andrew Oliver en "¿Qué maldita PaaS debería usar?"), CloudBees dio un giro drástico hace 18 meses para relanzarse como el proveedor líder de Jenkins, un programa abierto muy popular. herramienta de origen para gestionar el proceso de desarrollo de software.

Según la directora ejecutiva Sasha Labourey, como proveedor de Java PaaS, CloudBees había estado "creciendo bien", pero "muchos de los tipos más grandes con los controles más grandes" dudaban en comprometerse en un mercado de PaaS volátil que carecía de estandarización. Al mismo tiempo, Jenkins despegaba como un cohete, y Labourey vio una gran oportunidad, particularmente porque CloudBees ya estaba ofreciendo Jenkins como un servicio y ya había contratado a Kohsuke Kawaguchi, el creador de Jenkins. La guarnición de Jenkins se convirtió en el plato principal.

El gigante de Jenkins

¿Qué hay detrás de la popularidad de Jenkins? En pocas palabras, Jenkins se ha convertido en el estándar de código abierto para administrar el lado de desarrollo de devops, desde la administración del código fuente hasta la entrega del código a la producción. Según Labourey, "La comunidad ve a Jenkins como un motor de orquestación y automatización ... Creo que la razón por la que Jenkins se ha convertido en el motor de facto es porque es extremadamente conectable". Ha surgido un ecosistema de más de 1.100 complementos, que permite a los clientes agregar todo tipo de funcionalidades e integrar Jenkins con todo, desde Active Directory hasta GitHub y OpenShift PaaS.

Jenkins es una solución de integración continua (CI) y entrega continua (CD). La idea de CI es fusionar código de desarrolladores individuales en un proyecto varias veces al día y probarlo continuamente para evitar problemas posteriores. CD lleva esto un paso más allá para garantizar que todo el código combinado esté siempre listo para producción. Jenkins permite a los desarrolladores automatizar este proceso tanto como sea posible, hasta el punto de implementación. Labourey proporciona un ejemplo:

Supongamos que una empresa está utilizando Chef o Puppet para implementar en AWS. Jenkins no va a reemplazar eso. Jenkins va a llamar a Puppet para que lo haga. Bien, aquí están los bits, así que llamemos a este script de Puppet y veamos cómo funciona. Y el resultado de la ejecución de Puppet será importante para Jenkins porque podría decidir desenrollar la implementación y tomar más acciones. Lo llamamos "la tubería". Realmente es esta serie de pasos. Pueden ser cinco pasos o 50 pasos.

Jenkins sirve como motor de flujo de trabajo para administrar esta canalización de CI / CD desde el origen hasta la entrega, dice Labourey, pero en el camino se pueden utilizar muchas herramientas diferentes para realizar diferentes funciones.

Docker es una de esas herramientas, y Docker, junto con Jenkins, está teniendo un efecto profundo en los equipos de desarrollo. Todo el mundo sabe que Docker agiliza el desarrollo y hace que la implementación sea mucho más fácil, pero Labourey observa que también ayuda a que los desarrolladores sean honestos: ya no pueden culpar a una mala configuración del entorno de desarrollo cuando una compilación falla y se quema. En una máquina física, el entorno de desarrollo se corrompe gradualmente, provocando inadvertidamente que se rompan las compilaciones. Pero cuando está codificando sobre una imagen prístina de Docker, solo tiene su propio código defectuoso a quien culpar cuando las compilaciones no se ejecutan.

Juntos, Jenkins y su ecosistema integrado proporcionan la infraestructura de software de coordinación para el desarrollo ágil y, de manera más amplia, forman “el núcleo de la iniciativa devops”, dice Labourey.

Llegando desde aquí

Toda esta automatización y eficiencia de DevOps suena genial, pero ¿qué pasa con las organizaciones que apenas se han concentrado en el desarrollo ágil? Labourey ofrece consejos para sumergirse en CI / CD:

Creo que la mejor forma de hacerlo es empezar de a poco. Elige un proyecto. No diga: "Está bien, ahora somos una tienda de entrega continua, todo va de esta manera". Comience con un equipo que esté dispuesto, que sea quizás más flexible que otros equipos, quizás miembros más nuevos del equipo, menos arraigados en la forma actual de hacer las cosas. Elija un proyecto sencillo. No intente usar eso como una forma de decir que si funciona, todo funcionará. No intente fallar; intenta triunfar. Elija un equipo dispuesto, elija un proyecto fácil y llegue allí. Este equipo será tu mejor vendedor porque ahora puedes demostrar que funciona. Pueden hablar sobre cómo su trabajo mejoró porque, francamente, la forma antigua es aburrida.

Parte del proceso, señala Labourey, es "extraer el conocimiento que se asienta silenciosamente en el cerebro de las personas y ponerlo en la tubería como lógica". Eso no sucede de la noche a la mañana. A menudo, las organizaciones de desarrollo comienzan elaborando la IC y avanzan hacia el DC con el tiempo.

Las organizaciones de desarrollo tienden a tener requisitos muy diversos y muy específicos. Por lo tanto, CloudBees ofrece una versión de SaaS genérica basada en suscripción ejecutada por CloudBees y una versión de "SaaS privada", que los clientes pueden implementar en AWS o Azure (o localmente en OpenStack) y personalizarla a su gusto.

Es difícil exagerar la importancia de orquestar, automatizar y optimizar el proceso de desarrollo. CI / CD es fundamental para DevOps, y una implementación exitosa de DevOps a su vez tiene implicaciones que se extienden más allá de la TI hasta la propia empresa. La mejora continua del software mejora continuamente los productos y servicios. Tesla, por ejemplo, tuvo un serio revés cuando uno de sus modelos se incendió, y la implementación de una actualización de software solucionó el problema de la noche a la mañana.

"Es interesante si obtiene un 10 por ciento más de eficiencia; si gasta $ 100 millones al año en TI, bueno, tiene $ 10 millones que puede gastar en otro lugar", dice Labourey. "Pero el beneficio real es cuando la empresa se da cuenta de que al aprovechar esas herramientas y esa forma de hacer las cosas, pueden aumentar las ventas en un 10 por ciento".