Visual Studio Team Service.- Un viaje a dev ops
•Descargar como PPTX, PDF•
0 recomendaciones•187 vistas
Este documento describe el proceso de DevOps y cómo puede mejorar la colaboración entre desarrollo y operaciones. Explica que DevOps implica la automatización de pruebas, despliegues continuos y retroalimentación continua para entregar valor al cliente de manera más rápida y frecuente. También describe varias herramientas y prácticas de DevOps como integración continua, despliegue continuo, pruebas automatizadas y monitoreo de producción.
Recomendados
Más contenido relacionado
Similar a Visual Studio Team Service.- Un viaje a dev ops
Similar a Visual Studio Team Service.- Un viaje a dev ops (20)
Más de Peter Concha
Más de Peter Concha (20)
Último
Último (19)
Visual Studio Team Service.- Un viaje a dev ops
- 2. Un viaje a DevOps VISUAL STUDIO
- 3. Introducción
- 5. ¿Dónde estaban? Planeación Beta ? RTM ? Código Pruebas y Estabilización Código Pruebas y Estabilización 2,5 años Su proceso de desarrollo Pedían comentarios después de cada hito (planificación, Beta, RTM). Con este proceso encontraban bugs y desarrollaban su respectiva solución; hasta ahí, no había problema alguno. Pero no podían reaccionar a tiempo a las peticiones de los clientes que usaban el producto En la mayoría de las veces, se daba al mundo un “lo siento” … y se planeaba las cosas para el próximo release.
- 6. Colaboración en Desarrollo y Operaciones. Es un título de trabajo Es automatización Significa versiones más rápidas y pequeñas
- 7. Desarrollo + Pruebas Plan + Vía(s) Monitoreo + Aprendizaje Release Desarrollo Producción
- 8. Hablemos de DevOps Personas Colabore más Comparta metas Centrarse en la mejora TRABAJEN JUNTOS Proceso Eliminar residuos Incremente la eficiencia Optimizar la retroalimentación ENTREGANDO RAPIDAMENTE VALOR Herramientas Mejorar la productividad Habiliten la colaboración Facilite experimentar EJECUTANDO LA ESTRATEGIA DEVOPS
- 9. FLUJO DE VALOR PARA EL CLIENTE AUTONOMÍA Y ALINACIÓN BACKLOG mejorado por APRENDIZA JE P R U E B A S O BT E N I DA S E N P R O D U CC I Ó N DEUDA TÉCNICA GESTIONADA MENTILDAD PRIMERO PRODUCCIÓN INFRA como un RECURSO FLEXIBLE
- 10. Infraestructura como Código Cloud Dev / Test Escalado Automático “Sandboxing” / Dev y Laboratorios de Pruebas Apuesta por los Contenedores Arquitectura de Microservicios Pruebas en Producción Monitoreo del Uso Telemetría del Usuario “Stakeholder Feedback” Banderas de Características Experimentos Escala Ágil Equipos autogestionados Equipos de función Pruebas Automatizadas Integración Continua Despliegue Continuo Gestión del “RELEASE” Monitoreo de Uso Colección de Telemetría Pruebas en Producción “Stakeholder Feedback” Revisiones Par del Código Pruebas Automatizadas Medición Continua Documentación Ágil Desplazamiento hacia la Izquierda en “Inner Loop” Gestión del “Performance” de las Aplicaciones Infraestructura como Código Entrega Continua (Continuous Delivery) Gestión del “RELEASE” (Release Management) Gestión de la Configuración Recuperación Automatizada FLUJO DE VALOR PARA EL CLIENTE AUTONOMÍA Y ALINACIÓN BACKLOG mejorado por LEARNING P R U E B A S O BT E N I DA S E N P R O D U CC I Ó N DEUDA TÉCNICA GESTIONADA MENTILDAD PRIMERO PRODUCCIÓN INFRA como un RECURSO FLEXIBLE
- 12. INTEGRACIÓN CONTINUA DESPLIEGUE CONTINUO GESTIÓN DEL RELEASE PRUEBAS AUTOMATIZADAS
- 14. E Q U I P O S A U T O G E S T I O N A D O S C H A R L A S D E P L A N I F I C A C I Ó N E Q U I P O S D E F U N C I Ó N R I T U A L E S D E S P R I N T E S C A L A Á G I L S A L A S D E E Q U I P O
- 21. T E L E M E T R Í A D E U S U A R I O M O N I T O R E O D E U S O S T A K E H O L D E R F E E D B A C K P R U E B A S A / B E N P R O D U C C I Ó N
- 23. P R U E B A S E N P R O D U C C I Ó N S T A K E H O L D E R F E E D B A C K M O N I T O R E O D E U S O T E L E M E T R Í A D E U S U A R I O B A N D E R A S D E C A R A C T E R Í S T I C A S
- 25. S H I F T - L E F T ( D E S P L E Z A M I E N T O A L A I Z Q U I E R D A ) M É T R I C A S D E C Ó D I G O P R U E B A S A U T O M A T I Z A D A S P E E R C O D E R E V I E W S ( R E V I S I Ó N P A R D E C Ó D I G O ) I N T E G R A C I Ó N C O N T I N U A P R U E B A S U N I T A R I A S C O N T I N U A S
- 28. G E S T I Ó N D E L R E N D I M I E N T O ( P E R F O R M A N C E ) D E L A A P L I C A C I Ó N G E S T I Ó N D E L A C O N F I G U R A C I Ó N I N F R A E S T R U C T U R A C O M O C Ó D I G O R E C U P E R A C I Ó N A U T O M A T I Z A D A E N T R E G A C O N T I N U A G E S T I Ó N D E L A L I B E R A C I Ó N ( R E L E A S E )
- 31. I N F R A E S T R U C T U R A C O M O C Ó D I G O D E S A R R O L L A D O R S A N D B O X I N G L A B O R A T O R I O S D E D E V / T E S T L A N U B E A P U E S T A P O R C O N T E N E D O R E S M I C R O S E R V I C I O S A U T O E S C A L A D O M A N E J O D E L F R A C A S O ( F A I L O V E R )
- 32. VIEJO MUNDO Centrarse en la Planificación Competir, no colaborar Jerarquías Estáticas Productividad Individual Eficiencia de Proceso Supuestos, no datos NUEVO MUNDO Centrarse en la Entrega Colaborar para Ganar Equipos Fluidos y Flexibles Creación de Valor Colectivo Eficacia de los Resultados Experimentar, Aprender y Responder
- 34. stories.visualstudio.com | microsoft.com/devops DevOps en Microsoft Productos y guía basados en nuestros propios aprendizajes al moverse a la nube
- 35. La solución de DevOps de Microsoft VISUAL STUDIO
- 36. Una mayor productividad para el desarrollo de aplicaciones de empresa y la entrega Planificar, ejecutar y supervisar su esfuerzo a prueba de todo. Administrar la complejidad y acorta el ciclo entre IT Ops y desarrollo. Crear aplicaciones móviles para Android, iOS y Windows Visual Studio Enterprise Una solución DevOps integrada end-to-end para los desarrolladores en busca de alta productividad y coordinación a través de equipos de cualquier tamaño. Aprovechar herramientas avanzadas y servicios para diseñar, construir, implementar y administrar soluciones complejas, modernas aplicaciones y servicios para Android, iOS, Windows, web, nube y escritorio.
- 37. Visual Studio Team Services Microsoft Azure
- 38. Lo que dicen los analistas VISUAL STUDIO
- 39. Plataforma de Desarrollo de Aplicaciones Empresariales como un Servicio Plataforma de Desarrollo de Aplicaciones Móviles Sistemas de Gestión de Base de Datos de Misión Crítica Administración del Ciclo de Vida de la Aplicación 2016 2016 2016 2015 Líder en 17 cuadrantes mágicos de Gartner
- 40. “
- 41. © 2016 Microsoft Corporation. All rights reserved.
- 44. 1 Plan
Notas del editor
- Desde 1975, Microsoft ha hecho el desarrollo de cierta manera – en cascada. Pero hace 6 años, vieron un grave peligro llegando en el horizonte. El negocio estaba cambiando rápidamente alrededor del equipo “y tuvieron que girar el barco para sobrevivir”.
- Pero ¿dónde estaba antes Microsoft?
- Era, y sigue siendo… el tiempo de Agile y DevOps. Tuvieron que formular una estrategia DevOps para toda la organización. Pero, ¿qué es DevOps? ¡Puede significar cosas radicalmente diferentes para diferentes personas!
- Para ellos, DevOps significa la fusión de dos ciclos de vida previamente aislados: desarrollo y operaciones de TI. Un ciclo de vida de DevOps convergente nos da la capacidad de ejecutar las ideas e iterar sobre la retroalimentación rápidamente, con un mínimo de fricción.
- Rápidamente se dieron cuenta de que una transformación DevOps tendrá un amplio impacto organizacional. Cada vez que se hable de DevOps debe centrarse en personas, procesos y herramientas por igual, de lo contrario la transformación fallará.
- Su viaje a DevOps comenzó con la definición de los siete hábitos, hábitos que se deben ir refinando con el tiempo. Los hábitos de DevOps son amplios cambios de mentalidad que todo la organización tienen que abrazar y vivir activamente todos los días. Veámoslos individualmente.
- Su viaje a DevOps comenzó con la definición de los siete hábitos, hábitos que se deben ir refinando con el tiempo. Los hábitos de DevOps son amplios cambios de mentalidad que todo la organización tienen que abrazar y vivir activamente todos los días. Veámoslos individualmente.
- Flujo se refiere a la capacidad de una organización para mover el software de la idea inicial a través de la creación y validación en manos de los clientes y usuarios, sin impedimentos o bucles de repetición. Reducir el re-trabajo permitiendo a los equipos centrarse en ofrecer más valor. Los ciclos con tiempos más cortos apoyan una mayor capacidad de respuesta, que a su vez fomenta la satisfacción y confianza de los clientes y usuarios.
- Las prácticas de DevOps convierten los hábitos de DevOps en acciones. Las prácticas de DevOps de Microsoft están bien documentadas y pueden ser implementadas fácilmente por equipos individuales. Estas son algunas de las prácticas que están relacionadas con la mejora del flujo de valor.
- Nuestro objetivo principal es la capacidad de respuesta. Ser receptivo (capacidad de respuesta) depende de: un agendamiento flexible, iteraciones cortas y de una estrecha colaboración de equipo (no “del equipo” … “de”). Esto elimina los traspasos inútiles. Cada equipo tiene la libertad de auto-organizar su trabajo con total autonomía.
- En Microsoft sabe que tiene equipos con características multidisciplinarias que trabajan a partir de un producto con un backlog común, entregando un trabajo listo para desplegar al final de cada sprint. No dicen a sus equipos cómo hacer su trabajo o que rituales adoptar, todo lo que cuenta son resultados.
- Nosotros
- Se consolida Desarrollo y pruebas en un ingeniero de software. Se debe tener en el equipo el rol de Operaciones. Operaciones cambia a ser un equipo de rendición de cuentas sino: Arquitectura de las Aplicaciones Automatización Código por secuencia de Comandos “Ingenieros de Servicio”
- La comunicación es entre el cliente y el equipo. La idea es acortar la comunicación y mejorar los tiempos de respuesta.
- El modelo bajo el que estamos, solo genera retrasos.
- Ellos tratan su backlog como un conjunto de hipótesis, que se convierten en experimentos, y para los cuales recopilamos datos. También se relacionan constantemente con los stakeholders (partes interesadas) y seguimos sus comentarios. Basados en los datos y feedback (retroalimentación) planean su próximo movimiento y perseveran o pivotean.
- Han implementado prácticas que les ayuda a recopilar información de diferentes fuentes. Toda esta información les ayuda a mantener continuamente su backlog en sincronización con los objetivos del negocio y re-alinearnos con los cambios repentinos en el ambiente.
- Los buenos experimentos proporcionan datos procesables. Hay que medir todo: salud, disponibilidad, desempeño (performance) y otras métricas de calidad de servicio, pero también se debe usar para: recopilar evidencias que pruebe o refute cada hipótesis del backlog (lista ordenada de trabajo (ítems, historias de usuario, unidades de trabajo, etc. – depende del método ágil utilizado)).
- Dependemos en gran medida de la experimentación para afinar nuestros productos y servicios. En cualquier momento, debemos poder ejecutar cientos de experimentos en producción. Luego que logramos esto, el contraste de datos de uso entre cohortes, por ejemplo, los usuarios por días de la semana y fines de semana, para que la hipótesis de formas de mejorar la experiencia de cada uno.
- La deuda técnica es un problema que afecta negativamente el flujo y el progreso. La deuda técnica reduce la productividad, hace que el código sea frágil y cause errores (bugs) que crean un trabajo no planificado. Nuestro objetivo debe ser el anular nuestra deuda técnica en cada sprint para limitar el impacto negativo a largo plazo.
- Mantener una deuda técnica con una tendencia de bajada comienza con un código de alta calidad. Microsoft a implementado estas prácticas para aumentar la calidad del código a un nivel de desarrollador individual. Después de eso, confían mucho en la automatización de pruebas. Cada equipo tiene el objetivo de reducir la deuda técnica a cero en cada iteración.
- El más mínimo cambio en Desarrollo, impacta a las Operaciones (Seguridad, Pruebas Continuas, Integración Continua, Entrega Continua).
- Producción está en el corazón de nuestra organización de entrega de software. Producción es el trabajo # 1 de cada miembro del equipo sus diferentes papeles, no sólo las operaciones de TI. Hay que hacer un seguimiento continuo al estado del sitio en vivo, solucionar inmediatamente cualquier problema del sitio en vivo e identificar proactivamente los valores atípicos en el rendimiento (performance).
- No se usa ambientes de pre-producción, se despliega directamente a producción en cada iteración. Para esto se debe implementar las prácticas de DevOps que permiten recuperar rápidamente, facilitar el análisis de la causa raíz de los problemas y una arquitectura que falle con gracia (con un impacto mínimo).
- Utilizar una infraestructura flexible que brinda la nube pública, permite mejorar continuamente la arquitectura a través de la refactorización de servicios para que sean independientes y discretos. La infraestructura en la nube proporciona un escalado enfocado a la demanda y hace que sea fácil de soportar el uso constante de los servicios de retroalimentación (feedback) continua.
- La infraestructura en la nube nos permite proveer recursos infinitos bajo demanda, algo que es imposible con la infraestructura local (on-premises) tradicional. Esto nos va permitir implementar muchas innovadoras prácticas de DevOps con un desembolso mínimo de capital.
- El desarrollo de software ha cambiado - las prerrogativas y las prioridades han cambiado y cada organización de entrega de software debe abordar estos cambios para poder sobrevivir. La pregunta no es si te va a golpear - la pregunta es cuándo. ¿Estás listo para DevOps?
- Desarrollo, pruebas, salud… todo de producción; un solo equipo, cliente y Intergrupo, con un vision.
- Demostrar Visual Studio Team Service
- Demostrar desde Visual Studio Enterprise Infraestructura como código Integración Continua