Descargado 23 veces
Subido porKleer Agile Coaching & Training
Dev ops e infraestructura – acompañando nuestro software a producción
Este documento trata sobre DevOps e infraestructura. Explica que DevOps no es solo automatización, sino un cambio cultural que promueve la colaboración entre desarrolladores y operaciones. También describe los beneficios de DevOps como reducción de costos, mayor velocidad e incremento de calidad, a través de la automatización del despliegue de software y la integración continua. Finalmente, resume los principales componentes de DevOps como construcción, pruebas, despliegue y monitoreo.
Más contenido relacionado
Similar a Dev ops e infraestructura – acompañando nuestro software a producción
![Yo soy Dev, yo soy Ops y somos dos en un equipo - [DEISER TOUR Madrid Talks]](https://cdn.slidesharecdn.com/ss_thumbnails/devops-leo-frailedeisertourmadrid-180514074031-thumbnail.jpg?width=640&height=640&fit=bounds)
Dev ops e infraestructura – acompañando nuestro software a producción
- 1. DevOps e Infraestructura Acompañando nuestro software a producción Carlos Peix - carlos.peix@kleer.la - @carlospeix
- 2. DevOps - ¿Quées? ¿Qué NO es? ¿Que no es? ● Bla, bla, bla ● Bla, bla, bla ● Bla, bla, bla ● Bla, bla, bla ● Bla, bla, bla ¿Que es? ● Ble, ble, ble ● Ble, ble, ble ● Ble, ble, ble ● Ble, ble, ble ● Ble, ble, ble
- 3. ¿Por qué? ¿Cómo? ¿Qué? Iniciativa DevOps
- 4. ¿Por qué? ¡¡¡Porquese siente bien!!!
- 5. ¿Por qué? Costo Velocidad (costo) Calidad (costo)
- 6.
- 7.
- 8. Sistema basado endemanda (pull system) ¿Por qué? Testers pueden probar cualquier versión Operaciones instala con un solo click en cualquier ambiente Soporte que puede revisar cualquier versión pasada Área de IT puede dedicarse a otros temas más interesantes
- 9. Repetible, confiable ypredecible ¿Por qué? < Stress < Fragilidad > Velocidad > Flexibilidad < Errores < Time to Market < Lead y Cycle Time
- 10. ¿Cómo? “Si ustedes un arquitecto de torre de marfil, por favor descienda y póngase en contacto con la intersección vital entre software, hardware y los usuarios finales.” Trad. ajustada del libro Release It de Michael Nygard|
- 11. ¿Cómo? “Los desarrolladores deben entregar software listo para producción” Trad. ajustada del libro Continuous Integration De Jez Humble y David Farley
- 12. ¿Cómo? TTM LeadTime Simplicidad SLA Estabilidad Seguridad Oportunidades Soporte al negocio Retorno de inversión Competitividad
- 13. ¿Cómo? Flujo devalor y deployment pipeline Value Stream Deployment pipeline
- 14. ¿Cómo? Flujo devalor ¡Producció n! Desarrollado r Commit Stage Acceptance Stage Release Stage Compile Unit tests Code metrics Integrati on tests Acceptanc e tests Manual tests Stress tests Build server Deployment pipeline
- 15. ¿Cómo? Todo enVCS Proceso repetible Automatizar (casi) todo Si duele, más frecuente Calidad desde el principio Terminado es “en producción” Todos somos responsables Mejora continua
- 16.
- 17. ¿Qué? Construcción •Dependencias, calidad Prueba • UI, integración, unitarias Despliegue • Base de datos, ambiente, configuración Monitoreo • Técnico, negocio
- 18. ¿Qué? Construcción Automatización • Jenkins, Teamcity, etc Dependencias de terceros • Maven, Gems, NuGet Dependencias propias • Nexus, Artifactory
- 19. ¿Qué? Despliegue Basede datos • Liquidbase, Migrator.NET, etc Ambientes • Puppet, Ansible, Vagrant, Docker Configuración • Nagios, Open NMS, Zookeeper • Ant, NAnt, Perl, Bash, Powershell
- 20. ¿Qué? Monitoreo Técnico • Smoke tests • Dependencias Negocio • Indicadores transacciones de negocio • Graphite, Etc.
- 21. ¿Qué? Despliegue completamenteprobado Debe estar automatizado (caso contrario, ¿qué probamos?) Probamos (automatizamos) Cambios en la base de datos Configuración del ambiente Configuración de la aplicación
- 22.
- 23. DevOps - ¿Quées? ¿Qué NO es? ¿Que no es? ¿Que es?
- 24.
- 25.
- 26.
- 27. SAO PAULO MONTEVIDE O BUENOS AIRES BOGOTÁ MÉXICO DF QUITO LIMA COCHABAM BA Estamo s en...
- 28. Carlos Peix carlos.peix@kleer.la @carlospeix