Distribución e implementación de aplicaciones para dummies

Eric Minick, Jeffrey Rezabek,
y Claudia Ring
Distribucióneimplementación
deaplicaciones
Edición Limitada IBM

Distribución e implementación de aplicaciones para Dummies®
, Edición Limitada IBM
Publicado por
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030-5774
www.wiley.com
Copyright © 2014 John Wiley & Sons, Inc., Hoboken, New Jersey
Ninguna parte de esta publicación puede reproducirse, almacenarse en un sistema de recuperación
ni transmitirse de ninguna manera ni por ningún otro medio, electrónico, mecánico, por fotocopia,
por grabación, por escaneado o por ningún otro modo, excepto según lo permitido en las Secciones
107 o 108 de la Ley de propiedad de intelectual de los Estados de Unidos de 1976, sin la previa
autorización por escrito de la editorial. Las solicitudes de permiso a la editorial deberán dirigirse al
Departamento de permisos, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-
6011, fax (201) 748-6008, o por Internet http://www.wiley.com/go/permissions.
Marcas comerciales: Wiley, Para Dummies, el logo de Dummies Man, The Dummies Way, Dummies.
com, Making Everything Easier y la imagen de marca relacionada son marcas comerciales o marcas
comerciales registradas de John Wiley & Sons, Inc. y/o sus filiales en los Estados Unidos y en otros
países, y no pueden utilizarse sin una autorización por escrito. IBM y el logotipo de IBM son marcas
registradas de IBM. Todas las restantes marcas comerciales son propiedad de sus respectivos
titulares. John Wiley & Sons, Inc. no tiene relación con ningún producto o fabricante mencionado en
este libro.
LÍMITE DE RESPONSABILIDAD/EXENCIÓN DE GARANTÍA: LA EDITORIAL Y EL AUTOR NO
ASUMEN RESPONSABILIDAD ALGUNA NI OFRECEN GARANTÍAS CON RESPECTO A LA PRE-
CISIÓN O INTEGRIDAD DEL CONTENIDO DE ESTA OBRA Y NO OFRECEN ESPECÍFICAMENTE
NINGUNA GARANTÍA, INCLUYENDO A TÍTULO ENUNCIATIVO, PERO NO LIMITATIVO,
GARANTÍAS DE IDONEIDAD PARA UN FIN DETERMINADO. NO SE CREARÁ NI SE AMPLIARÁ
NINGUNA GARANTÍA MEDIANTE MATERIALES PROMOCIONALES O DE VENTAS. EL ASESORA-
MIENTO Y LAS ESTRATEGIAS CONTENIDOS EN ESTA PUBLICACIÓN PUEDEN NO SER ADECUA-
DOS PARA TODAS LAS SITUACIONES. ESTA OBRA SE VENDE ENTENDIÉNDOSE QUE LA
EDITORIAL NO OFRECE SERVICIOS LEGALES, CONTABLES U OTROS SERVICIOS PROFESION-
ALES. SI PRECISA ASISTENCIA PROFESIONAL, RECURRA A LOS SERVICIOS DE UN PROFE-
SIONAL COMPETENTE. NI LA EDITORIAL NI EL AUTOR SE RESPONSABILIZAN DE LOS DAÑOS
COMO CONSECUENCIA DE ESTA PUBLICACIÓN. EL HECHO DE QUE EN ESTA OBRA SE HAGA
REFERENCIA A UNA ORGANIZACIÓN O SITIO WEB, A MODO DE CITA O COMO POSIBLE FUENTE
DE INFORMACIÓN, NO SIGNIFICA QUE EL AUTOR NI LA EDITORIAL APRUEBEN LA INFOR-
MACIÓN QUE DICHA ORGANIZACIÓN O SITIO WEB PUEDAN PROPORCIONAR NI SUS RECO-
MENDACIONES. ASIMISMO, LOS LECTORES DEBEN SER CONSCIENTES DE QUE LOS SITIOS WEB
INDICADOS EN ESTA OBRA PUEDEN HABER CAMBIADO O DESAPARECIDO ENTRE EL
MOMENTO EN QUE SE REDACTÓ LA OBRA Y EL MOMENTO EN QUE SE LEE.
Para obtener información general sobre nuestros otros productos o servicios o sobre cómo crear un
libro Para Dummies personalizado para su empresa u organización, póngase en contacto con
nuestro Departamento de Desarrollo Comercial en EE.UU. llamando al 877-409-4177, por correo elec-
trónico a info@dummies.biz, o visitando www.wiley.com/go/custompub. Para obtener infor-
mación sobre licencias de la marca Para Dummies para productos o servicios, póngase en contacto
con BrandedRights&Licenses@Wiley.com.
ISBN: 978-1-119-18615-1 (publicación); ISBN: 978-1-119-18616-8 (ebook)
Fabricado en Estados Unidos de América
10 9 8 7 6 5 4 3 2 1

Índice
Introducción...............................................................1
Acerca de este libro ...............................................................................1
Iconos utilizados en este libro.............................................................2
Más allá de este libro.............................................................................2
Capítulo1:¿Quécontribuyealaeficacia
deladistribucióneimplementación?..................5
Seguir el ciclo de vida del desarrollo de software (CVDS)............5
Cosechar los beneficios de la entrega eficiente del software.......7
Mayor velocidad en la llegada al mercado ...........................8
Disminuir fallos costosos .........................................................8
Escalar las distribuciones e implementaciones
de gran complejidad..............................................................9
Identificar las prácticas de entrega del software ..........................11
Agile.............................................................................................11
Integración continua................................................................11
Entrega continua.......................................................................12
ITIL...............................................................................................13
Adoptar un enfoque DevOps para la entrega de software..........13
Capítulo2:Aplicar el proceso
deimplementaciónmodelo...........................15
Los tres pilares de la implementación modelo..............................15
Utilizar el mismo proceso.......................................................16
Automatizar ...............................................................................17
Realizar cambios incrementales ...........................................18
Efectos positivos de la implementación modelo ..........................18
Automatizar y utilizar el mismo proceso
de implementación ..............................................................18
Realizar implementaciones incrementales.........................19
Gestionar los defectos.............................................................19
Capítulo3:Elegir solucionesparaladistribución
eimplementacióndeaplicaciones....................21
Prepárese para los cambios ..............................................................21
Cambios de roles ......................................................................22
Cambios en procesos y soluciones ......................................23
Evaluar soluciones de distribución e implementación ...............23
Evaluar soluciones de coordinación de distribuciones ..............25

DistribucióneimplementacióndeaplicacionesparaDummies
iv
Capítulo 4: Poner lasoluciónenmarcha ................27
Poner en funcionamiento una solución de automatización
de la implementación de aplicaciones........................................27
Escoger el mejor momento para la implementación........28
Crear un entorno similar al de producción ........................29
Practicar implementaciones similares a producción.......30
Diseñar en primer lugar para producción ..........................30
Poner en funcionamiento una solución para coordinación
de distribuciones .............................................................................31
Identificar un modelo realista de distribuciones...............32
Escoger una ruta de implementación ..................................32
Capítulo 5: Diezmitossobreladistribución
eimplementacióndeaplicaciones....................35
Automatizar la implementación significa crear scripts...............35
Los equipos de desarrollo crean los mejores
procesos de implementación........................................................36
Es posible gestionar fácilmente distribuciones complejas
sin soluciones especializadas .......................................................36
Entrega continua significa constantes distribuciones
a producción.....................................................................................37
La automatización reduce la calidad y el control.........................37
Una hoja de cálculo es una buena herramienta de gestión
de distribuciones .............................................................................38
Una distribución grande es menos arriesgada
que varias pequeñas .......................................................................38
La automatización es independiente del proceso
de compilación.................................................................................39
Un backlog de materiales implementables no indica
un problema de DevOps ...............................................................40
Las soluciones de coordinación de distribuciones
resuelven todos los problemas ...................................................40
iv

Agradecimientos de la editorial
Estamos orgullosos de este libro y de las personas que trabajaron en él.
Para obtener información sobre cómo crear un libro Para Dummies
personalizado para su empresa u organización, póngase en contacto con
info@dummies.biz o visite www.wiley.com/go/custompub.
Para obtener información sobre licencias de la marca Para Dummies
para productos o servicios, póngase en contacto con
BrandedRights&Licenses@Wiley.com.
Algunas de las personas que contribuyeron a poner este libro en el mer-
cado son:
Adqu isiciones, editoria l y sitios web
ver tica lesAcqu isitions, Editoria l, a nd
Ver tica l Websites
Editora del proyecto: Carrie A.
Burchfield
Editora de adquisiciones: Connie
Santisteban
Director editorial: Rev Mengle
Especialista en desar rollo empresarial:
Sue Blessing
Especialista en proyectos editoriales
personalizados: Michael Sullivan
Ser vicios editoriales para Technology Dummies
Richard Swadley, Vicepresidente y editor ejecutivo del Grupo
Andy Cummings, Vicepresidente y editor
Mar y C. Corder, Directora editorial
Edición de Consumer Dummies
Kathleen Nebenhaus, Vicepresidenta y editora ejecutiva
Ser vicios de composición
Debbie Stailey, Directora de servicios de composición
Desar rollo empresarial
Lisa Coleman, Directora de nuevos mercados y desarrollo de marca

