Top 11: lo que debes saber sobre DevOps
Tabla de contenido
- ¿Qu茅 es DevOps y de d贸nde viene?
- ¿En qu茅 se diferencian DevOps y Agile?
- ¿En qu茅 se diferencian DevOps y ITIL o ITSM?
- ¿C贸mo encaja DevOps con VisibleOps?
- Los principios fundamentales de DevOps
- ¿Cu谩les son las 谩reas de los patrones de DevOps?
- ¿Cu谩l es el valor de DevOps?
- ¿C贸mo se integran Seguridad y QA en el flujo de trabajo?
- Primer Patr贸n DevOps
- Segundo Patr贸n DevOps
- Tercer Patr贸n DevOps
1. ¿Qu茅 es DevOps y de d贸nde viene?
El t茅rmino DevOps se refiere usualmente al movimiento profesional emergente que aboga por una relaci贸n colaborativa entre Desarrollo y Operaciones de TI, lo que resulta en un flujo r谩pido de trabajo planificado, es decir, un alto ritmo de implementaciones, incrementando simult谩neamente la confiabilidad, la estabilidad, la resistencia y la seguridad del entorno de producci贸n.
¿Por qu茅 Desarrollo y Operaciones TI?
Porque habitualmente es la cadena de valor que se encuentra entre el negocio (donde se definen los requerimientos), y el cliente (donde se entrega el valor).
Los or铆genes del movimiento DevOps se encuentran alrededor de 2009, como resultado de la convergencia de numerosos movimientos adyacentes que se alimentaron mutuamente:
- El movimiento de las conferencias Velocity, especialmente el seminario “10 implementaciones al d铆a”, de John Allspaw y Paul Hammond.
- El movimiento “Infraestructur como c贸digo” (Mark Burgess y Luke Kanies) el movimiento “Infraestructura 脕gil” (Andrew Shafer) y el movimiento “Administraci贸n de sistema 脕gil” (Patrick DeBois).
- El movimiento “Lean Startup” de Eric Ries.
- El movimiento “Integraci贸n continua y liberaci贸n” de Jez Humble
- La amplia disponibilidad de tecnolog铆as en la nube y PaaS (plataforma como servicio), por ejemplo Amazon Web Services.
Uno de los coautores del “Recetario de DevOps”, John Willis, escribi贸 un fant谩stico documento acerca de la “Convergencia de DevOps” aqu铆:
2. ¿En qu茅 se diferencian DevOps y Agile?
Uno de los principios del proceso de desarrollo 谩gil es entregar software funcional en entregas m谩s peque帽as y frecuentes, en oposici贸n al enfoque "Big Bang" de la metodolog铆a en cascada. Esto es muy evidente en el objetivo de las metodolog铆as 谩giles de tener funcionalidades potencialmente entregables, al final de cada iteraci贸n, (normalmente cada dos semanas).
Las altas tasas de implementaciones suelen apilarse en la puerta de Operaciones de IT para ser implementadas. Se atribuye a Clyde Logue, fundador de StreamStep, la frase “Agile fue clave en que Desarrollo reconquistara la confianza del negocio, pero, sin querer, dej贸 a Operaciones rezagado. DevOps es una manera para que el negocio recupere la confianza en la organizaci贸n TI por completo.”
DevOps es especialmente complementario al proceso de desarrollo de software 谩gil, dado que lo extiende y completa la integraci贸n continua y el proceso de liberaci贸n al asegurar que el c贸digo est谩 listo para producci贸n y proveyendo valor al cliente.
DevOps permite un flujo de trabajo mucho m谩s continuo dentro del equipo de operaciones TI. Cuando el c贸digo no se promueve hasta estar en producci贸n, al ritmo al que es desarrollado, (por ejemplo, Desarrollo entrega c贸digos cada dos semanas pero son implementados cada dos meses), las implementaciones se apilan frente a la puerta de operaciones de TI, los clientes no reciben el valor y los despliegues a menudo resultan en caos e interrupciones de servicio.
DevOps tiene un componente inherente de cambio cultural, dado que modifica el flujo de trabajo y las medidas locales de Desarrollo y Operaciones de TI.
3. ¿En qu茅 se diferencian DevOps e ITIL o ITSM?
Aunque la mayor铆a de las personas ve DevOps como una reacci贸n a ITIL (Biblioteca de Infraestructura de TI) o a ITSM(gesti贸n de servicios de TI), yo tengo una visi贸n distinta. ITIL y ITSM son mejores codificaciones de los procesos de negocio que forman la base de Operaciones de TI y de hecho describen muchas de las capacidades que Operaciones de TI necesitan tener en orden para dar soporte al flujo de trabajo al estilo DevOps.
La metodolog铆as 谩gil y de integraci贸n y liberaci贸n cont铆nua son el resultado que genera Desarrollo como salida, las cuales son las entradas para Operaciones de TI. Para acomodar la r谩pida cadencia de liberaciones asociada con DevOps, muchas 谩reas de los procesos ITIL requieren estar automatizados, especialmente los procesos de cambio, configuraci贸n y liberaci贸n.
El objetivo de DevOps no s贸lo es incrementar el ritmo de cambio, sino implementar exitosamente nuevas funcionalidades en producci贸n, sin causar caos ni interrumpir otros servicios, permitiendo la r谩pida detecci贸n y correcci贸n cuando ocurran. Esto se a帽ade a las disciplinas ITIL de dise帽o de servicio y gesti贸n de incidentes y problemas.
4. ¿C贸mo encaja DevOps con VisibleOps?
Visible Ops es una gu铆a prescriptiva para transmitir las mejoras para los equipos de operaciones de alto rendimiento, y uno de los conceptos clave es la noci贸n de c贸mo controlar y reducir el trabajo no planificado.
En muchos aspectos, DevOps es lo opuesto: enfocado principalmente en c贸mo crear un flujo de trabajo planificado r谩pido y estable a trav茅s de los equipos de Desarrollo y de Operaciones. No obstante, DevOps tambi茅n tiene un enfoque m谩s hol铆stico hacia la erradicaci贸n sistem谩tica del trabajo no planificado, aplicando principios de la ingenier铆a resiliente y la gesti贸n y reducci贸n responsable de la deuda t茅cnica.
5. Los principios fundamentales de DevOps
Los principios fundamentales de todos los patrones DevOps pueden derivarse de “Las tres v铆as”. 脡stas describen los valores y filosof铆as que enmarcan los procesos, procedimientos, y pr谩cticas, as铆 como los pasos prescriptivos.
La Primera V铆a enfatiza el rendimiento del sistema entero, en oposici贸n al rendimiento de un departamento espec铆fico que puede ser tan grande como una divisi贸n (por ejemplo Desarrollo u Operaciones de TI), o tan peque帽o como un individuo (por ejemplo, un desarrollador, un administrador de sistema)
El foco est谩 en todos los flujos de valor de negocio habilitados por TI. En otras palabras, empieza cuando se identifican requerimientos (por ejemplo, por el negocio o por IT), se crea la soluci贸n en Desarrollo y se mueve a Operaciones de IT, donde el valor se entrega al cliente como un servicio.
Los resultados de la puesta en pr谩ctica de la Primera V铆a incluyen nunca permitir que un error conocido avance hacia centros de trabajo subsiguientes en el flujo de trabajo, nunca permitir que la optimizaci贸n local cree degradaci贸n global, buscar siempre incrementar el flujo, y buscar siempre alcanzar el conocimiento m谩s profundo del sistema.
La Segunda V铆a consiste en crear bucles de retroalimentaci贸n de derecha a izquierda. El objetivo de casi cualquier proceso de mejora es acortar y amplificar los bucles de retroalimentaci贸n de modo que las correcciones necesarias puedan realizarse cont铆nuamente.
Los resultados de la Segunda V铆a incluyen comprensi贸n y respuesta a las necesidades de los clientes, internos y externos, el acortamiento y amplificaci贸n de los bucles de retroalimentaci贸n, e incluir conocimiento donde sea necesario.
La Tercera V铆a fomenta la creaci贸n de una cultura basada en dos cosas: La experimentaci贸n continua, que requiere asumir riesgos y aprender del 茅xito y del fracaso; y la comprensi贸n de que la repetici贸n y la pr谩ctica son pre-requisitos para alcanzar la maestr铆a.
Necesitamos ambas por igual. La experimentaci贸n y la toma de riesgos son lo que garantiza permanecer en marcha hacia la mejora, incluso cuando signifique entrar en la zona de peligro m谩s all谩 de lo que se haya entrado jam谩s. Y es necesaria la maestr铆a en las habilidades que pueden ayudarnos a salir de la zona de peligro cuando se ha ido demasiado lejos.
Los resultados de la Tercera V铆a incluyen encontrar tiempo para la mejora del trabajo diario, crear rituales que recompensen al equipo por asumir riesgos, e introducir fallos en el sistema para incrementar la resistencia.
6. ¿Cu谩les son las 谩reas de los patrones de DevOps?
Los patrones DevOps se pueden dividir en cuatro 谩reas:
脕rea 1:
Extender a Desarrollo en Producci贸n: Esto incluye extender las funciones de integraci贸n y liberaci贸n continua en Producci贸n, integrando a QA y Seguridad en el flujo de trabajo, asegurando la disponibilidad para Producci贸n del c贸digo y el entorno
脕rea 2:
Crear retroalimentaci贸n de Producci贸n a Desarrollo: Esto incluye crear una l铆nea temporal completa con los eventos de Desarrollo y Operaciones de TI para ayudar a la resoluci贸n de problemas, incluyendo a Desarrollo en reuniones post-mortem sin b煤squeda de culpabilidad, permitiendo a los desarrolladores obtener auto-servicio cuando sea posible y creando radiadores de informaci贸n que muestren c贸mo las decisiones locales afectan las metas globales.
脕rea 3:
Insertar a Desarrollo en Operaciones de TI: Esto incluye poner a Desarrollo en la cadena de escalada de producci贸n, asignar recursos de Desarrollo a la gesti贸n de problemas de producci贸n y ayudar a disminuir deuda t茅cnica, y crear una capacitaci贸n cruzada entre Operaciones y Desarrollo que permita reducir la cantidad de escaladas.
脕rea 4:
Insertar a Operaciones de TI en Desarrollo: Esto incluye insertar o enlazar recursos de Operaciones en Desarrollo, crear historias de usuario reutilizables para el equipo de Operaciones de TI (incluyendo implementaci贸n, gesti贸n del c贸digo en producci贸n, etc.); y definir requerimientos no funcionales que puedan ser usados en todos proyectos.
7. ¿Cu谩l es el valor de DevOps?
Se puede pensar que existen tres beneficios comerciales para las organizaciones que adoptan DevOps:
- Reducci贸n en el tiempo de comercializaci贸n, es decir, con tiempos de ciclo m谩s reducidos y tasas de despliegue m谩s altas.
- Incremento de la calidad, es decir, incremento de disponibilidad, incremento del ritmo de cambios exitosos, reducci贸n de los fallos, etc.
- Incremento de la efectividad organizacional, por ejemplo, basada en el incremento de la inversi贸n del tiempo en las actividades que aporten valor en lugar del gasto, incremento en la cantidad de valor que se ofrece al cliente.
Reducci贸n en el tiempo de comercializaci贸n:
En 2007, en el IT Process Institute, se realiz贸 un an谩lisis comparando 1.500 organizaciones de TI, concluyendo que las organizaciones TI de alto rendimiento eran, en promedio, de 5 a 7 veces m谩s productivas que el resto de las organizaciones. Realizaron 14 veces m谩s cambios, con la mitad de fallos, de los que 4 veces m谩s fueron resueltos al primer arreglo, y los tiempos de las incidencias de severidad 1 fueron 10 veces m谩s cortos. Tambi茅n ten铆an 4 veces menos problemas encontrados repetidamente en auditor铆as, la probabilidad de detectar agujeros en el control interno automatizado era 5 veces menor, y la efectividad en cuanto a las fechas de entrega de los proyectos era 8 veces mejor.
Una de las caracter铆sticas de las organizaciones de alto rendimiento es que se alejan aceleradamente de la manada. En otras palabras, lo mejor contin煤a mejorando. Esto ocurre completamente en el 谩rea de los altos ritmos de implementaciones. Las organizaciones aplicando pr谩cticas DevOps sobrepasan nuestro mejor ejemplo de alto rendimiento en 贸rdenes de magnitud.
Accenture realiz贸 un estudio sobre lo que las empresas de Internet est谩n haciendo, en el cual Amazon afirm贸 que ellos hacen m谩s de 1000 implementaciones al d铆a, ¡con una tasa de 茅xito del cambio del 99,999%!
La capacidad de mantener altos ritmos de implementaci贸n, es decir, tiempos de ciclo r谩pidos, se traduce en valor de negocio de dos formas: Cu谩n r谩pido la organizaci贸n puede pasar de una idea a la entrega del valor al cliente, (es decir del “concepto al cobro” como dir铆an Damon Edwards and John Willis) y en cu谩ntos experimentos la organizaci贸n puede realizar simult谩neamente.
Si una organizaci贸n puede hacer s贸lo una implementaci贸n cada nueve meses, y la competencia puede hacer 10 en un d铆a, existe una desventaja competitiva estructural muy importante.
Los ritmos de implementaci贸n altos tambi茅n permiten una experimentaci贸n r谩pida y constante. Scott Cook, fundador de Intuit, ha sido uno de los m谩s ardientes defensores de una "cultura de la innovaci贸n desenfrenada" en todos los niveles de la organizaci贸n.
Todo empleado deber铆a ser capaz de hacer experimentos r谩pidos y a una alta velocidad... Dan Maurer est谩 a cargo de nuestra divisi贸n de consumo, incluyendo la operaci贸n del sitio web de TurboTax. Cuando entr贸, realiz谩bamos cerca de siete experimentos al a帽o. Al instalar una cultura de innovaci贸n desenfrenada, ahora realizan 165 experimentos en la temporada de declaraci贸n de impuestos. ¿Resultado para negocio? La tasa de conversi贸n del sitio web ha subido un 50%. ¿Resultado para los empleados? Ellos est谩n encantados, porque ahora sus ideas llegan al mercado.
-Scott Cook
La parte m谩s impactante de la historia de Scott Cook es que estaban haciendo todos esos experimentos ¡durante el per铆odo de declaraci贸n de impuestos! La mayor铆a de las organizaciones congelan sus operaciones en las temporadas de mayor importancia (por ejemplo el departamento de ventas al detal puede frecuentemente tener paralizaci贸n de cambios por vacaciones desde Octubre hasta Enero). Pero si se consiguen incrementar los ritmos de conversi贸n, y por lo tanto, las ventas, durante esas temporadas, cuando la competencia no puede, eso se convierte en una aut茅ntica ventaja.
Los pre-requisitos para hacer esto incluyen ser capaz de hacer muchos cambios peque帽os r谩pidamente, sin interrumpir el servicio a los clientes.
Trabajar en la mayor铆a de las organizaciones TI es a menudo desagradecido y frustrante. Mucha gente se siente atrapada en una pel铆cula de terror que no deja de repetirse e impotente para lograr un cambio en la situaci贸n. La gesti贸n abdica su responsabilidad en el correcto funcionamiento de TI, resultando en unas interminables guerras tribales entre los departamentos de desarrollo, operaciones, y seguridad inform谩tica. Y las cosas s贸lo empeoran cuando aparecen los auditores.
Todo esto resulta, inequ铆vocamente en un bajo rendimiento cr贸nico. La vida de un profesional en TI es, a menudo, desmoralizante y frustrante, lo que lleva, normalmente, a sentimientos de impotencia y estr茅s, que se acaban filtrando en cada aspecto de la vida. Desde problemas de salud relacionados con el estr茅s, hasta problemas sociales o tensiones en casa, ser un profesional de TI no s贸lo no es saludable, sino que adem谩s es insostenible.
Como personas, estamos hechos para contribuir y sentir que realmente marcamos la diferencia. Adem谩s de esto, cuando los profesionales de TI piden ayuda a sus organizaciones, a menudo son recibidos con un 'no lo entiendes' o, a煤n peor, con un apenas enmascarado 't煤 no importas'.
8. ¿C贸mo se integran Seguridad y QA en el flujo de trabajo?
Los altos ritmos de implementaci贸n usualmente asociados con el flujo de trabajo de DevOps a menudo ponen una enorme presi贸n sobre los equipos de Control de calidad y Seguridad inform谩tica. Consideremos el caso en el que Desarrollo est谩 haciendo 10 implementaciones diarias, mientras que Seguridad requiere tiempos de espera de cuatro meses para completar las revisiones de seguridad de la aplicaci贸n. A simple vista, se observa una falta de coincidencia entre el ritmo de despliegues y el de revisiones de seguridad.
Un ejemplo del riesgo expuesto por despliegues insuficientemente comprobados es el famoso caso del fallo de Dropbox en 2011, en el que la autenticaci贸n qued贸 desactivada durante cuatro horas, permitiendo a usuarios no autorizados acceder a toda la informaci贸n almacenada.
La buena noticia para Control de calidad y Seguridad Inform谩tica es que las organizaciones capaces de sostener ritmos altos de implementaciones, suelen usar integraci贸n cont铆nua y otras pr谩cticas relacionadas con la liberaci贸n cont铆nua, que a menudo incluyen una cultura de prueba continua. Dicho en otras palabras, cada vez que se va a integrar el c贸digo, se ejecutan pruebas automatizadas y cualquier problema que aparezca debe ser corregido para continuar, del mismo modo que un desarrollador revisa un c贸digo que no se compila.
Mediante la inclusi贸n de las pruebas funcionales, de integraci贸n y de seguridad en las operaciones diarias de Desarrollo, los defectos se detectan y resuelven en menor tiempo que nunca.
Hay un n煤mero creciente de herramientas de seguridad inform谩tica, como Gauntlet y Security Monkey, que ayudan a probar objetivos de seguridad en los procesos de desarrollo y producci贸n.
Una preocupaci贸n habitual genuina es que las herramientas de an谩lisis est谩tico de c贸digo requieren demasiado tiempo para ejecutarse que har铆an que los tiempos de los procesos de prueba e integraci贸n tardasen horas o incluso d铆as en completarse. En esos casos, Seguridad Inform谩tica deber铆a designar los m贸dulos espec铆ficos sobre los que se delegan las funcionalidades de seguridad (por ejemplo, cifrado, autenticaci贸n, etc.). Cada vez que se modifican esos m贸dulos, se ejecutan las pruebas completas de nuevo, de otro modo, la implementaci贸n puede continuar.
Una 煤ltima nota: Los flujos de trabajo de DevOps a menudo tienen m谩s dependencia en la detecci贸n y recuperaci贸n, que en la prueba unitaria est谩ndar. En otras palabras, en el desarrollo de software empaquetado, que dificulta el despliegue de cambios y parches, Control de calidad depende mucho de la prueba del c贸digo para cumplir la funcionalidad antes de ser enviado. Por otro lado, cuando el software se entrega como un servicio y los defectos pueden ser resueltos muy r谩pidamente, Control de calidad puede reducir su dependencia en las pruebas y concentrarse en la monitorizaci贸n de producci贸n para detectar problemas, siempre y cuando se puedan resolver r谩pidamente.
La recuperaci贸n r谩pida de errores de c贸digo puede ser mejorada con la inclusi贸n de feature flags, o activadores de funcionalidades, que activan y desactivan funcionalidades del c贸digo mediante opciones de configuraci贸n, en lugar de tener que descartar una implementaci贸n nueva por completo.
Depender en la detecci贸n y recuperaci贸n para CC es obviamente, mucho m谩s aplicable cuando lo peor que puede ocurrir es la p茅rdida de funcionalidad o del rendimiento requerido. Sin embargo, cuando los errores ponen en riesgo de perder confidencialidad o integridad entre los sistemas o datos, la dependencia no se debe poner en la detecci贸n y recuperaci贸n, sino que debe ser probado antes de desplegar el c贸digo, porque un error de producci贸n generar铆a un incidente de seguridad genuino.
9. Primer Patr贸n DevOps
Demasiado a menudo en los proyectos de desarrollo de software, Desarrollo acaba empleando todo el tiempo de la planificaci贸n en el desarrollo de funcionalidades. Esto no deja tiempo suficiente para tratar los asuntos de Operaciones. Lo que lleva a tomar atajos de forma sucesiva en la definici贸n, creaci贸n y comprobaci贸n de todo en lo que el c贸digo se basa, lo cual incluye las bases de datos, los sistemas operativos, la red, la virtualizaci贸n y dem谩s. 脡sta es, sin duda, una de las principales causas de la tensi贸n perpetua entre Desarrollo y Operaciones, y sus resultados no 贸ptimos.
Las consecuencias de esto son bien conocidas: Entornos con definiciones y especificaciones inadecuadas, procedimientos de implementaci贸n irrepetibles, incompatibilidades entre el c贸digo implementado y el entorno, entre otros.
En este patr贸n, crearemos los entornos al principio del proceso de desarrollo y aplicaremos un pol铆tica que fuerce probar el c贸digo y el entorno juntos. Cuando el equipo de desarrollo utiliza un proceso Agile se puede hacer algo muy sencillo y elegante.
De acuerdo con Agile, se supone que dispondremos de c贸digo entregable y funcional al final de cada iteraci贸n (usualmente cada dos semanas). Modificaremos la pol铆tica de iteraci贸n de Agile para que al final de la iteraci贸n no s贸lo tengamos el c贸digo listo, sin贸 tambi茅n el entorno en el que se implementar谩, desde la primera iteraci贸n, es decir iteraci贸n 0 e iteraci贸n 1.
En lugar de responsabilizar a Operaciones de crear un entorno productivo que se ajuste a las especificaciones, se construir谩 un proceso de creaci贸n del entorno automatizado. Este mecanismo crear谩 el entorno de producci贸n, pero tambi茅n los entorno para Desarrollo y Control de calidad.
Al hacer que los entornos, y las herramientas para crearlos, est茅n disponibles pronto, quiz谩s antes de que el proyecto empiece, los desarrolladores y Control de calidad pueden ejecutar y probar su c贸digo en entornos consistentes y estables, con una desviaci贸n controlada del entorno de producci贸n.
Adem谩s, al mantener esta desviaci贸n entre los distintos entornos (por ejemplo Desarrollo, Control de calidad, Prueba de Integraci贸n, Producci贸n) lo m谩s reducida posible, encontraremos y resolveremos asuntos de interoperabilidad entre el c贸digo y el entorno mucho antes de la implementaci贸n en producci贸n.
Idealmente, el mecanismo de implementaci贸n que hemos construido estar谩 completamente automatizado. Las herramientas que se pueden utilizar incluyen shell scripts, Puppet, Chef, Solaris Jumpstart, Redhat Kickstart, Debian Preseed, etc.
10. Segundo Patr贸n DevOps
Patrick Lightbody, antiguo CEO de BrowserMob, dijo: “Hemos descubierto que cuando despertamos a los desarrolladores a las 2 de la madrugada, se genera un bucle de retroalimentaci贸n fenomenal. Los problemas son solucionados m谩s r谩pido que nunca.”
Esto subraya el problema de que Desarrollo revise su c贸digo el viernes a 煤ltima hora, felicit谩ndose en el estacionamiento de camino a casa, dejando al equipo de Operaciones el trabajo de arreglar el desastre durante todo el fin de semana. Peor a煤n, los defectos y errores conocidos son recurrentes en producci贸n, forzando al equipo de Operaciones a estar cont铆nuamente apagando fuegos, sin que la raz贸n ra铆z del problema se arregle nunca porque Desarrollo se mantiene enfocado en desarrollar nuevas funcionalidades.
Un elemento importante de la Segunda V铆a es acortar y amplificar los bucles de retroalimentaci贸n, y de acercar a Desarrollo a la experiencia del cliente (que incluye tanto al equipo de Operaciones de TI como a los usuarios finales del servicio entregado).
La simetr铆a aqu铆 es destacable: El primer patr贸n trata acerca de hacer que los entornos est茅n disponibles temprano. Consiste principalmente en insertar a Operaciones en Desarrollo, mientras que el segundo patr贸n consiste en poner a Desarrollo en Operaciones.
Aqu铆, ponemos a Desarrollo en la cadena de escalada de Operaciones, posiblemente poni茅ndolos en un tercer nivel de soporte, o incluso haciendo a Desarrollo completamente responsable del 茅xito del despliegue del c贸digo, ya sea ech谩ndolo atr谩s o arreglando los problemas hasta que el servicio sea restaurado al cliente.
La meta no es reemplazar a Operaciones por Desarrollo. En su lugar, consiste en garantizar que Desarrollo vea los efectos de su trabajo y de sus cambios, y de que vivan la realidad de Operaciones lo suficiente para que est茅n motivados para arreglar los problemas r谩pidamente para ayudar con el alcance de los logros globales.
11. Tercer Patr贸n DevOps
Otro problema que ocurre frecuentemente es la falta de estandarizaci贸n en el flujo de valor entre Desarrollo y Operaciones. Ejemplos de esto ser铆an las implementaciones realizados de forma distinta cada vez, o los entornos que re煤nen diferentes propiedades. Cuando esto ocurre, ninguna maestr铆a se crea en las configuraciones o procedimientos de la organizaci贸n.
En este patr贸n, definimos procedimientos de despliegue reutilizables que puedan ser utilizados en todos los proyectos. Hay una soluci贸n muy elegante en las metodolog铆as 脕giles para esto, en la que las actividades de implementaci贸n se convierten en una historia de usuario. Por ejemplo, podr铆amos construir una historia de usuario reutilizable para Operaciones llamada 'Implementaci贸n en un entorno de alta disponibilidad', la cual definir铆a los pasos exactos para construir el entorno, as铆 como cu谩nto tiempo lleva, qu茅 recursos se necesitan, etc.
Esta informaci贸n puede, entonces, ser usada por los directores de proyecto para integrar detalladamente las actividades de implementaci贸n en el plan de proyecto. Por ejemplo, podr铆amos tener mucha confianza en el horario de implementaci贸n si supi茅ramos que la historia “Implementaci贸n en un entorno de alta disponibilidad” ha sido ejecutada en quince ocasiones en el 煤ltimo a帽o, llevando una media de tres d铆as, con un margen de error de un d铆a.
Adem谩s, tambi茅n ganamos confianza en que las actividades de implementaci贸n est谩n siendo debidamente integradas en cada proyecto de software.
Al reconocer que ciertos proyectos de software requieren entornos 煤nicos que Operaciones no soporta oficialmente, podemos permitir excepciones en las que esos entornos est谩n permitidos en producci贸n, pero que sean soportados por alguien fuera de Operaciones, es decir, entornos no soportados.
Al hacer esto, tenemos los beneficios de la estandarizaci贸n de los entornos (por ejemplo, variedad de producci贸n reducida, menores diferencias en producci贸n, aumento de capacidad de Operaciones de TI para soporte y mantenimiento confiable, etc.), mientras que permitimos los casos especiales que permiten la agilidad que a veces el negocio requiere.