BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Lo básico Póngase al día con nuestro contenido introductorio.

Adopción de DevOps tiene beneficios para organizaciones grandes y pequeñas

Es fácil para las organizaciones pequeñas adoptar DevOps. En Jenkins World 2016, las organizaciones más grandes están hablando de cómo alcanzar el éxito.

Para las organizaciones más pequeñas y nuevas empresas, la adopción de DevOps y la opción de utilizar una herramienta...

moderna de integración continua (CI) tiene un camino relativamente sencillo. Sin embargo, para las empresas más grandes que tienen procesos y herramientas de desarrollo heredados ya insertados, la adopción de DevOps no es tan fácil. Pero la superación de los obstáculos para la adopción de DevOps, incluso para las grandes organizaciones, bien vale la pena el esfuerzo, y ese es un sentimiento popular entre los asistentes y ponentes de Jenkins World 2016.

"Todas las nuevas empresas comienzan con una construcción automatizada con Jenkins. Es fácil para los departamentos pequeños", dijo Scott Hickey, arquitecto principal de empresa en Mutual of Omaha Insurance Co. "Ellas se preguntan por qué no todo el mundo lo está haciendo, pero la brecha entre lo fácil que es para un pequeño equipo de desarrollo automatizar la implementación con Jenkins y lo difícil que es para una gran organización llevar todos sus proyectos a una integración continua (CI) es grande".

Así que, ¿cómo hizo la transición Mutual of Omaha? "Tuvimos la mayor parte de los proyectos construyéndose en ANT", dijo Hickey. "Tuvimos Jenkins, pero una construcción solo se produjo cuando la gente quiso hacer un despliegue. Eso pondría ese artefacto en un depositario IDE [entorno de desarrollo integrado], y nuestra aplicación Grails tiraría de él hacia fuera y lo pondría en nuestros grupos".

Ahora, Mutual está subiéndose al bote de la adopción de DevOps de una manera más integral. "Lo que hemos estado tratando de hacer es implementar una plataforma de integración continua. Tal vez no suene tan revolucionario, pero para nosotros lo es. Estamos armando una secuencia usando cosas como Apache Subversion y Jenkins para la construcción [y] prueba automática", dijo Hickey. "El siguiente paso hace análisis de código estático con Sonar. Luego, generamos un artefacto para Artifactory. Pero todavía estamos haciendo implementación manual. Aún no estamos en la nube. Estamos desplegando grupos de WebSphere o Tomcat. Estamos trabajando en la construcción de una nube privada en este momento".

El viaje de adopción de DevOps en sí le ha dado a la organización un mejor manejo del desarrollo rápido e iterativo. Ahora bien, es no solo la gestión de proyectos lo que es ágil. El proceso de ingeniería de software en sí se está volviendo ágil por primera vez. "En el pasado, no había realmente ningún énfasis en las pruebas; solo se trataba de tener una construcción repetible. Ahora, estamos construyendo en cada check-in". Con Sonar, Jenkins y Gradle, el equipo de Hickey tiene una retroalimentación constante y alta visibilidad de la calidad del código utilizando la automatización de la construcción y de las pruebas. El resultado es un cambio cultural que impulsa a los equipos de desarrollo a comprobar los códigos y las pruebas juntos, por lo que la calidad se evalúa de forma continua.

Jenkins allana el camino desde la integración continua a la entrega continua

Para las organizaciones que ya están manejando la integración continua (CI), el siguiente paso en el ciclo de vida de la adopción de DevOps es pasar desde la integración continua a la entrega continua. La entrega continua (CD) sí misma es un tema un tanto mal entendido, ya que muchos imaginan la CD como un flujo constante de entrega de software, sin pausas o intervención manual, donde el código pasa por el proceso de construcción, y luego va directamente a la implementación y producción. Pero la realidad es más matizada. "CD se trata de tener su software en un estado para ser entregado. No significa necesariamente empujar cada cometido hacia sus clientes", según el colaborador de Jenkins, R. Tyler Croy. "Puede haber requisitos de negocio o pruebas manuales que tienen que ocurrir. Si usted está construyendo una aplicación Android, no va a tratar de empujar un cometido de 10 MB todos los días de la semana. Eso sería una locura".

Sin embargo, incluso si no se toma literalmente, CD debe ser ubicua en principio. "Quiero que la gente entienda que la adopción de DevOps y CD [son] aplicables a cada pieza de software que se entrega a los clientes", dijo Croy. "Por ejemplo, puede tener un suministro continuo de incrustados, o tener publicaciones Android en Google Play Stores y canales de datos".

Con el software viviendo en todas partes, desde los móviles a la internet de las cosas, no hay razón para que el modelo CI/CD esté restringido a las aplicaciones tradicionales. "No se trata solo de SaaS [software como servicio] o de construir aplicaciones web. Cualquier software que se entrega a los clientes en cualquier punto, se puede beneficiar de la adopción de esta secuencia de código y práctica de entrega. El objetivo es llevar el código al cliente. CD se trata de automatizar esos procesos, y Jenkins es una buena herramienta para eso".

Próximos pasos

Más sobre DevOps:

La infraestructura como código es el principal reto de TI para DevOps

El futuro de las redes viene de la mano con DevOps

Hotel se acelera con modelo sobrealimentado de DevOps

Construir un entorno DevOps con microservicios y contenedores

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close