Introducción
Las aplicaciones software son importantes impulsores de benefi-
cios para las empresas, y la distribución e implantación puntual
de las aplicaciones se ha convertido en un elemento crítico del ciclo
de vida comercial. Porque, ¿de qué sirve crear una aplicación inno-
vadora si no es posible implantarla eficientemente en entornos de
prueba o distribuirla a los usuarios en la fecha prevista?
Tradicionalmente implantación se define como el paso de compo-
nentes de un entorno al siguiente. Distribución abarca la implanta-
ción a producción de una aplicación totalmente nueva o múltiples
aplicaciones integradas. Distribución e implantación son cosas
distintas pero comparten el mismo objetivo: ofrecer aplicaciones de
calidad.
Distribución e implantación tiene objetivos similares, por lo que
ambos términos se usan en ocasiones de forma intercambiable. A
efectos de este libro, nos referiremos a la distribución e implanta-
ción de una aplicación se ha definido en el párrafo anterior, y distin-
guiremos entre ambos cuando se precise.
Alo largo de este libro le ofreceremos información sobre las dife-
rencias entre distribución e implantación de aplicaciones. También
le indicaremos cómo aprovechar las soluciones de distribución e
implantación para ayudar a su organización a reducir el tiempo de
llegada al mercado y reducir costes y riesgos.
Acerca deestelibro
El propósito de este libro es ofrecer una introducción relativamente
simple a un tema que puede llegar a ser muy complejo. Pretende
ser una referencia, no un manual. Si le interesa algún tema pero no
otros, no dude en leer solo los capítulos relevantes. También puede
saltar libremente de una sección a otra. No es necesario leer los
capítulos en orden.

2
Iconosutilizadosen estelibro
Encontrará los siguientes iconos en los márgenes del libro:
El icono Consejo destaca información útil.
El icono Recuerde destaca cosas que deberá tener en mente.
Las secciones marcadas como Información técnica no son necesa-
rias salvo que desee obtener información en profundidad sobre el
tema.
Asegúrese de leer todo lo marcado con el icono Advertencia, que
destaca posibles riesgos.
Másallá deestelibro
En el libro le hablamos sobre los beneficios de las soluciones de
implantación de aplicaciones, automatización y coordinación de
distribuciones. Incluimos algunos casos prácticos con resultados
satisfactorios y mejores prácticas.
También encontrará más información sobre distribución e implanta-
ción de aplicaciones visitando las siguientes páginas web.
✓ Soluciones DevOps de IBM para distribución e implantación
de aplicaciones: http://ibm.co/devopsRaD
✓ IBM UrbanCode Deploy -página del producto:
http://ibm.co/UCDeploy
✓ IBM UrbanCode Release -página del producto:
http://ibm.co/UCRelease
✓ 7 prácticas demostradas para reforzar la gestión de distribu-
ciones: http://ibm.co/7ProvenPractices
✓ Los ABC de la distribución e implantación continuas en un
enfoque DevOps: http://ibm.co/ABCsRaD

Introducción
3
Por último, también puede leer estos otros títulos Para Dummies
Edición Limitada IBM:
✓ DevOps pa ra Dummies: ibm.co/devopsfordummies
✓ Agile pa ra Dummies: ibm.co/agilefordummies
✓ Virtua liza ción de servicios pa ra Dummies:
ibm.co/servicevirtualization

4

Capítulo1
¿Quécontribuyeala
eficaciadeladistribución
eimplementación?
En estecapítulo
▶ Hacer seguimiento del ciclo de vida del desarrollo de software
▶ Comprender los beneficios empresariales de la entrega eficaz del software
▶ Comprender las prácticas técnicas que hacen posible el desarrollo de apli-
caciones
Una aplicación hace un largo recorrido hasta que es ofrecida a
los usuarios en producción. Este recorrido se denomina ciclo
de vida de desarrollo del software (CVDS). En este capítulo le mos-
traremos los elementos de este ciclo. Acontinuación hablaremos
sobre los principales aspectos empresariales y técnicos de la distri-
bución e implementación del software.
Seguir el ciclodevida del
desarrollodesoftware( CVDS)
El CVDS puede incorporar todos los aspectos de la vida de una
aplicación, desde la planificación inicial hasta su retirada. En esta
sección trataremos sobre una importante parte del CVDS que
llamaremos proceso de entrega, y que está formada por múltiples
entornos: objetivos de desarrollo para un conjunto de elementos que
funcionan conjuntamente por alcanzar una meta común. Los entor-
nos se apoyan entre sí para aumentar la calidad de una aplicación
antes de que llegue al usuario al que está destinada. No es necesario

6
que las aplicaciones pasen por un número establecido de elemen-
tos, pero hemos advertido cuatro entornos bastante típicos:
✓ Desarrollo (DEV): En el entorno de Desarrollo, los desarro-
lladores crean e implementan código en un laboratorio de
pruebas y el equipo de desarrollo comprueba la aplicación al
nivel más básico. Cuando la aplicación satisface determinados
criterios, avanza al entorno siguiente.
✓ Prueba de integración del sistema (PIS): En el entorno de
Prueba de integración del sistema, se comprueba la capacidad
de la aplicación para funcionar con las aplicaciones y sistemas
existentes. Cuando la aplicación satisface los criterios de este
entorno, se implementa en el siguiente.
✓ Prueba de aceptación por los usuarios (PAU): En el entorno
de Prueba de aceptación por los usuarios, se comprueba que la
aplicación offrezca las características que precisan los usua-
rios finales. Este entorno suele ser similar al de producción
(ver Capítulo 3). Cuando la aplicación supera estos requisitos,
pasa al entorno final.
✓ Producción (PROD): En el entorno de Producción, la aplicación
queda a disposición de los usuarios. Se recoge el feedback
(ver barra lateral) mediante monitorización de la disponibili-
dad y funcionalidad de la aplicación. Se introducen actualiza-
ciones o parches en el entorno DEV, que siguen el mismo ciclo.
La figura 1-1 muestra un sencillo diagrama de estos cuatro entornos.
Development DEV SIT UAT PROD End user
Figura1-1:Loscuatroentornosbásicosdel CVDS.
Se define implementación como el paso de los componentes de un
entorno al siguiente. Distribución es la implementación de una apli-
cación completa o de múltiples aplicaciones integradas a produc-
ción. La imagen de la figura 1-2 ayuda a ilustrar la diferencia un poco
mejor.

Capítulo1:Laeficaciadeladistribucióneimplementación
7
Development DEV SIT UAT PROD
RELEASE
DEPLOYMENTS
Figura1-2:Visualizacióndeladiferenciaentreunadistribuciónyuna
implementación.
Ejecutar unbucledefeedback
Algunasprácticasdeentregade
softwareimplicanlamonitorización
delaaplicaciónentodoslosentor-
nosyhacer llegar el feedbackal
equipodedesarrollo.Basándoseen
losnuevosrequisitos,el equipode
desarrolloimplementalaaplicación
modificadaal entornoDEVyel ciclo
comienzadenuevo.Trasel pasoa
cadaentornoensucesión,semoni-
torizalaaplicaciónysehacellegar
el feedbackal equipodedesarrollo.
Esteprocesosedenominabucle
defeedback.
Cosechar losbeneficiosdela
entrega eficientedel software
La necesidad de proporcionar software que se adapte y responda a
las expectativas de la empresa y de los clientes impulsa la necesidad
de unas mejores prácticas de distribución e implementación de apli-
caciones. El IBM Institute of Business Value indica que el número de
organizaciones que valoran la efectividad en la entrega del software
es muy superior al número de organizaciones que realmente propor-
cionan una entrega eficiente del software. Encontrará más informa-
ción en la figura Figure 1-3.
En las siguientes secciones consideramos algunos de los beneficios
empresariales de la entrega eficiente del software.

8
Mayor velocidadenlallegadaal mercado
El tiempo que los clientes están dispuestos a esperar por un servicio
que desean es cada vez más reducido. Los clientes esperan una gra-
tificación instantánea. Piense con qué frecuencia sus aplicaciones
móviles precisan actualizaciones requeridas por los clientes. Si un
servicio no está disponible en el momento exacto en que un cliente
lo desea, este cliente está a un solo clic de pasarse a la página de
una empresa competidora.
Con unos métodos adecuados de distribución e implementación
de aplicaciones, tanto las nuevas empresas como las ya estableci-
das pueden ofrecer rápidamente los servicios que demandan los
clientes. La entrega efectiva del software es clave para el éxito de su
empresa, por lo que proporcionar a sus equipos de distribución e
implementación las personas, procesos y herramientas adecuados
puede suponer la diferencia entre el éxito y el fracaso a largo plazo.
Disminuir falloscostosos
El coste de un fallo en el software depende del entorno en el que se
produzca el fallo. Por norma general, los fallos detectados en los
entornos tempranos, como DEVo SIT (consulte la anterior figura
1-1 en este capítulo), son mucho menos costosos que los detec-
tados en producción. Detectar un error en la aplicación en estos
entornos le permite implementar una corrección que puede evitar
una disrupción crítica en la producción, o, peor aún, un fallo crítico
para los usuarios. Forbes.com destacó que en el verano de 2013,
Amazon experimentó una interrupción del servicio durante 30 minu-
tos que tuvo como resultado unas pérdidas estimadas en 66.240
86%
leverage software delivery
e ectively today
of those who
leverage software
delivery e ectively
today outperform
their competitors
of companiesbelieve software
delivery isimportant or critical
69%
25%
86%
But only
25%
Figura1-3:El valor delaentregaeficientedel software.

