Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Juan Manuel Gonzalez Calleros, profile picture
Uploaded byJuan Manuel Gonzalez Calleros
PPTX, PDF724 views

Una mirada al desarrollo por entregas continuas

El documento explora el concepto de desarrollo por entregas continuas (Continuous Delivery) y su integración con metodologías ágiles como Agile, Lean, Scrum y Kanban, destacando la importancia de la retroalimentación y la automatización en el proceso de desarrollo. Se presentan principios clave y buenas prácticas para la gestión del flujo de trabajo y la implementación de un pipeline de despliegue eficaz. Además, se mencionan desafíos potenciales y la necesidad de ajustar enfoques según el contexto organizacional.

Education◦
Downloaded 23 times
Una mirada al desarrollo por entregas continuas Continuous Delivery Bernadette Martínez Hernández
Sumario ✓ 1 Ingeniería de Software ✓ 2 Agile ✓ 3 Lean ✓ 4 Scrum ✓ 5 Kanban ✓ 6 Continuous Delivery ✓ 7 Peguntas
Ingeniería de Software Desarrollo en cascada
Ingeniería de Software Desarrollo en cascada
Ingeniería de Software Desarrollo en cascada
Agile, Lean, Scrum y Kanban Agile Cuatro valores básicos (manifiesto Agile): 1. Los individuos y sus interacciones por encima de los procesos y las herramientas (COMUNICACION) 2. Entregar software que funciona por encima de hacer la documentación 3. Colaboración con el cliente por encima de la negociación de los contratos 4. Responder al cambio por encima de seguir un plan El desarrollo ágil no es una metodología. Es un término incluyente que describe varias metodologías ágiles.
Agile, Lean, Scrum y Kanban Agile Los doce principios Ágiles son: 1. Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor. 2. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos software frecuentemente, con una periodicidad desde un par de semanas a un par de meses, con preferencia por los periodos más cortos posibles. 4. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto. 5. Construimos proyectos con profesionales motivados. Dándoles el entorno y soporte que necesitan, y confiando en ellos para que realicen el trabajo. 6. El método más eficiente y efectivo de comunicar la información a un equipo de desarrollo y entre los miembros del mismo es la conversación cara a cara.
Agile, Lean, Scrum y Kanban Agile Los doce principios Ágiles son: 7. Software que funciona es la principal medida de progreso. 8. Los procesos ágiles promueven el desarrollo sostenible. Patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida. 9. La atención continua a la excelencia técnica y los buenos diseños mejoran la agilidad. 10. Simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se auto-organizan. 12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo, entonces mejora y ajusta su comportamiento de acuerdo a sus conclusiones.
Agile, Lean, Scrum y Kanban Lean PIENSA EN GRANDE, ACTÚA EN PEQUEÑO, EQUIVÓCATE RÁPIDO; APRENDE CON RAPIDEZ Los principios de desarrollo de software Lean (magro): • Eliminar el desperdicio • Ampliar el aprendizaje • Manejar la incertidumbre tomando decisiones hasta el último momento.(Sin evadir la planeación, sólo enfocarse en la adaptabilidad) • Reaccionar tan rápido como sea posible • Dar poder al equipo (Las personas no son recursos) • Fomentar la integridad (Refactorización y automatización de pruebas) • Tener una visión clara del „todo‟ • Puntos buenos: Enfoque en el „todo‟, autonomía del equipo (decide y ejecuta los procesos que necesita) • Puntos malos: Ignora la necesidad de dividir para analizar en proyectos grandes, posponer las decisiones puede causar problemas.
Agile, Lean, Scrum y Kanban Scrum • Scrum es un marco de trabajo para el desarrollo de software (herramienta que aplica el principio de divide y vencerás) • Roles, sprint, el equipo crea un incremento de software potencialmente entregable, backlog, reuniones planeadas. • Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. • Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.
Agile, Lean, Scrum y Kanban Scrum • Puntos buenos: Metas pequeñas y fáciles de cuantificar, una reunión mínima diaria, impulsa la formación de equipos. • Puntos malos: Inflexible (grupos multitareas), demasiadas reuniones de supervisión, no funciona bien en equipos inexpertos y/o no familiarizados con Agile y/o con problemas internos de confianza, requiere un excelente líder, se enfoca demasiado en lo que los usuarios quieren, la productividad y las metas inmediatas, ignora especializaciones (causa de stress), minimiza en exceso la importancia de la documentación, las entregas terminales a usuarios y los bloqueos.
Agile, Lean, Scrum y Kanban Scrum
Agile, Lean, Scrum y Kanban Scrum
Agile, Lean, Scrum y Kanban Kanban • Kanban es una herramienta visual de control y manejo de proyectos y procesos que ayuda a administrar efectivamente el flujo de trabajo durante una iteración. Kanban es una herramienta, y como cualquier herramienta, su propósito es resolver un problema... Lean es una filosofía. • Kanban Standups: o ¿Tenemos cuellos de botella (cola con exceso de trabajo)? o ¿Tenemos algo que bloquea la continuidad del proceso? o ¿Estamos manteniendo nuestro límite de trabajos en progreso? o ¿Tenemos las prioridades claras? o ¿Qué se hizo ayer, qué hay que hacer hoy? • Tablero o pizarrón Kanban se actualiza por lo menos una vez al día. El encargado de cada reunión enumera trabajo, NO gente. Reglas de control de calidad para el movimiento de tarjetas • Principio de mejora continua. Preguntar ¿POR QUÉ? hasta que duela • Gente con diferentes habilidades tiene que trabajar en equipo para terminar las metas. • No desarrollar features que nadie quiere en este momento. No escribir más especificaciones de las que se pueda desarrollar. No hacer pruebas en más software del que se planee instalar. Descomposición de ideas en features redituables.
Agile, Lean, Scrum y Kanban Kanban • Puntos buenos: Los mismos de Scrum además de ser más flexible (no hay iteraciones!) y proporcionar una manera de controlar los bloqueos ,la sobrecarga de trabajo y no ignorar la documentación ya que se vuelve parte del proceso. Apunta hacia el desarrollo por entregas continuas. • Puntos malos: Se enfoca demasiado a satisfacer lo que los clientes quieren, la productividad y las metas inmediatas, ignorando especializaciones (causa de stress) además de la estimación y la planeación, el principio de mejora continua puede cansar o presionar en exceso, requiere mucha disciplina.
Agile, Lean, Scrum y Kanban Kanban
Agile, Lean, Scrum y Kanban No hay herramientas ni filosofías perfectas, entonces lo mejor es combinar y ajustar. Scrumban con un toque de sal, limón y chile
Continuous Delivery Desarrollo por entregas continuas El flujo de trabajo reforzado por Kanban apunta a que un punto ignorado en el que nos debemos enfocar es el perfeccionamiento del movimiento de tareas en el flujo, independientemente de qué tareas se estén procesando. Por ejemplo; al usar Kanban se considera una falla el regresar tareas a colas previas. Cuando la causa de esa falla, está en el proceso, debemos eliminarla. ¿En tu organización, cuánto tiempo pasa para que una línea de código llegue a producción? ¿Cuánta confianza tienes en tu producto?
Continuous Delivery Desarrollo por entregas continuas • Continuous Delivery significa que un producto es considerado terminado desde el día uno del proyecto y puede ser dado a los clientes, incluso si no todas las características y features han sido implementados. • Da prioridad a la retroalimentación para evitar: – Retrasos en la compilación , documentación y construcción de instaladores – Esperas largas de ejecutables adecuados par a efectuar tests – Reportes de bugs y problemas semanas después de haber concluido un proyecto – Identificación de problemas estructurales justo cuando el proyecto está a punto de concluir • Jez Humble y David Farley Continuous Delivery (Addison Wesley, 2010) • ThoughtWorks lo usa y provee una herramienta gratuita (Go). Libro se usa como texto en Oxford en la materia de Prácticas de Ingeniería Ágil.
Continuous Delivery Implanta Desarrolla Define
Continuous Delivery Poner en acción las mejores prácticas en tres áreas principales dentro de una organización Procesos Personas Herramientas
Continuous Delivery Principios • Implantación (deployment) repetible y confiable • Repetición de procesos difíciles hasta que sean entendidos, simplificados y/o automatizados • Automatizar TODO • Versionar TODO (junto con la compilación y corrida automática de tests compone Continuous Integration) • Terminado = Considerado en ambiente de producción (aunque no siempre se haga público para que pueda ser instalado como sucede en el paradigma de Continuous Deployment) • TODOS son responsables de proceso de emisión del software (release) • Calidad desde la primera emisión del software. • Mejora continua.
Continuous Delivery Prácticas • Compilar el producto una sola vez • Usar el mismo mecanismo de implantación para todos los ambientes • Correr test preliminares (no exhaustivos) • Cualquier falla hace que la línea de producción se detenga. • Desarrollo en la Tubería de Montaje – Equipo de desarrollo y entrega → Control de versiones → Tests de compilación y unit tests → Tests de aceptación automatizados → Tests de aceptación del usuario → Release – Esto no es nuevo, es simple y llano método científico (Planteamiento del problema, formulación de la hipótesis, experimentación, ley)
Continuous Delivery La Tubería de Montaje (Deployment Pipeline) • Cada que se salva código en el sistema de control de versiones se activa una corrida de la tubería y el software se compila, se corren los tests y si todos ellos son satisfechos el software puede publicarse. • Ventajas: – Método probado que permite crear, verificar y montar sistemas complejos de gran calidad a un costo y riesgo menor. Confianza en el producto (test, test, test) – Evitar el “en mi maquina funciona” vía tests en entornos parecidos a los de producción (VM, Plataform As A Service [cloud]) o Test de aceptación automáticos o Test de aceptación de los usuarios o Test de capacidad – Recibir noticia inmediata de errores y regresiones además de proveer una aplicación terminada tan pronto y tan frecuentemente como sea posible – Incrementa la visibilidad del nivel de terminación del producto ya que hay retroalimentación temprana cada vez que hay una nueva versión. – Facilita el montaje de versiones especificas
Continuous Delivery Problemas que pueden ocurrir • Paralelización insuficiente • Mal diseño de la tubería de tal suerte que ciertos tests no se pueden saltar o reordenar, no se le puede dar prioridad a ciertas versiones o el proceso es muy lento • Falta de herramientas que permitan alternar entre ambientes “en vivo” y “en proceso de testing” (staging)
Continuous Delivery Conceptos importantes • Adecuado para Kanban • Principios clave para la Tubería: – Construir ejecutables una sola vez, almacenarlos en el repositorio de productos y mandarlos a la Tubería – Promover únicamente las versiones que pasen todos los unit tests y los tests de aceptación – Los ambientes de desarrollo, corrida de tests (automatizados y de aceptación) y staging deben ser lo más similares posible al ambiente de producción. • Automatizar TODO: compilación, configuración y tests. Los seres humanos tienden a cometer errores en procesos repetitivos. • Versionar TODO, incluida la configuración del sistema operativo, infraestructura y equipo de red. Para el versionado de la Base de Datos – Versionar la base de datos y usar una herramienta para manejar los cambios – Compatibilidad hacia adelante y hacia atrás con respecto a la base de datos – Cambios aditivos solamente – Tests adecuados que creen solo los datos necesarios – Evitar integraciones entre aplicaciones vía base de datos • Continuous Integration (SVN, GIT) • Continuous Deployment (Cloud Foundry) • Switch para features • Staging
Continuous Delivery Más información • Capítulo 5 sobre la Tubería: http://ptgmedia.pearsoncmg.com/images/9780321601919/samplepage s/0321601912.pdf • http://www.infoq.com/presentations/Continuous-Delivery • http://www.infoq.com/interviews/jez-humble-agile2011 • http://www.infoq.com/articles/humble-farley-continuous-delivery • http://continuousdelivery.com/ • http://continuous-delivery.thoughtworks.com/ • http://www.slideshare.net/jmcgarr/continuous-delivery-8341276 • http://www.davefarley.net/
Development Production Test Planning Development Cycle Done and ready for deployment. QA
Development Development cycle: TDD Write a test or a set of tests according to the Code passes specification and all the tests. check they fail. Some tests fail or some code can be improved. Fix code so all previous tests pass or improve the quality of the code or its efficiency.
Development Production Why: 1. If a task goes back into the cycle is Scrumban because the requirements changed, not because somebody understood them wrong, didn‟t have them at all, or unexpected things got broken. TDD 2. TDD + Scrumban enforces discipline and quality. 3. Eventually, iteration and retrospectives blend in, creating an atmosphere of continuous production.
Altienban All items To Do Ideas, breakdown features, tasks ready for Definition development Prioritized backlog, test planning, development Development cycle, QA, done, extra, urgent Waiting for installer, test installer, needs documentation Deployment Waste
Altienban Kanban
Altienban Details • If there is nothing to take on my usual queue and I cannot start or continue more work in other queues without passing the WIP limit of any queue maybe it is time for a standup. Board may be inaccurate or I can do something to unblock a currently blocked item but I may not know about it. The following guidelines can be useful to help in this situation: – Can you help progress an existing Kanban? Work on that. – Don‟t have the right skills? Find the bottleneck and work to release it. – Don‟t have the right skills? Pull in work from the queue. – Can‟t start anything in the queue? Is there any lower priority to start investigating? – There is nothing lower priority? Find other interesting work. • Stop the Line for special cause problems. Retrospectives with Operations Reviews for common cause problems and reassess the whole value stream • If requirements are not complete at the definition state, it is OK, we only need to get as much info as possible at that point. Be creative to do that (e.g. drawings and simulations). Requirements may change later, but at least we avoid waste on things that could have initially avoided. • Development cycle requires developer to run the feature test and all the relevant tests. QA does the wrap-up of the tests and checks nothing is missing before declaring it done. M may do the more complex or manual tests. Possibly check their interaction with other finished work. • Minimal requirement is that the code is decent enough for someone to take over. If not perfect at least documented or with references of who to ask. • Test planning: write or get a problem or task specification. Write a test, check if the test fails. Write tests easy to maintain. Initial tests should not break the encapsulation! • Documentation should be easy to draw from cases if all examples and explanations are there.
Altienban En este momento…. • Mejora de la integración continua por medio de una serie de reglas y monitoreo además del uso de GIT como método suplementario de integración continua. • Manufactura de la documentación ha mejorado considerablemente gracias a que los casos son especificados de mejor manera. • Parte de los tests están automatizados (número de unit tests se ha incrementado) y cada que se salva código en el sistema de control de versiones, se corren test básicos (continuous integration) • La compilación y construcción de los programas de instalación ha sido automatizada en su mayoría, aunque aún requiere una persona a cargo que supervise y dos o tres pasos manuales. • Bases de datos están versionadas y con un método bastante seguro y establecido de adición de cambios. • Reducido el tiempo de entrega de producto de tres-seis meses a un mes si es necesario, teniendo varios RCs entre periodo y periodo.
Altienban Mayores retos • Cambio de actitud – Garantizar tiempo para efectuar las mejoras – Continuidad – Disciplina y participación de todas las esferas de la organización – Importancia de la implementación y ejecución de tests • Lidiar con los contras de CD – Dificultad de implementar al 100% en una sola iteración, lento proceso de mejoras continuas que puede exasperar – Implementación de la tubería completa demanda muchísima dedicación y tiempo que es difícil de conseguir en una compañía de tamaño pequeño. • Planes futuros: – Automatización completa de la compilación, construcción de programas de instalación e implantación – Reducción del ciclo de producción y mejora del diseño de la Tubería de Montaje (permitir staging) – Implantación automática en maquinas virtuales que ejecuten series de tests automáticamente – Mejora de tests: más DSLs, mejor TDD y usar Selenium además de VM para la instalación y corrida automática de tests. – Herramienta de manejo y tests automáticos para las bases de datos usadas por el producto.
¡Gracias! ¿Preguntas?