DevOps - Más allá del botón derecho > publicar | 4Sessions Feb17
•Download as PPTX, PDF•
0 likes•1,046 views
![[T]echdencias](https://cdn.slidesharecdn.com/profile-photo-techdencias-48x48.jpg?cb=1560867556)
Un día cualquiera, has terminado de resolver un bug. Haces fetch de los cambios en el repositorio central. Hay cambios. Haces pull. Conflictos... mierda. Los resuelves y compilas. Pasas los test. 6 minutos y 332 tests después. Tus compañeros de QA están esperando a que despliegues los cambios en desarrollo desde hace 2 horas. Todo bien, haces commit. Sincronizas con el repositorio central. Despliegas el proyecto en destino. En QA te avisan de que faltan funcionalidades. Te desesperas: Alguien ha desplegado antes que tú, con código que no está protegido. Caos. Vuelta a empezar. Detección temprana de errores, automatización de procesos de deploy, compilaciones planificadas, menor gap entre desarrollo y calidad, separación y automatización de entornos... Éstas son algunas de las herramientas que se utilizan en DevOps. Tras la increíble charla de Carmen y Nacho sobre como desplegar nuestros proyectos web en Azure con dos simples pasos, en esta sesión hemos visto cómo ir un paso más allá.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to DevOps - Más allá del botón derecho > publicar | 4Sessions Feb17
Similar to DevOps - Más allá del botón derecho > publicar | 4Sessions Feb17 (20)
More from [T]echdencias
More from [T]echdencias (20)
Recently uploaded
Recently uploaded (20)
DevOps - Más allá del botón derecho > publicar | 4Sessions Feb17
- 1. DevOps Más allá de “Botón derecho > Publicar” #FourSessions Ángel García
- 3. DevOps
- 4. DevOps
- 5. DevOps
- 6. DevOps
- 8. Continuous Integration ¿Qué es? Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. https://www.thoughtworks.com/es/continuous-integration
- 9. Continuous Delivery ¿Qué es? Through reliable, low-risk releases, Continuous Delivery makes it possible to continuously adapt software in line with user feedback, shifts in the market and changes to business strategy. Test, support, development and operations work together as one delivery team to automate and streamline the build, test and release process https://www.thoughtworks.com/continuous-delivery
- 10. I choose you!
- 11. • Git • GitFlow ¿Por qué?
- 12. ¿Por qué? • Visual Studio Team Services • Integración out-of-the-box con Git • Integración out-of-the-box con Azure • SCV, Build, Release, Deploy management
- 13. • Azure • WebApps • Máquinas virtuales • Bases de datos • Infraestructura • Storage • … • Y porque es de Microsoft ¿Por qué?
- 14. Visual Studio Dev Essentials https://www.visualstudio.com/es/dev-essentials/
- 15. Continuous Integration Estrategias CI - Build • Planificada (… y nightlies) • Inmediata • Gated Commit / Check in • Manual
- 16. • La estrategia de branching determina qué ramas deben ser compiladas mediante una build automática. • En GitFlow, tiene sentido tener al menos dos entornos automatizados: master y develop Estrategia de branching - GitFlow Continuous Integration
- 17. DEMO
- 18. Continuous Delivery Deploy • WebApp • Nuget • Store • …
- 19. Continuous Delivery Estrategias CD - Release • Planificada (… y nightlies) • Inmediata • Manual
- 20. DEMO
- 21. DevOps Code Build Test Release Deploy Resumen
- 22. DevOps Code Build Test Release Deploy Resumen
- 23. DevOps Code Build Test Release Deploy Resumen
- 25. GRACIAS
Editor's Notes
- ¿DevOps? ¿Alguien sabe que significa esa palabra? ¿A qué me refiero? (click) ¿Quizá a un perfil profesional? (click) ¿Quizá a un concepto muy hipster? (click) No, en realidad, DevOps se refiere a un conjunto de principios, herramientas y procesos. El nombre de DevOps en realidad es la contracción de los términos Development y Operations. Pretende definir...
- ¿DevOps? ¿Alguien sabe que significa esa palabra? ¿A qué me refiero? (click) ¿Quizá a un perfil profesional? (click) ¿Quizá a un concepto muy hipster? (click) No, en realidad, DevOps se refiere a un conjunto de principios, herramientas y procesos. El nombre de DevOps en realidad es la contracción de los términos Development y Operations. Pretende definir...
- ¿DevOps? ¿Alguien sabe que significa esa palabra? ¿A qué me refiero? (click) ¿Quizá a un perfil profesional? (click) ¿Quizá a un concepto muy hipster? (click) No, en realidad, DevOps se refiere a un conjunto de principios, herramientas y procesos. El nombre de DevOps en realidad es la contracción de los términos Development y Operations. Pretende definir...
- ¿DevOps? ¿Alguien sabe que significa esa palabra? ¿A qué me refiero? (click) ¿Quizá a un perfil profesional? (click) ¿Quizá a un concepto muy hipster? (click) No, en realidad, DevOps se refiere a un conjunto de principios, herramientas y procesos. El nombre de DevOps en realidad es la contracción de los términos Development y Operations. Pretende definir...
- … un cambio de filosofía a nivel empresarial. Desde el punto de vista de las herramientas que dicha filosofía aporta, podemos clasificar las diferentes etapas de un proceso DevOps en: Planificación Codificación Construcción Pruebas Entrega Despliegue Operación Monitorización En esta charla no quiero explicaros cada una de las etapas de un proceso DevOps, sino que el objetivo es centrarme en aquello que creo que puede aportaros más valor como desarrolladores. Me refiero a los conceptos de Continuous integration y Continuous delivery.
- ¿Qué significa Continuous integration? Me gusta especialmente esta descripción que encontré en la web de Thoughtworks. La integración continua es una práctica de desarrollo que requiere que los desarrolladores integren su código en un repositorio compartido varias veces al día. Cada check-in es verificado por una build automática, permitiendo de esta forma a los equipos detector los problemas de forma temprana.
- Por otro lado, Continuous Delivery define el proceso mediante el que nuestro producto va a desplegarse y como va a ser explotado una vez desplegado. También he escogido la definición que da Thoughtworks para el concepto. Mediante entregas confiables de bajo riesgo, Continuous Delivery permite adaptar el software mucho más deprisa en función del feedback del usuario final, ante cambios de mercado o ante cambios de estrategia de negocio. Los departamentos de test, Soporte, desarrollo y operaciones trabajan juntos como un único equipo. Que chulo suena todo, ¿verdad?
- Para implementar CI + CD, podéis escoger muchísimas herramientas que están ahí y que permiten desde el build automatizado de código hasta el despliegue o monitorización de soluciones de todo tipo. En mi caso, he escogido como escenario de CI + CD: Git Visual Studio Team Services Microsoft Azure
- Podría estar horas hablando de por qué Git es mejor que TFS… pero no. Básicamente he escogido Git para la demo porque creo que actualmente es el Sistema de Control de Versiones que la mayor parte del mundo mundial NO corporativo está utilizando. Aunque en su momento la mayor parte del mundo mundial corporativo usaba Visual Source Safe… en fin. Como flow de trabajo, he escogido GitFlow. Esto también da para una charla, pero creo que la mayoría de vosotros habrá oído hablar de ello. No es más que una convención, una estrategia de branching, que asocia de forma semántica cada rama con un estado del código: Master para producción Develop para vNext Feature para la implementación de nuevas funcionalidades Release para la integración (o merge) de desarrollo a producción y Hotfix… bueno… nadie quiere usar Hotfix, pero a veces es necesario.
- En el caso de Visual Studio Team Services, porque básicamente tiene todo lo que necesito en un solo lugar y además, es gratis. Todo lo que necesito es: Integración con Git (Jenkins o Team City también lo tienen) Integración con Azure (Jenkins o Team City lo permiten) SCV, Build, Release, Deploy, Management… que para tenerlo todo en una sola herramienta ya tienes que andar combinando un Jira, con un Github, con un Team City, con un… demasiados con un.
- ¿Y Azure? Bueno, Azure te da Webapps, máquinas virtuales, bases de datos, infraestructura de red, directorio activo, cloud storage… Bueno, y también porque es de Microsoft y con el programa Visual Studio Dev Essentials os regalan 25$ al mes durante un año para que trasteéis.
- Entráis aquí, en ésta URL, os registráis… ponéis la tarjeta de crédito, que os puedo asegurar que no os van a cobrar (si a alguno os cobran no vengáis a reclamar tampoco luego…), y a disfrutar de las ventajas que ofrece.
- Retomando un poco el tema de CI, quiero hablaros de los procesos de build. Una build automatizada usando Continuous integration se inicia a través de lo que se conoce como Triggers. Entre muchos de los que, en mi escenario, ofrece VSTS, existen tres muy diferenciados que creo interesante resaltar aquí. Las builds planificadas, son aquellas builds que se ejecutarán pasado un intervalo de tiempo X, o a tal hora por la noche, o los 29 de febrero a las tres de la tarde. Las builds inmediatas son aquellas que se lanzan en cada commit o checkin que hagamos a la rama configurada de nuestro repositorio para dicha build. Esto significa que cada vez que alguien suba algo a, por ejemplo, la rama master, se lanzará una build automática para generar la versión resultante tras los cambios realizados. Se acabaron los “pues en mi máquina compila”, porque el equipo siempre va a trabajar con una compilación de referencia, que es la que tenga el servidor de build. Por último, un tanto olvidadas, pero que dan mucho juego normalmente, son las gated builds. Las gated builds se generan por un gated commit, que no es más que un commit al repositorio que, de manera previa a su inclusión en el repositorio compartido como código consolidado, se le hace la verificación de compilación, pruebas…. De todos y cada uno de los pasos que nuestra build automática tenga definidos, de manera que no aceptemos ese commit si la build no es correcta. Este tipo de gated commits es el siguiente nivel de CI, ya que no sólo detectas los errores pronto… sino que los detectas antes incluso de que se guarden en el servidor. Ni comento la versión manual… acaso alguno de nosotros va a estar ahí, cual monete, encolando builds cada vez que un compañero le avise de que ha subido cambios al repositorio?
- Algo importante también es tener claro qué queremos que sea código a integrar. Para un escenario como el mío, en el que mi estrategia de branching es la que marca GitFlow, lo habitual es tener dos builds automáticas: master y develop. Así pues, si integro features nuevas a mi rama de desarrollo, o si genero un hotfix súper urgente para el entorno de producción, la build se generará de forma automática al hacer merge en las ramas principales del repositorio.
- Enseñar la aplicación PokeTechs Demostrar que funciona, pero que tiene un bug. Arreglarlo, pero no sincronizar. Explicar cómo se configura una build. Añadir build Elegir Visual Studio Escoger la rama apropiada (master) y seleccionar Continuous integration. En la lista de steps, el Copy Files no hace falta. Eliminarlo. En caso de fallo, el step build requiere de estos parámetros: /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\“ No lanzar build. El repositorio aún no tiene código en master. Explicar cómo activar un gated-commit. Acceder a Code / Settings / Version Control Seleccionar la rama master Branch Policies Marcar las opciones apropiadas.
- Hasta ahora no hemos visto que funcione, pero ya llegamos a eso. Continuous delivery en este caso nos permite desplegar una build correcta en un entorno previamente creado, o en un recurso de red, o en un repositorio nuget, o en la store de turno de Android, iOS o… Windows Phone. En el escenario que hemos visto, desplegaremos una WebApp en azure, que además es una de las más sencillas de configurar.
- No quiero pasar a la segunda parte de la demo sin hablar de estrategias CD también. Aunque no os sorprenderá que la lista sea parecida a la de estrategias CI. En realidad, dentro del continuous delivery, es habitual que sea una build la que genere, mediante trigger, una reléase del código compilado. Obviamente la herramienta, en este caso VSTS, te permite lanzar una entrega de forma manual… pero perdería un poco el sentido la palabra Continuous… a menos que alguien esté continuamente lanzando releases a mano.
- Ya acabamos… vamos a calmarnoh… que es sábado y hay que irse a comer. Explicar cómo se configura una release. Añadir reléase (desde el menú izquierdo) Seleccionar el Source Apropiado (Prod) Marcar Continuous deployment. Configurar el deploy. Definir la suscripción de Azure Definir la instancia de Azure Desplegar las opciones disponibles, sólo haciendo mención a que hay muchísimas propiedades configurables y que en cada versión nueva salen más. Guardar y dejar el resto por defecto. Sincronizar el código con el repositorio. Mostrar la build automática. Mostrar la reléase automática. Demostrar que el entorno de producción se ha levantado. Enseñar Azure para demostrar que el proceso de deploy también se puede visualizar desde allí.
- Y hasta aquí… Hemos visto una pequeña introducción a parte del ciclo de vida y la toolchain de DevOps. Desde cómo almacenamos y compartimos nuestro código fuente mediante Git, cómo compilamos, testeamos y generamos versiones en VSTS y como acabamos deployando el software final en Azure. ¿Creéis que estáis preparados para implementar las prácticas DevOps?
- Y hasta aquí… Hemos visto una pequeña introducción a parte del ciclo de vida y la toolchain de DevOps. Desde cómo almacenamos y compartimos nuestro código fuente mediante Git, cómo compilamos, testeamos y generamos versiones en VSTS y como acabamos deployando el software final en Azure. ¿Creéis que estáis preparados para implementar las prácticas DevOps?
- Y hasta aquí… Hemos visto una pequeña introducción a parte del ciclo de vida y la toolchain de DevOps. Desde cómo almacenamos y compartimos nuestro código fuente mediante Git, cómo compilamos, testeamos y generamos versiones en VSTS y como acabamos deployando el software final en Azure. ¿Creéis que estáis preparados para implementar las prácticas DevOps?