9
$ por minuto, o un total de casi 2 millones de dólares de ingresos
totales perdidos.
El coste de un fallo es un claro aliciente para mejorar las prácticas
de distribución e implementación de las aplicaciones. En capítulos
posteriores examinaremos distintas formas de evitar estos fallos.
Escalar lasdistribucioneseimple-
mentacionesdegran complejidad
Las organizaciones tienden a tener cada vez más objetivos de imple-
mentación en distintos dispositivos, locales, cloud, y máquinas
físicas y virtuales. Escalar un proyecto en gran medida manual a un
sistema eficiente y a nivel de empresa de distribuciones de aplica-
ciones interdependientes y mantener a la vez los requisitos de segu-
ridad, trazabilidad y visibilidad puede resultar muy complicado.
El número de pasos manuales que puede conllevar la distribución
de una sola aplicación puede constituir un laborioso proceso, pero
la aplicación termina inevitablemente en producción. Con distribu-
ciones más grandes y complejas aumenta el riesgo con el número de
aplicaciones interdependientes distribuidas. Los procesos manuales
combinados con soluciones primitivas de seguimiento, (hojas de
Estimar el costedelosfallos
Unfallopuedeprovocar pérdidade
ingresos,perosolucionarlotambién
puedesuponer uncosteparasu
organización.Podemoscomenzar a
estimar el costedeunfalloenladistri-
bucióndeunaaplicacióncalculando
el costepor horadeuningenierores-
ponsabledecorregir el problema.Una
estimaciónaproximadadeloscostes
adicionalesesdeentreel 20yel 40
por cientodel sueldo.Lafórmulaes:
Salarioanual estimado/ 52semanas
al año/ 40horassemanales* 1,3
Si uningenierocobra,por ejemplo
80.000$,unaestimaciónrazonable
del costetotal por horaes
80.000/ 52/ 40* 1,3=50$
Utiliceestafórmulaparacadamiem-
brodel equipoderecuperacióny
multipliqueel resultadopor el prome-
diodehorasdedicadasaacciones
correctivas.Si,por ejemplo,unequipo
pasadiezhorassolucionandounpro-
blemaenunadistribución,el costees
de3.000$paraestadistribución.Sin
embargo,estecostesoloserefierea
productividad;noincluyeel costede
oportunidad:lapérdidadeingresos
olaintangiblepérdidapotencial de
credibilidadacausadel fallo.

10
cálculo) son propensos a errores humanos e, inevitablemente, a
costosos fallos.
Amedida que aumenta la complejidad de las aplicaciones, los equi-
pos de distribución pueden alcanzar docenas o cientos de personas,
lo que añade un nivel de complejidad adicional. Cuando los equipos
de IT crecen para gestionar la complejidad de las aplicaciones,
aumenta el aislamiento entre las responsabilidades y especialidades
de cada tarea; la comunicación se hace menos frecuente mientras
los equipos llevan a cabo sus respectivos procesos. Esta falta de
comunicación se debe a la especialización de las tareas y a las dife-
rencias horarias y de ubicación geográfica. Los equipos distribuidos
que utilizan distintas soluciones y procesos suelen descubrir que
estas diferencias multiplican el esfuerzo por dos o tres y hace impo-
sible cumplir los plazos.
La coordinación de cada implementación, cada proceso y cada con-
junto asociado de pasos manuales resulta prácticamente imposible
de ejecutar sin una herramienta especializada. El uso de una herra-
mienta especializada puede ayudarle a coordinar cada implementa-
ción, cada proceso y cada conjunto de pasos y hacerlos visibles a
todos los implicados en la distribución o implementación.
Si la implementación de un elemento a un servidor consta de diez
pasos y se aumenta de uno a diez servidores, pasamos de diez
pasos manuales a 100. Por tanto, si pasamos de un elemento de
implementación a diez elementos, multiplicamos de nuevo por
diez, alcanzando el número de 1000 pasos manuales. Los procesos
manuales no pueden crecer si estos tres niveles de complejidad
(número de elementos implementados, número de servidores y
número de pasos en cada implementación) generan un crecimiento
exponencial.
Las organizaciones que puedan establecer un proceso eficiente de
distribución e implementación serán capaces de mantener el ritmo
del desarrollo y podrán distribuir a la vez lotes más pequeños de
aplicaciones, o incluso o versiones únicas o cambios únicos. La efi-
ciencia reduce el riesgo y permite a las organizaciones centrarse en
la satisfacción oportuna de las necesidades empresariales en lugar
de los procesos

11
Identificar lasprácticasdeentrega
del software
Hay distintas prácticas y metodologías de entrega de software
que permiten a las organizaciones acortar el tiempo de llegada al
mercado, reducir errores y escalar el trabajo a nivel empresarial.
Muchas organizaciones utilizan un enfoque combinado. Algunas
de las prácticas más extendidas son Agile, Integración continua,
Entrega continua e ITIL, que trataremos en las siguientes secciones.
Agile, Integración continua y Entrega continua se apoyan entre sí y
contribuyen a llevar las aplicaciones a producción.
Agile
Los rápidos avances tecnológicos han hecho que los clientes tengan
menos paciencia y sean más exigentes. La adopción de las prácticas
Agile es consecuencia de la acelerada velocidad para realizar los
cambios necesarios para mantener la competitividad en el mercado.
Agile da énfasis a las necesidades del cliente, a las distribuciones
pequeñas y frecuentes, a la adopción del cambio y a la colabora-
ción entre los miembros del equipo de desarrollo. Adiferencia del
método tradicional de desarrollo de software en cascada, Agile resta
importancia a la planificación exhaustiva, por lo que los desarrolla-
dores no se ven atrapados en planes imposibles de cambiar. Agile se
centra en unos entregables más pequeños que permitan a los desa-
rrolladores hacer cambio a medida que surja la necesidad.
Encontrará más información en Agile para Dummies, Edición
Limitada IBM, en ibm.co/agilefordummies.
Integración continua
La integración continua (IC) surgió del principio Agile de implemen-
tar de forma regular código y comprobar las compilaciones para
validar los cambios integrados. Mediante la IC, los desarrolladores
se comprometen de forma regular con una línea de código común e
integran sus cambios con los de otros miembros del equipo y con el
código existente. Al compartir rápidamente el código, evitan los pro-
blemas de integración tardía de los sistemas en cascada y localizan
los problemas más rápidamente. Los desarrolladores deberán alcan-
zar un compromiso cada vez que se completa un pequeño bloque
de código, generalmente al menos una vez al día.

12
La IC es posible mediante el uso de una solución que compile
automáticamente los cambios recién integrados a medida que se
reciben. Es frecuente que una verificación automática acompañe a
la compilación automática, de modo que los defectos se descubran
y aborden con mayor rapidez. Esta característica es especialmente
potente si se combina con la Entrega continua, que presentamos en
la siguiente sección.
En combinación con las prácticas de desarrollo Agile, IC es un paso
más hacia las distribuciones de elevada velocidad y elevada calidad.
Permite a los equipos de desarrollo producir a muy elevada velo-
cidad compilaciones que es posible someter a pruebas. También
ejerce mayor presión sobre los equipos de operaciones para imple-
mentar con mayor frecuencia a los entornos posteriores.
Entrega continua
La Entrega continua (EC) es la siguiente mejora de IC, e implementa
automáticamente compilaciones satisfactorias que han llegado a
los entornos de prueba, dando lugar a pruebas automatizadas. Los
equipos que implementan EC tratan de comprobar siempre cada
compilación, lo que permite a la empresa distribuir nuevas caracte-
rísticas en cualquier momento con total confianza.
EC toma su nombre del Manifiesto Agile, y se creó en respuesta al
cuello de botella que evidenciaron las prácticas Agile y de IC para
los equipos de operaciones. Amedida que los equipos de desarrollo
comenzaban a avanzar con rapidez y producir un elevado volumen
de compilaciones, los equipos de operaciones sufrían la presión
de una acumulación de tareas atrasadas que era preciso llevar a
producción. Las diferencias en lenguajes, plataformas y pruebas
también contribuyeron a asfixiar a los equipos de operaciones, que
buscaban formas de garantizar una distribución satisfactoria de las
aplicaciones.
El que un profesional de IT diga que está haciendo EC no significa
necesariamente que esté implementando directamente hasta
producción. Es posible que haya implementado prácticas de EC,
pero posiblemente se encuentre obstáculos, físicos o técnicos, que
impidan completar la tarea en otros puntos del CVDS. Estos obstá-
culos contribuyen a aumentar los riesgos de forma exponencial, al
acumularse más cambios en lotes cada vez mayores, que están a la
espera de ser implementados a la vez. La forma ideal de EC utiliza
la automatización para llevar una aplicación hasta producción, pero

13
hay que superar importantes obstáculos hasta poder alcanzar los
beneficios en toda la empresa. En el capítulo 2 examinaremos estos
obstáculos.
ITIL
La Librería de infraestructuras para tecnologías de la información
(ITIL) es un conjunto de mejores prácticas y procesos que contri-
buyen a la administración de los servicios de IT. ITILse compone
de cinco grandes ciclos de vida que asesoran a los profesionales
sobre las mejores prácticas para ofrecer servicios específicos a los
usuarios.
Los conceptos de ITILofrecen unas prácticas no dependientes de
ningún proveedor y no preceptivas que pueden utilizarse en cual-
quier sector. La mayoría de las organizaciones que practican ITILlo
hacen porque precisan un sistema de gobernanza, gestión de ries-
gos y control de las distribuciones e implementaciones.
Algunas de las empresas que utilizan ITILson reacias a la automa-
tización porque consideran que aumentar la velocidad supone un
mayor riesgo de cometer errores. En realidad, la automatización
puede reducir los errores y aumentar el control, la visibilidad y la
auditabilidad.
Adoptar un enfoqueDevOpspara
la entrega desoftware
DevOps es un sistema de entrega continua de software que permite
a los clientes aprovechar las oportunidades del mercado y reducir
el tiempo necesario para obtener feedback de los clientes. DevOps
aplica principios Agile y Lean en toda la cadena de suministro del
software para eliminar desperdicios y cuellos de botella. DevOps se
compone de cuatro grandes capacidades en el CVDS:
✓ Planificar se centra en las líneas de negocio y sus procesos de
planificación. Significa comprender y aumentar la eficacia de
las medidas de estos procesos y la cartera de aplicaciones que
abarcan.
✓ Desarrollar/comprobar se centra en el desarrollo colabora-
tivo, la IC y la comprobación continua. Se centra en optimizar
las capacidades de los equipos de desarrollo y pruebas.

14
✓ Implementar permite crear el proceso de implementación para
la distribución e implementación continuas.
✓ Operar incluye la práctica de la monitorización continua, fee-
dback de los clientes y optimización para monitorizar el rendi-
miento de las aplicaciones después de la distribución, lo que
permite a las empresas adaptar sus requisitos según convenga.
Para obtener más información sobre DevOps, consulte DevOps para
Dummies en ibm.co/devopsfordummies.
Implementar soluciones de coordinación de distribuciones y
automatización de la implementación son la clave para solucionar
problemas de DevOps en su organización, como veremos en los
capítulos 3 y 4.

Capítulo2
Aplicarel procesode
implementaciónmodelo
En este capítulo
▶ Reconocer los tres pilares de un proceso de implementación modelo
▶ Observar los efectos de un proceso de implementación modelo
En este capítulo nos centramos en abordar los factores empresa-
riales y tecnológicos (ver Capítulo 1) mediante la aplicación de
un proceso de implementación modelo. Al final de capítulo veremos
cómo aplicar un proceso de implementación modelo puede tener un
efecto positivo en una distribución.
Lostrespilaresdela
implementación modelo
Para garantizar el éxito de una distribución de una aplicación,
comience por utilizar los tres pilares del proceso de implementación
modelo:
✓ Utilizar el mismo proceso.
✓ Automatizar.
✓ Realizar cambios incrementales.
En las siguientes secciones trataremos en detalle cada uno de estos
pilares.

16
Utilizar el mismoproceso
Uno de los principales problemas para escalar implementaciones de
una aplicación a volúmenes mayores y mayor complejidad es que
los equipos de especialistas trabajan aislados y crean procesos a
medida adecuados para sus propias responsabilidades.
Las necesidades de implementación varían entre los equipos
✓ Los desarrolladores quieren realizar la implementación y
pruebas rápidamente para implementar más cambios en la
aplicación. Es habitual que creen atajos en el proceso de imple-
mentación mediante scripts o que eliminen pasos aparente-
mente innecesarios pero que pueden ser importantes para el
rendimiento de la aplicación en producción.
✓ Los equipos de pruebas tratan de imitar el ritmo de los equi-
pos de desarrollo, pero comprenden la necesidad de dedicar
el tiempo necesario para hacer pruebas tanto del proceso de
implementación como de las aplicaciones. Con frecuencia,
estos equipos crean sus propios procesos de implementación
para acelerar las pruebas y evitar retrasos.
✓ Los equipos de operaciones toleran un ritmo más lento.
Son responsables de mantener los sistemas críticos para la
empresa en funcionamiento, por lo que no pueden admitir los
riesgos que conlleva una implementación rápida. Su proceso
de implementación está diseñado para mantener el entorno de
producción funcionando sin sobresaltos.
Cuando los procesos de implementación difieren entre los equipos
y entornos de destino, aumenta la posibilidad de que se produzcan
errores. Los pasos no documentados, las diferencias en los entornos
y la falta de aportaciones de todos los equipos hacen aumentar las
posibilidades de fallos en la implementación.
Para reducir el riesgo que conlleva el uso de distintos procesos de
implementación, utilice el mismo proceso de implementación al
pasar de un entorno a otro durante todo el ciclo de vida del desarro-
llo de software (CVDS) y durante el proceso de entrega continua a
producción.
Cuando utilice el mismo proceso de implementación durante todo el
CVDS, puede comprobar el proceso de la aplicación y el de la imple-
mentación.
El método preferente para estandarizar el proceso de implementa-
ción es comenzar el diseño por la producción e ir retrocediendo.

Capítulo 2: Aplicar el proceso de implementación modelo
17
Aunque esta práctica precise inicialmente más reflexión, tiempo y
esfuerzo, si diseña en primer lugar el proceso de paso a producción,
puede eliminar los pasos innecesarios al retroceder a entornos ante-
riores. En el capítulo 4 trataremos este tema más en detalle.
Automatizar
Los pasos manuales o realizados en parte mediante scripts en un
proceso de implementación aumentan el riesgo de fallos. Incluso los
operarios más experimentados pueden cometer equivocaciones, y
el error es más probable cuando un humano realiza una larga lista
de pasos manuales. Un proceso de implementación (automatizado
o manual) deberá incluir compuertas o aprobaciones predefinidas
que el equipo deberá realizar o satisfacer para que la implementa-
ción pase al estadio siguiente. Sin embargo, automatizar el proceso
de implementación le ayuda a escalar el proyecto, llegar antes al
mercado y reducir los riesgos.
Al automatizar todos los elementos posibles del proceso de
implementación, usted puede añadir conformidad y auditabilidad
mediante mayor visibilidad sobre:
✓ Qué componentes se incluyen en la implementación
✓ Quién ha implementado qué aplicación
✓ Dónde se ha implementado la aplicación
✓ Qué versión de la aplicación se ha implementado
✓ Cuándo se implementó la aplicación
La trazabilidad y la visibilidad son dos elementos clave en el pro-
ceso de distribución e implementación, y usted puede conseguirlos
con una adecuada automatización, según veremos en el capítulo 4.
Hay una diferencia entre automatizar y escribir una serie de scripts
para que los ponga en marcha un experto. La auténtica automatiza-
ción elimina los riesgos de cambiar piezas y permite a las personas
autorizadas poner en marcha una implementación con solo pulsar
un botón. Además, la verdadera automatización ofrece capacidad de
implementación mediante autoservicio, visibilidad y trazabilidad.
La automatización de la implementación es un factor de tal impor-
tancia para el éxito de la implementación de aplicaciones que
cuando en este libro mencionamos implementación de aplicaciones,
nos referimos a la implementación de aplicaciones mediante auto-
matización.

18
Realizar cambiosincrementales
El último pilar de un proceso de implementación modelo es realizar
cambios incrementales a la aplicación. Lo ideal es que su solución
de automatización implemente solo los componentes que sea pre-
ciso cambiar y deje el resto intacto, ya que volver a reimplementar
componentes sin cambios conlleva riesgos. implementar solo lo que
se ha cambiado significa poder implementar con más frecuencia y
bajo demanda. Cuando se comprenden los cambios de la aplicación,
se tiene una visión auténtica de las versiones y de qué, cuándo,
dónde se ha cambiado y quién lo ha hecho. Es posible implementar
con más frecuencia y bajo demanda cuando se automatizan las
tareas más repetitivas, y se establece una aprobación acordada y
unas barreras de calidad (criterios que debe satisfacer una aplica-
ción antes de pasar a entornos posteriores). Si utiliza el mismo pro-
ceso para todas las implementaciones, realizar pequeños cambios
en la aplicación será posible y deseable. Los cambios más pequeños
deberán superar fácilmente los entornos de prueba hasta llegar a
producción.
Cuando realice cambios incrementales es posible que no utilice el
proceso completo de implementación. Para realizar cambios incre-
mentales, configure el proceso de implementación modelo y utilice
solo la parte del proceso que realmente se precisa para implementar
cambios incrementales.
Efectospositivosdela
implementación modelo
Utilizar los tres pilares del proceso de implementación modelo (ver
sección anterior) puede ayudarle a comenzar a poner en línea las
necesidades de negocio y las técnicas, lo que podrá tener un efecto
positivo en la distribución de la aplicación. Esta sección cubre algu-
nos de estos efectos.
Automatizar y utilizar el mismo
procesodeimplementación
Al utilizar el mismo proceso automatizado de implementación en
múltiples ciclos de vida de la aplicación, está influyendo de forma
notable en la distribución en conjunto. Esta distribución es menos
propensa a contener errores y tarda mucho menos en realizarse.

Capítulo 2: Aplicar el proceso de implementación modelo
19
Realizar implementacionesincrementales
Realizar una implementación grande es arriesgado, pero aún más
peligroso es implementar una gran distribución de varias aplicacio-
nes. implementar pequeños lotes de cambios es menos arriesgado y
más fácil de gestionar.
Además, gestionar defectos en una distribución pequeña y corregir-
los de forma efectiva es mucho más fácil en pequeños lotes (ver la
sección siguiente).
Para distribuir e implementar bajo demanda es preciso disponer de
un proceso optimizado. Por este motivo, mejorar continuamente su
proceso estándar de implementación y automatizar las tareas más
propensas a errores es la clave para llevar a cabo con éxito imple-
mentaciones incrementales y distribuciones sin sobresaltos.
Gestionar losdefectos
Las distribuciones pequeñas son menos arriesgadas que las grandes
porque disminuyen el número de posibles defectos que pueden
provocar un error o una interrupción de la actividad. Hay tres ele-
mentos que contribuyen a la aparición de defectos: el código, la
configuración y la complejidad. Por complejidad nos referimos aquí
al número de interdependencias o relaciones en el paquete de la
distribución.
Evitar el efectodel lunespor lamañana
El efectodel lunespor lamañanase
produceel lunesdespuésdel finde
semanaenel queseharealizadouna
distribuciónimportante,cuandoladis-
tribuciónaúnhadesuperar distintos
problemas,comopuedeser unainte-
rrupciónenproducciónodefectosen
laaplicación.El equipodedistribución
hadeemprender accionescorrecti-
vasheroicaseinmediatas.Reiniciar la
distribución,corregir el error oerrores
yeliminar otrasposibilidadessintener
quesuspender laactividadduranteun
tiempoimportanteresultacasi imposi-
ble.Si si laconclusiónnoseproduce
deinmediatoosi el problemanoes
visibleinmediatamente,el resultado
esel efectodel lunespor lamañana.
Paraevitarlo,lasimplementaciones
handeestar automatizadas,losequi-
poshandeutilizar procesosdeimple-
mentaciónsimilares,loscambioshan
deintroducirsedeformaincremental
ylaactividaddeladistribucióndebe
ser visibleparatodoscuantointervie-
nenenella.

20
Mientras que los defectos en el código y en la configuración aumen-
tan los riesgos de forma lineal con el aumento del tamaño de los
lotes, los defectos en complejidad aumentan los riesgos al cuadrado.
Según se muestra en la figura 2-1, si se distribuyen tres caracterís-
ticas, es preciso gestionar tres relaciones, pero si añadimos solo
una característica más a la distribución, son seis las relaciones que
gestionar. Como vemos, añadir solo una aplicación más duplica las
relaciones y crea más complejidad, y, por tanto, más riesgo.
Aplicación
Relación
Figura2-1:Comprender lasrelacionesylacomplejidad.
Para las organizaciones que utilizan procesos manuales de imple-
mentación o distribuciones lentas para conseguir un mejor control
de la calidad, el riesgo de fallos ha crecido exponencialmente. Los
grandes lotes de distribuciones con numerosas interdependiencias
conllevan el riesgo de múltiples fallos. Sin embargo, utilizar el mismo
proceso de implementación, automatizar las tareas manuales y rea-
lizar cambios incrementales hace posible un proceso optimizado de
distribuciones.
Para obtener más información sobre gestión de riesgos y defectos
en las distribuciones, visite http://ibm.co/UCVlog4.

Capítulo3
Elegirsoluciones
paraladistribución
eimplementaciónde
aplicaciones
En este capítulo
▶ Preparar a su organización para el cambio
▶ Considerar distintas soluciones de distribución e implementación
▶ Buscar una solución para la coordinación de distribuciones
Para gestionar su aplicación durante el proceso de compilación
y entrega con automatización de la implementación y a la vez
orquestar y coordinar todo el proceso de distribución se precisan
soluciones especializadas. Las soluciones de automatización de la
implementación de aplicaciones y de coordinación de distribucio-
nes están diseñadas para llevar las aplicaciones de alta calidad a la
fase de producción lo más rápidamente posible.
En este capítulo trataremos de la forma de preparar a su orga-
nización para los cambios que introducirán las soluciones de
distribución e implementación de aplicaciones. Acontinuación pre-
sentaremos los criterios básicos para evaluar estas soluciones.
Prepáresepara loscambios
Antes de comenzar a buscar una solución, recuerde los objetivos de
las herramientas de automatización de la implementación de aplica-
ciones y de coordinación de distribuciones:

22
✓ Reducir el tiempo de llegada al mercado: Aumentar la fre-
cuencia de la entrega del software con mayor conformidad
mediante auditabilidad y transparencia de extremo a extremo
y menor tiempo para la obtención de feedback
✓ Reducir costes: Reducir la cantidad de trabajo manual, los
tiempos de espera de los recursos y la duplicación de trabajos
mediante la eliminación de errores y con implementaciones de
autoservicio
✓ Reducir riesgos: Entregar aplicaciones de alta calidad
mediante procesos de implementación automatizados y repe-
tibles en todos los entornos de desarrollo, pruebas y produc-
ción
Para alcanzar la mayoría de los objetivos de negocio es preciso
reconocer los cambios requeridos para los distintos miembros del
equipo, interacciones, procesos y soluciones, tal y como se indica
en esta sección.
Aclimatar a sus equipos a los cambios propuestos puede ser el paso
más largo y difícil de todo el proceso de implementación, pero es
indispensable para unas prácticas optimizadas y totalmente auto-
matizadas de distribución e implementación.
Cambiosderoles
Algunos de los cambios más importantes que va a realizar conllevan
tareas de miembros individuales del equipo e interacciones entre
los miembros del equipo. En palabras del Manifiesto Agile, los miem-
bros de su equipo deberán estar preparados para ajustar sus méto-
dos de interacción y la frecuencia de estas interacciones. También
deberán estar preparados para aceptar las soluciones de automati-
zación y los nuevos roles que tendrán en el seno de la organización.
Negocie con la dirección los cambios en roles de los miembros del
equipo para garantizar a los empleados que las soluciones de auto-
matización les ayudarán a cumplir sus tareas diarias. La solución
no pretende sustituir al talento humano, sino contribuir a alcanzar
el resultado que desea la organización reduciendo la cantidad de
tareas repetitivas que conllevan riesgos, y capacitando a los miem-
bros del equipo para centrarse en las tareas que precisan más capa-
cidad creativa.
Busque un adalid interno que comprenda las ventajas del cambio.
Esta persona puede ofrecer el punto de vista de los interesados
sobre los efectos de la solución a largo plazo. Un abanderado dentro

Capítulo 3: Soluciones para la distribución e implementación
23
del equipo comprometido con la nueva solución ofrece a sus com-
pañeros la posibilidad de conocer las ventajas por medio de una
persona que se enfrenta a sus mismas dificultades.
Introduzca este cambio cultural en una fase lo más temprana posi-
ble. En el capítulo 4 se presenta una idea general del tiempo que
pueden precisar distintos cambios.
Cambiosen procesosy soluciones
Amedida que cambian las personas y las interacciones para alcan-
zar los objetivos de negocio, también cambian las funciones empre-
sariales del día a día. Al introducir la solución que desea utilizar,
sea consciente de que encontrará cierta resistencia. Mantenga a su
equipo motivado y esté preparado para un periodo de solución de
problemas. Llevar a cabo el primer proyecto importante con ayuda
de la solución obligará a todos a confrontar la nueva solución y los
nuevos procesos y descubrir una forma de interacción más eficiente.
Si presenta las soluciones y el proceso sin preparar adecuadamente
a su equipo, es probable que no acierte con la implementación satis-
factoria. Para alcanzar un objetivo de negocio es necesario efectuar
cambios en los procesos, soluciones, personas e interacciones.
Evaluar solucionesdedistribución
eimplementación
Las soluciones de automatización de la implementación de aplica-
ciones gestionan los componentes de la aplicación y sus versiones y
controlan qué versión se implementa en cada entorno. Estas solucio-
nes son esenciales para las prácticas de distribución e implementa-
ción de aplicaciones, como se explicar más adelante en este capítulo.
Al buscar una solución para automatización de la implementación,
dependiendo de sus metas de negocio, la solución deberá ofrecer las
siguientes capacidades:
✓ Reutiliza los procesos de implementación en distintos entornos
✓ Coordina la implementación de aplicaciones en múltiples
niveles
✓ Se integra con las tecnologías ya existentes
✓ Ofrece seguridad basada en roles

24
✓ Mantiene registros de todos los comandos ejecutados en las
implementaciones
✓ Controla quién ha implementado qué versión de cada material
implementable y a qué destino
Priorice las características que más necesarias sean para su organi-
zación para alcanzar el objetivo de negocio deseado. Por ejemplo,
es posible que su organización desee garantizar la auditabilidad y la
gobernanza, o minimizar el esfuerzo necesario para superar las audi-
torías. En este caso, la capacidad de la solución para ofrecer seguri-
dad basada en roles y mantener registros de la implementación es
más importante que el resto de capacidades.
Implementaciónsatisfactoriacon
IBM UrbanCodeDeploy
Una organización financiera estaba
desarrollando una nueva plataforma
de trading que iba a ser el motor
vital de la organización. El equipo de
desarrollo utilizó prácticas de desa-
rrollo Agile para producir resultados
más rápidamente, pero el proceso de
implementar aplicaciones en cientos
deservidoressebasabaenunsistema
básicamente manual que precisaba
adaptación para cada aplicación. En
realidad, la introducción de prácticas
Agilehizoqueloscambiosseacumu-
lasen para el equipo de operaciones,
cuyo equipo de implementación no
estabapreparadoparamanejar cam-
biosfrecuentes.Esteproblemallegoa
detener el procesodedesarrollo.
Pero la institución seguía deseando
conseguir los beneficios de las meto-
dologías Agile. Tras evaluar minu-
ciosamente numerosas soluciones,
sustituyeron sus prácticas manua-
les de implementación por IBM
UrbanCode Deploy, que les ofreció
variosbeneficios:
✓ Lostiemposdeimplementaciónse
redujerondetresdíasadoshoras.
✓ La organización ahorró más de
dos millones de dólares solo en el
primer año al eliminar el coste de
lasimplementacionesmanuales.
✓ La organización consiguió el nivel
deconformidaddeseadoyofreció
alosequiposuna opcióndeauto-
servicio para implementar aplica-
ciones.

Capítulo 3: Soluciones para la distribución e implementación
25
Evaluar solucionesdecoordinación
dedistribuciones
Planificar, gestionar y ejecutar una distribución importante de una
aplicación suele realizarse con ayuda de hojas de cálculo o docu-
mentos de distribución que indican las tareas, sus propietarios y la
secuencia precisa para el éxito de la distribución. El problema de
ejecutar una distribución de esta manera es que no hay forma de
controlar quién hizo qué cosa, qué código se implementó en qué
lugar y cuándo se produjo la distribución.
Las soluciones de coordinación de distribuciones están diseñadas
para ayudarle a planificar y ejecutar una distribución mediante una
planificación colaborativa que abarca los cambios en la aplicación y
en la infraestructura. Lo ideal es que una solución ofrezca visibilidad
total del proceso de distribución, así como capacidades de planifica-
ción y ejecución de extremo a extremo.
Al evaluar una solución de coordinación de distribuciones, usted
deberá buscar una solución capaz de:
✓ Optimizar la distribución de múltiples aplicaciones como una
misma distribución
✓ Actualizar el plan de distribuciones sobre la marcha
✓ Mostrar el progreso de la distribución en tiempo real
✓ Controlar los cambios en las aplicaciones y en la infraestruc-
tura
✓ Notificar a los interesados del progreso de la distribución
✓ Secuenciar y coordinar las actividades automatizadas y manua-
les en el flujo de trabajo de distribución, todas las relaciones
entre actividades y todas las comunicaciones relacionadas a
personas y sistemas automatizados
✓ Pasar automáticamente a nivel superior las aplicaciones que
satisfagan los criterios de los entornos inferiores

26
Aunque no es obligatorio, sí es recomendable utilizar una solución
de automatización de implementaciones con su solución de coor-
dinación de distribuciones. De la misma manera que las soluciones
de distribución e implementación de aplicaciones suelen funcionar
conjuntamente para alcanzar el mismo objetivo, las soluciones de
coordinación de entregas y automatización de la implementación
suelen funcionar conjuntamente para ayudar a crear un proceso de
entrega totalmente automatizado. Las soluciones de coordinación
de distribuciones se integran con las de automatización de la imple-
mentación para poner en marcha implementaciones automatizadas
de múltiples aplicaciones durante el tiempo de la distribución.
Distribución satisfactoria con
IBM UrbanCode Release
Unaorganizaciónsinánimodelucro
dedicaba demasiado tiempo en pla-
nificar ycoordinar lasdistribuciones.
Los miembros del equipo utilizaban
hojas de cálculo para controlar las
actividadesdedistribuciónysereu-
nían varias veces para revisar los
planes y los cambios realizados. La
organización quería lograr mayor
visibilidadensusesfuerzosdedistri-
bución y reducir el tiempo dedicado
a reuniones durante el proceso de
distribución. Finalmente, eligió IBM
UrbanCode Release, la primera
solución diseñada específicamente
para distribuciones de aplicaciones
complejas.IBM UrbanCodeRelease
permitió a la organización reducir
a la mitad el número de reuniones,
reducir a la mitad la duración de
cada reunión y aumentar la visibili-
dad de toda la distribución. Al final
de la segunda distribución con la
solución, los miembros del equipo
habíanimplementadounaadecuada
plantillaparadistribuciones.Al fina-
lizar la tercera sesión, el líder del
equipo que implementó la solución
se sentía tan cómodo con ella que
se fue de vacaciones en plena dis-
tribución.

Capítulo4
Ponerlasoluciónenmarcha
En este capítulo
▶ Sacar partido a una solución de automatización de la implementación
de aplicaciones
▶ Introducir una solución para coordinación de distribuciones
Cuando su organización haya seleccionado las mejores solucio-
nes de distribución e implementación para sus necesidades
(ver Capítulo 3), deberá poner en funcionamiento estas soluciones.
Este capítulo le ofrece algunas sugerencias.
Poner en funcionamientouna
solución deautomatización dela
implementación deaplicaciones
Como mencionamos en el capítulo 2, los objetivos de la automatiza-
ción incluyen la trazabilidad y visibilidad mediante una solución que
controle una compilación en los distintos estadios del ciclo de vida
de desarrollo del software (SDLC). Los principales componentes de
un proceso sólido en este contexto son un repositorio de versiones
de materiales para compilaciones completadas y gestión de depen-
dencias para proyectos dependientes.
Una forma de mantener estos dos componentes es con un servidor
de Integración continua (IC); la otra es integrar y controlar manual-
mente las compilaciones. Con un método de integración manual, es
preciso controlar las versiones y las compilaciones activas con un
repositorio funcional de materiales. Con un servidor de IC, también
deberá asegurarse de que su solución o proceso incluya los dos
pasos siguientes. Cuando tiene visibilidad del contenido de cada
compilación y de lo que cada material debe volver a implementar

28
si algo va mal en un entorno superior, ha establecido los requisitos
mínimos para poner en funcionamiento su solución de automatiza-
ción de implementación de aplicaciones.
Para poner en funcionamiento adecuadamente una solución de
automatización de implementaciones deberá disponer de un
proceso de compilación fiable. Si sus compilaciones son poco uni-
formes o poco fiables, la automatización del despliegue puede des-
cubrir los fallos más pronto, pero el problema intrínseco de calidad
se mantiene.
Escoger el mejor momentopara
la implementación
Al avanzar con la puesta en funcionamiento, sus dos principales pro-
blemas son superar la resistencia de su equipo y encontrar el pro-
yecto o aplicación que reúna las cualidades que usted precisa para
la automatización. Estos dos problemas están conectados entre
sí. Escoger una aplicación equivocada para la automatización crea
resistencia y una automatización mal planificada o documentada
tiene grandes posibilidades de fracasar.
Por tanto, la práctica recomendada es elegir el momento adecuado
para implementar la aplicación o proyecto en cuestión.
Un momento ideal es durante un proyecto Greenfield, cuando una
nueva aplicación tenga una implementación que precise automati-
zación. Otro momento potencialmente ideal es durante un proyecto
Brownfield, ya iniciado pero también preparado para la automatiza-
ción. Elegir el proyecto Greenfield o Brownfield adecuado precisa
una atenta consideración.
Deberá considerar si su proyecto o aplicación están preparados
para la automatización. Las aplicaciones que precisan automatiza-
ción tienen un proceso de implementación bien documentado e,
idealmente, una serie de tareas repetitivas. Si está examinando un
proyecto Greenfield, puede utilizar una aplicación que sea similar a
una aplicación previamente distribuida, o bien su plan de implemen-
tación existente puede pasarse a la solución de automatización. Las
mismas reglas valen para un proyecto Brownfield. Si dispone de un
proceso de implementación y se ve presionado a realizar las distri-
buciones más rápidamente, puede pasar el proceso a una solución
de automatización.

Capítulo 4: Poner la solución en marcha
29
Para elegir el proyecto Greenfield o Brownfield apropiado, deberá
saber cómo suelen trabajar sus equipos y en qué punto introducir el
cambio. Por ejemplo, si suele realizar implementaciones orientadas
al desarrollo, debería pasar la potencia y diseño de la implemen-
tación al equipo de operaciones. Si este proceso suele terminar
creando un muro entre desarrollo y operaciones, el equipo que
implementa a producción deberá estar a cargo del proceso y de la
automatización. Saber en qué puntos suele fallar el proceso puede
ser útil para poner la solución en marcha, y la programación tempo-
ral deberá estar acompañada de las personas, procesos y solucio-
nes (ver Capítulo 3).
La figura 4-1 muestra las tareas en las que deberá pensar para obte-
ner una idea sobre cómo planificar e poner en funcionamiento sus
soluciones.
Establish BusinessGoals
Individualsand Interaction Changes
ProcessandTools
CreateaProduction
-likeEnvironment
PracticeProduction
styleDeployments
Minimum State
ChoosetheIdealTime
EvaluateDeployand/or
ReleaseSolutions
Figura 4-1: Un ejemplo de calendario de implementación y puesta en
funcionamiento.
Crear unentornosimilar al deproducción
En cuanto tenga planificado su proyecto, deberá diseñar un entorno
similar al de producción como punto de partida para el desarrollo.
Es probable que este entorno sea de menor tamaño, pero deberá uti-
lizar los mismos sistemas operativos, middleware y configuraciones
que el entorno de producción. Como hemos indicado en el capítulo
1, UAT es uno de los cuatro entornos típicos del SDLC y ofrece la
posibilidad de hacer pruebas en un entorno similar al de produc-
ción. Los recursos de producción que no están disponibles para
los entornos de prueba deberán ejecutarse mediante simulación de
servicios, si es posible.
Para obtener más información sobre virtualización de servicios,
consulte Virtualización de servicios para Dummies, Edición Limitada
IBM, en ibm.co/servicevirtualization.

30
Un entorno similar al de producción aumenta la precisión de las
pruebas tanto para los procesos de aplicación como de implemen-
tación. Puede simplificar sus entornos a medida que retroceda a
entornos anteriores y elimine componentes innecesarios.
Implique a sus equipos de operaciones en la fase más temprana
que le sea posible en lugar de dejar la crítica implementación final a
producción para el último momento y cruzar los dedos. El permitir
que estos equipos participen desde el comienzo del Ciclo de vida de
desarrollo de software (CVDS) permite a los equipos de desarrollo
desarrollar y comprobar sus compilaciones y libera a los equipos
de operaciones para comprobar e implementar las aplicaciones.
También garantiza un entorno de diseño propio para mantener una
aplicación en orden de funcionamiento. Pasar algunas de las respon-
sabilidades de desarrollo mejora la coordinación entre desarrollo y
operaciones y crea un proceso beneficioso para todos los equipos.
Este cambio en la forma de pensar y en los procesos es la meta esen-
cial de DevOps. Fuerza a tomar en consideración los problemas de
Operaciones a lo largo del CVDS, no solo en el momento de la imple-
mentación. Asu vez, Desarrollo tiene acceso a entornos similares a
los de producción, lo que les permite desarrollar y hacer pruebas
contra un modelo más realista, como el que utilizarán los usuarios.
Los equipos de operaciones también se benefician de una vista
previa de cómo reaccionará su entorno a la aplicación y dónde es
posible mejorar el soporte.
Practicar implementaciones
similaresa producción
Si el estado ideal que desea alcanzar es una distribución optimizada
formada por implementaciones automatizadas, necesitará un pro-
ceso repetible y uniforme. Para lograrlo, comience por practicar
implementaciones similares a producción que sea posible simplifi-
car para entornos anteriores. Los entornos en sí también deberán
ser lo más semejantes posible a producción. En una nueva imple-
mentación, es fundamental dar con un proyecto que pueda adap-
tarse a este criterio.
Diseñar enprimer lugar paraproducción
Producción es el entorno más complejo, por lo que las implemen-
taciones en entornos anteriores deberán diseñarse como versiones
sencillas de implementaciones anteriores. Aumentar la complejidad
de la implementación entre desarrollo y producción no funciona, de

31
la misma manera que aumentar el tamaño de un cuadrado no crea
un cubo. Las dimensiones y complejidad de producción no tienen
un marco adecuado en desarrollo, por lo que si crea un proceso de
implementación basado en el desarrollo, acabará por tener que reha-
cerlo sustancialmente en producción.
Diseñar el proceso comenzando por producción ofrece varias
ventajas:
✓ Permite a los equipos practicar antes de la implementación final
crítica (ver sección anterior) y constituye una plantilla para el
resto de los procesos que condicen al comienzo del CVDS.
✓ Permite a los equipos ajustar y optimizar el proceso. La auto-
matización avanza esta meta estabilizando pasos anteriormente
manuales en un complejo proceso y reduce esfuerzos innecesa-
rios en futuras implementaciones.
✓ Elimina la desconexión en la complejidad de los procesos de
implementación entre los entornos de fases tempranas y poste-
riores. Comenzar el proceso de diseño por la fase de desarrollo
evita la alineación con los objetivos de los equipos de operacio-
nes porque un proceso diseñado y comprobado por sí mismo
no puede alcanzar el nivel de complejidad que requieren los
equipos de operaciones.
Los desarrolladores se centran en comprobar sus aportaciones indi-
viduales y la pieza representativa de la aplicación completa que se
aplica a su función en el proyecto. Por este motivo, muchas veces los
desarrolladores no tienen en consideración o no conocen lo que se
precisa para mantener el entorno de producción estable y funcional.
Debido a la magnitud y la escala de lo que se necesita comprobar y
mantener funcional en producción, el proceso de implementación
no debe ser diseñado por equipos que no estén familiarizados con
el entorno de producción. Este es el motivo inevitable por el que
permitir a los desarrolladores diseñar un proceso de distribución
continua como extensión de la integración continua se detiene antes
de Producción y choca contra el muro de Operaciones.
Para alinear plenamente a sus equipos y facilitar la colaboración
desde el inicio de un proyecto, debe reconocer la importancia de
comenzar por los procesos más complicados y eliminar pasos para
simplificarlos. Es más fácil eliminar pasos que añadirlos durante una
crisis o cuando una implementación ha dado fallos en producción.

32
Poner enfuncionamientounasolución
paracoordinacióndedistribuciones
La coordinación de distribuciones es ideal para organizaciones que
implementan múltiples aplicaciones a la vez o que desean tener
mayor visibilidad de un proceso complejo de distribuciones. Como
mencionamos en el capítulo 3, es posible utilizar una solución de
coordinación de distribuciones con o sin soluciones de automatiza-
ción de implementaciones.
Si su proceso de distribución es una larga lista de tareas manuales
contenida en una hoja de cálculo, debería evaluar posibles solucio-
nes para mejorar este proceso. Sin embargo, si desea poner en fun-
cionamiento coordinación de distribuciones con automatización de
implementaciones, deberá contar con mejores prácticas adicionales
para automatización de implementaciones.
Identificar un modelorealista
dedistribuciones
Para conseguir una solución satisfactoria de coordinación de dis-
tribuciones, deberá estar familiarizado con su proceso actual, con
las aplicaciones que se va a distribuir y con la complejidad de estas
aplicaciones. Comience por una distribución pequeña y avance
hasta la distribución de múltiples aplicaciones. Incluso con una
distribución pequeña o de muestra deberá conocer la aplicación o
aplicaciones y característica(s) que se distribuyen y quién participa
en el proceso típico.
La clave de este concepto es la escala. Es recomendable comenzar
por el modelo lógico más pequeño de un proceso de distribución
típico. Utilice una distribución que, aunque sea pequeña, resulte útil
de ampliar en futuras distribuciones representando su proceso ideal
desde el comienzo, lo que supone incluir las personas que participa-
rán en las distribuciones más complejas.
No se líe con escenarios hipotéticos, porque no podrá predecir todo
hasta que realmente comience a utilizar la solución y pueda descu-
brir áreas de mejora. Usted y/o su equipo deberán buscar la forma
de poner en funcionamiento la solución de coordinación de distribu-
ciones que les ofrezca más beneficios.

33
Escoger una ruta deimplementación
Una vez elegida una distribución que se utilizará como base para
futuras distribuciones, deberá identificar una ruta lógica para llegar a
la implementación. Hay tres rutas principales que ofrecen una transi-
ción sin sobresaltos hacia el uso de una solución de coordinación de
distribuciones:
✓ Utilizar la nueva solución en paralelo con el proceso exis-
tente. La primera ruta es utilizar la solución en paralelo con
un proceso de distribución ya existente. Esta ruta permite al
equipo de distribución asignar un proceso existente al proceso
de la solución de distribución mientras se ejecutan ambas. En
la práctica, esto significa llevar a cabo una distribución de la
forma tradicional y a la vez ejecutar la distribución en la nueva
solución para ver cómo difieren las tareas con la herramienta.
Esta práctica ayuda al equipo a acostumbrarse al nuevo pro-
ceso, pero además ofrece un sistema de prueba sin riesgos para
el primer uso, lo que reduce ansiedades para la siguiente distri-
bución al demostrar las tareas en paralelo con cada método y
ofrecer una imagen completa del proceso antes y después.
✓ Realizar una ejecución posterior a la distribución. La segunda
ruta es llevar a cabo una ejecución posterior a la distribución
utilizando la solución como modelo de una distribución recien-
temente realizada, es decir, volver a realizar la distribución
de una aplicación utilizando el actual proceso estándar y a
continuación utilizar el mismo proceso para distribuir una
aplicación con una solución de coordinación de distribuciones.
De forma muy similar a ejecutar la solución en paralelo a una
distribución en curso, esta práctica proporciona al equipo una
imagen antes y después del proceso y una forma de utilizar la
solución con seguridad por primera vez.
Las dos primeras rutas son ejercicios que ofrecen casos de uso
prácticos y realistas de la solución y permiten a los miembros
del equipo la oportunidad de realinear sus expectativas e inte-
racciones.
✓ Zambullirse donde más cubre. La tercera vía, menos con-
servadora que las dos anteriores, es lanzarse al agua donde
más cubre y, simplemente, utilizar la nueva versión para una
distribución en tiempo real. Prepare a sus equipos para el éxito
eligiendo una distribución pequeña que usted sepa que pueden
ejecutar con la solución. Reduzca la distribución seleccionada
a su estado mínimo de complejidad y preséntela a su equipo
como primer uso en directo y de bajo riesgo de la solución.

34

Capítulo5
Diezmitossobrela
distribucióneimplementación
deaplicaciones
En este capítulo
▶ Comprender por qué la automatización puede ser una ayuda, no un
obstáculo
▶ Saber qué puede y no puede hacer una solución concreta
En ocasiones, la mejor forma de conocer la verdad sobre un
concepto es comprender algunos conceptos falsos sobre él.
Con esta intención presentamos diez mitos sobre la distribución y
desarrollo de aplicaciones.
Automatizar la implementación
significa crear scripts
Aunque utilizar scripts específicos para la implementación puede
funcionar para pequeñas implementaciones en un número reducido
de servidores, esta técnica no es apropiada para la escala y comple-
jidad de las aplicaciones empresariales interdependientes.
Recurrir a un experto en la materia para ejecutar scripts de imple-
mentación puede suponer un gran esfuerzo para todo el equipo
de implementación, y en especial para la persona responsable. Si
el experto no está disponible para ejecutar el script (o ya no está
en la organización cuando llega el momento de un cambio), es fácil
no poder cumplir un plazo o no llevar a cabo el paso en cuestión.
Además, si el experto es responsable de ejecutar los scripts para

36
múltiples implementaciones, la posibilidad de errores aumenta con el
tamaño de cada lote (ver Capítulo 2). Por otra parte, las limitaciones
humanas, como el cansancio, la ansiedad y los nervios afectan al ren-
dimiento cuando una persona realiza una larga serie de tareas repeti-
tivas y bajo una fuerte presión.
La mejor solución es dejar que una solución de automatización de la
implementación de aplicaciones ejecute las implementaciones, ideal-
mente utilizando integraciones. Si la solución que elija puede inte-
grarse eficazmente con las herramientas que ya utiliza, deberá poder
crear un proceso de implementación mediante un sencillo diseñador
de procesos no basado en scripts. Unas integraciones efectivas y un
diseñador de procesos tipo arrastrar y soltar puede eliminar todos o
casi todos los scripts de su proceso de implementación.
Losequiposdedesarrollocreanlos
mejoresprocesosdeimplementación
Los desarrolladores saben cómo debería funcionar una aplicación
pero posiblemente no conozcan el funcionamiento de la topología
de la aplicación en un entorno de producción, porque no es ese su
cometido. Es probable que al asignar al equipo de desarrollo la tarea
de diseñar un proceso de distribuciones el resultado sea un plan que
pase por alto algunas necesidades operativas clave o configuraciones
específicas de producción, como agrupación en clústeres, equilibra-
dores de cargas e integración con sistemas externos.
Como mencionamos en el capítulo 4, comenzar a planificar el proceso
de implementación en producción permite al equipo de desarrollo
comprobar la aplicación contra un entorno similar al de producción.
También permite a los equipos de desarrollo y operaciones compro-
bar el proceso de implementación temprano y con frecuencia. Los
mejores procesos de implementación son el resultado de la colabora-
ción entre desarrollo, operaciones e ingeniería de distribuciones.
Esposiblegestionar fácilmente
distribucionescomplejassin
solucionesespecializadas
Desde luego, es posible gestionar sencillas distribuciones de aplica-
ciones mediante distintos métodos, como correos electrónicos, docu-
mentos Runbook y soluciones de automatización de implementacio-

Capítulo 5: Diezmitos sobre la distribución e implementación
37
nes. Sin embargo, los tres primeros métodos no ofrecen trazabilidad
ni planificación colaborativa de implementaciones, y ninguno de
ellos puede escalarse para admitir la complejidad de una distribu-
ción empresarial independiente.
Aunque es posible utilizar una solución de automatización de
implementaciones para gestionar una distribución, es mejor utilizar
una solución de coordinación de distribuciones. Las soluciones de
coordinación de distribuciones están diseñadas para ayudarle en
la planificación y ejecución de una distribución ofreciendo planifi-
cación colaborativa para la distribución, que incluye cambios en la
infraestructura y en la aplicación.
Entregacontinuasignificaconstantes
distribucionesaproducción
Entrega continua (EC) no es lo mismo que distribución continua.
La EC se centra en acelerar el paso de una nueva versión por el
proceso de entrega lo más rápidamente posible y esperar a que la
empresa decida cuándo realizar la distribución. La misma tecnología
se utiliza para entornos de producción, pero la decisión la toman
humanos.
Para la mayoría de las organizaciones, sus pruebas automatizadas
no son suficientes para validar que una nueva versión esté prepa-
rada para producción. Para estas organizaciones, la entrega con-
tinua minimiza la fricción provocada por el paso de las versiones
a distintos entornos y maximiza la productividad del equipo de
pruebas.
Laautomatizaciónreducelacalidad
y el control
La automatización refuerza la calidad porque aprovecha las capa-
cidades de los ordenadores para ejecutar tareas repetitivas que
pueden malograrse si se ejecutan manualmente.
También se mejoran los controles. El botón de implementación está
protegido por seguridad basada en roles y es posible aplicar auto-
máticamente reglas de aprobación y controles de calidad. Cuando
tenga una pista de auditoría completa con indicación de quién con-
figuró un proceso y quién lo ejecutó, tendrá conocimiento exacto de
lo sucedido en cada momento.

38
Unahojadecálculoesunabuena
herramientadegestióndedistribuciones
Muchos equipos de distribución consiguen funcionar mediante el
uso de hojas de cálculo, pero este método de coordinación resulta
inevitablemente en errores humanos. Las hojas de cálculo permiten
gestionar el proceso de distribución en el nivel más elevado, pero
obligan a realizar manualmente tareas repetitivas, lo que aumenta
las ocasiones para que aparezcan errores y precisan un manteni-
miento continuado para asegurarse de que todos los miembros
del equipo estén informados. Por último, al variar las ubicaciones,
aumentar los equipos de tamaño y crecer la complejidad e interde-
pendencia de las aplicaciones, las hojas de cálculo son proclives a
los errores y resultan menos útiles, porque no pueden escalarse al
aumentar la complejidad.
Adiferencia de las hojas de cálculo, las soluciones de coordinación
de distribuciones capturan las interdependencias y determinan
la estrategia de implementación más eficaz. También alertan a los
miembros del tiempo de distribución cuando se han superado
determinados hitos del proceso o cuando se precisan las destrezas
de determinados miembros del equipo.
Las soluciones de coordinación de distribuciones son muy recomen-
dables para organizaciones que tengan un proceso de distribución o
equipos distribuidos, o que hayan intentado infructuosamente ges-
tionar su proceso de distribuciones con hojas de cálculo.
Las soluciones de coordinación de distribuciones pueden utilizarse
sin soluciones de automatización de implementaciones, pero es
recomendable usar ambas para reducir los riesgos asociados con
las tareas manuales repetitivas y reducir el tiempo de llegada al
mercado.
Unadistribucióngrandeesmenos
arriesgadaquevariaspequeñas
En realidad, las distribuciones grandes conllevan un riesgo supe-
rior que las pequeñas y más frecuentes, al aumentar el número de
interdependencias incluidas. Si optimiza el proceso de distribución
e implementación mediante soluciones de automatización, libera a
sus empleados para resolver el problema en sí, en lugar de obligar-
los a llevar a cabo tareas manuales muy repetitivas.

39
Las distribuciones más pequeñas tienen menos elementos y menos
interdependencias. Los errores debidos a errores de comprensión o
falta de previsión en cuanto a independencias se reducen drástica-
mente con distribuciones más pequeñas.
Los cambios incrementales mediante entrega continua real son los
objetivos finales de cualquier organización que desee ofrecer valor
mediante nuevas características con mayor frecuencia que la com-
petencia. Los cambios pequeños y frecuentes ofrecidos mediante
soluciones de automatización son el primer paso para reducir el
coste y los riesgos asociados con las distribuciones tradicionales.
Laautomatizaciónesindependiente
del procesodecompilación
Por desgracia, hasta que no alcance los requisitos mínimos de un
repositorio de materiales funcional, gestión de dependencias y resul-
tados de alta calidad de su proceso de compilación, usted no estará
preparado para intentar la automatización de implementaciones.
Los elementos de las implementaciones deben tener control de ver-
siones o estar preparados para control de versiones, lo que permite
hacer seguimiento de qué se implementa y dónde se implementa
cada elemento. Para completar distribuciones satisfactorias que
ofrezcan visibilidad durante todo el ciclo de vida de desarrollo del
software, es preciso asegurarse de que las dependencias sean mane-
jables, visibles y evidentes como parte del proceso de compilación.
Normalmente se alcanza el estado mínimo requerido con ayuda de
un servidor de integración continua (IC) que también ofrece capaci-
dad de versiones y autoservicio para implementar en entornos de
prueba. Las formas manuales de IC le permiten automatizar parcial-
mente la implementación, pero carecen de la plena visibilidad que
recomendamos alcanzar antes de pasar a soluciones de automa-
tización de implementaciones. El objetivo primario de un proceso
de compilación optimizado es crear compilaciones funcionales
con control de versiones y preparadas para ser implementadas
mediante pruebas y a producción con un elevado nivel de calidad.
Algunas soluciones de automatización de distribuciones ofrecen
capacidad de control de versiones con un repositorio de materiales
propio. Esta capacidad le permite evitar tener que hacer control
de versiones de sus propias compilaciones y utilizar la solución de
automatización de implementación de aplicaciones para incorporar
este paso. Una solución de este tipo es IBM UrbanCode Deploy.

40
Unbacklogdemateriales
implementablesnoindicaun
problemadeDevOps
Si usted dice practicar la implementación continua pero su equipo
de operaciones acumula un enorme registro tareas pendientes
procedentes de desarrollo, tiene un problema de DevOps, y no está
practicando realmente la implementación continua. Las prácticas y
soluciones de DevOps le ayudan a aprovechar las oportunidades del
mercado y reducir el tiempo necesario para obtener feedback de los
clientes, haciendo posible una auténtica implementación continua.
Cuando decide implementar soluciones de distribución e implemen-
tación, deberá prepararse para trabajar en una cultura DevOps, que
implica cambios en las personas, interacciones, procesos y solucio-
nes (encontrará más información sobre DevOps en el capítulo 1).
Cuando haya minimizado las diferencias entre los entornos de
desarrollo y operaciones, estandarizado su proceso de distribución
e implementación y automatizado la mayor parte de sus tareas
manuales o todas, dispondrá de una solución DevOps. Esta solu-
ción DevOps acelera la entrega del software, reduce el tiempo para
obtener feedback del cliente, mejora la gobernanza en todo el ciclo
de vida de desarrollo del software y equilibra calidad, costes y
velocidad.
Lassolucionesdecoordinaciónde
distribucionesresuelventodoslos
problemas
El paso de un proceso de distribuciones e implementaciones total o
principalmente manual a uno automatizado es complicado y precisa
considerar varios aspectos. Uno de los cambios a largo plazo más
importantes es en relación con la cultura de su organización. Sus
personas e interacciones deben estar en línea con el nuevo método
de trabajo y los posibles cambios en las responsabilidades. Deberá
preparar a sus equipos para el cambio, esperar que se produzca un
cierto nivel de resistencia y mantenerse al tanto de qué cosas fun-
cionan y no funcionan para su organización.

41
Cuando haya seleccionado el proyecto adecuado para implementar
las soluciones de automatización de la implementación de aplica-
ciones y de coordinación de distribuciones, sus equipos no tendrán
más opción que colaborar. Sin embargo, prepararlos lo más posi-
ble para el cambio facilitará la transición y le ayudará a alcanzar
sus objetivos de negocio. Al igual que abordar los problemas de
compilación y de IC reduce los cuellos de botella en las fases de
desarrollo e implementación continua, posiblemente comience a
ver otras oportunidades de mejora para su ciclo de vida del desa-
rrollo de software al introducir soluciones de implementación y
distribuciones.

W ILEY END USER LICENSE
AGREEM ENT
Go to www.wiley.com /go/eula to a ccess
Wiley’s ebook EULA.

Distribución e implementación de aplicaciones para dummies

Recomendados

Recomendados

Más contenido relacionado

Similar a Distribución e implementación de aplicaciones para dummies

Similar a Distribución e implementación de aplicaciones para dummies (20)

Último

Último (20)

Distribución e implementación de aplicaciones para dummies