WIXLIB

ProblemasProblemas tı́picos (2)Desarrollo hace un producto de baja calidad, lo mı́nimo paraser aceptadoEl trabajo ya está hecho. El diagrama de Gantt está cumplido.Los problemas posteriores no importan, son cosa demantenimiento, de otro contrato, de otra subcontrata, de otropresupuesto.Consumir más recursos (tiempo, esfuerzo) para entregar unproducto de más calidad, no reportará beneficios al equipo dedesarrolloGSyC - 2018DevOps27

ProblemasProblemas tı́picos (3)Problema contrario al anterior: Desarrollo anancástico(demasiado perfeccionista)El equipo de desarrollo prepara un un software con cambiosradicales (nuevo lenguajes, nuevas librerı́as). O preparado paraeventualidades poco probables.Todo lo contrario al pequeño cambio incremental. No tiene encuenta las implicaciones para operaciones. Dispara los costesy/o los plazos, peligrando la viabilidad de la empresa. Aoperaciones o al mercado no llegan las soluciones adecuadasporque la solución óptima no está disponibleGSyC - 2018DevOps28

ProblemasProblemas tı́picos (4)Para intentar evitar los problemas anteriores, se mejora laespecificación de los deliverables (entregables) que unosproporcionan a otrosNegociaciones duras, criterios muy rı́gidos, contratoscomplicados, especificaciones a la defensiva. Lo fundamentales, en caso de problema, dejar claro quién tiene la culpaEsto aumenta los trámites, la preparación y la frecuencia de lasentregasAumenta la distancia entre los equiposGSyC - 2018DevOps29

ProblemasProblemas tı́picos (5)Cultura del héroe (rock star, ninja, crack)Programador individualista. Con frecuencia hace software conerrores y no documentado. Aparentemente es muy valiosoporque solo él sabe arreglar esos erroresPlanificación rı́gidaInicialmente se prepara un diagrama de Gantt. Luego todo sefuerza para que encaje en el diagramaGSyC - 2018DevOps30

Aspectos humanosValores a promoverEquipos motivados y productivosCompromiso con objetivos y valores comunesRespeto al otroColaboración bienintencionada entre las partes/las empresasAceptación de un cierto ratio de errores como inevitables, sinbuscar culpablesTodo estoTiene ventajas evidentesEs difı́cil de conseguirGSyC - 2018DevOps31

Aspectos humanosMotivación de equiposSegún Poppendieck, la motivación se puede conseguir con:Sensación de pertenenciaConfianza en una cierta tolerancia a los erroresConfianza en la capacidad propia y del resto del equipoCelebración conjunta de los progresosTeniendo en cuenta que no todo el mundo sale de copas ojuega al PaintballGSyC - 2018DevOps32

Aspectos humanosTrabajo en equipo productivoDefinir objetivos, métodos, pasos, plazos temporales. yreajustarlo cuando sea necesarioEvitar la microgestión. Que los gestores digan qué hacer, perosin demasiados detalles del cómo. El equipo se auto-organizaEsto suele ser más eficienteHace al equipo sentirse más valoradoGSyC - 2018DevOps33

Aspectos humanosHacer pequeños experimentos. Fallar a menudo pero pronto ycon pequeñas cosasDe vez en cuando (una vez al dı́a, a la semana.) reservar unrato para alguien de operaciones se siente con alguien dedesarrolloEvitar el presentismo laboral. Respetar el equilibrio entre eltrabajo y la vida personal. No esperar que los empleadoshagan jornadas maratonianas en la oficina y que luegocontesten al correo a cualquier horaGSyC - 2018DevOps34

Aspectos humanosComunicación efectivaQue los individuos y equipos:Comprendan las circustancias y dificultades de los demásBusquen influenciar en otros de forma positiva.No porque te lo mando o me debes una, sino porque esto eslo mejor para todosReconozcan el trabajo ajeno. Hacerlo en público es muchomás efectivo. Y si hay que hacer algún reproche, con muchamano izquierda y en privadoGSyC - 2018DevOps35

Aspectos humanosReuniones de calidadTodos los convocados llegan puntuales. La reunión acabapuntualmenteMeta-decisiones claras. Ya sea por jerarquı́a, por votación, oidealmente, por consensoLos participantes hablan de uno en unoLo que solo afecta a unos pocos, no se trata en el tiempo detodos.Sin olvidar lasDiscusiones retrospectivas. Reuniones con periodicidadpredeterminada para tratar las etapas superadas, paraanalizarlas y extraer conclusiones.Reuniones post morten. Similares a las retrospectivas, peroprovocadas por un problema concreto. Siempre es necesariotrabajar de forma constructiva sin echar la culpa a nadie, peroen estos casos, mas que nunca.GSyC - 2018DevOps36

Aspectos técnicosAutomatizaciónLa automatización es una técnica fundamental en DevOpsTareas que se pueden automatizar:Construcción (compilación)PruebasDespliegue (puesta en producción)Configuración en los distintos entornosMonitorizaciónControl de incidenciasUltimamente se ha introducido el término orquestar:AutomatizarUsar herramientas (scripts o similares) que permitan realizaruna tarea sin intervención de una personaOrquestarCoordinar diversas automatizaciones de tareas individuales,para que formen procesos / flujos de trabajoGSyC - 2018DevOps37

Aspectos técnicosAutomatizar (incluyendo orquestar) es, en general, positivo. Conalgunas salvedadesDebemos asegurarnos de que merezca la pena. Que el esfuerzonecesario para preparar y mantener la automatización, seamenor que el esfuerzo de realizar las tareas a mano.Paradoja del exceso de automatizaciónInevitablemente, habrá ocasiones en que el sistema requieraintervención humana (errores, cambios no previstos.).Cuánto más automatizado esté el sistema:Más complejos serán estos cambios, más especializadotendrá que ser el personalMenos especializado será el personal del dı́a a dı́a.Como esto lo puede llevar cualquiera, el resultado es que loacaba llevando cualquieraGSyC - 2018DevOps38

Aspectos técnicosTécnicas de despliegue (1)Despliegue frecuenteUn cambio grande puede ser muy drástico. Por el contrario, eldespliegue frecuente pone en producción pequeños cambios,de forma continuaEsto familiariza a todo el equipo con el proceso de introducirnovedadesLos cambios menores implican problemas potenciales menoresHay técnicas más avanzadas (integración continua, entregacontinua, despliegue continuo). Pero realizar al menosdespliegue frecuente es prácticamente imprescindible dentro dela filosofı́a DevOpsGSyC - 2018DevOps39

Aspectos técnicosTécnicas de despliegue (2)Conmutación de funcionesEjemplo: Ponemos en producción funcionalidad nueva. Pero sifalla y decidimos desactivarla, se puede hacer con unconmutador sencillo desde el código. Sin necesidad de volver adesplegar el código viejoLos contenedores pueden hacer innecesaria esta técnicaDark LaunchingLas nuevas versiones se aplican solo a unos pocos usuariosEsto facilita la corrección de problemas y limita los problemaspotencialesPueden ser los empleados, pueden ser voluntarios, pueden serusuarios que hemos detectado como avanzados o pueden seraleatoriosGSyC - 2018DevOps40

Aspectos técnicosTécnicas de despliegue (3)Blue Green DeploymentLa versión nueva y la versión anterior se preparan para quefuncionen en paraleloPara conmutar de la versión azul a la versión verde no hay quecambiar el código, solo el router/el balanceador de carga oalgún fichero de configuraciónGSyC - 2018DevOps41

Aspectos técnicosIntegración, entrega y despliegue continuoLas siguiente técnicas son habituales en DevOps, aunqueNo son imprescindibles para hacer DevOpsImplementarlas no significa estar haciendo DevOpsEn cualquier entorno de desarrollo moderno de cierto tamaño, hayvarios desarrolladores, utilizando un sistema de control deversiones. Cada uno tiene su copia de trabajo del software, que concierta periodicidad, integra en el repositorio principalContinuous Integration (CI)Realizar esta integración muy a menudo. Tı́picamente variasveces al dı́aGSyC - 2018DevOps42

Aspectos técnicosContinuous Delivery (CD)No solamente hacer Continuous Integration, sino dar un pasomás allá. Además de integrar el código, asegurarse de queestá listo para ponerse en producción muy a menudo. Esto es,pasar los controles de calidad y automatizar la puesta enproducción. Tal vez no tan a menudo como la CI, pero sı́ muya menudo. P.e. una vez al dı́a.Continuous DeploymentNo solo hacer Continuous Delivery, sino dar un paso más allá.Además de asegurarse de que el código tiene calidad comopara ponerse en producción, ponerlo realmente en producciónGSyC - 2018DevOps43

HerramientasHerramientasLas siguientes herramientas son habituales cuando se siguen losprincipios DevOpsContenedores Dockerhttps://gsyc.urjc.es/ mortuno/lagrs/02-virtualizacion I.pdfhttps://gsyc.urjc.es/ mortuno/lagrs/02-virtualizacion III.pdfAnsibleJenkinsVagranthttps://gsyc.urjc.es/ mortuno/lagrs/vagrant.pdfGSyC - 2018DevOps44

HerramientasJenkinshttps://jenkins.ioJenkins es una herramienta para implementar Integración Continua(C.I.)Aparece en el año 2011. Es software libre, muy popularAplicación basada en webGSyC - 2018DevOps45

HerramientasVa un paso más allá de herramientas como Maven, queconstruyen el fuente pero no hacen C.I.Su entorno nativo es Java, pero tiene plugins para distintoslenguajes, herramientas de control de versiones, devirtualización, de testing, de comunicación con el personal, etcLa unidad principal es el build: el conjunto de pasos paradesplegar una aplicación softwareUn build se pueden disparar manualmente, por un commit, ocon planificación periódica similar a cronUn build se organiza en pipelines, cada una compuesta de stepsGSyC - 2018DevOps46

HerramientasJenkinsfile (Declarative Pipeline)pipeline {agent anystages {stage(’Build’) {steps {echo ’Building’}}stage(’Test’) {steps {echo ’Testing’}}stage(’Deploy’) {steps {echo ’Deploying’}}}}GSyC - 2018DevOps47

HerramientasAnsiblehttps://www.ansible.comAnsible es un software de gestión de configuracionesCreado por Michael DeHaan en 2012. En la actualidadpertenece a RedHatsoftware libre, muy popularArquitectura cliente servidorGSyC - 2018DevOps48

HerramientasLos clientes se denominan nodos. Son las máquinascontroladas. Solo necesitan un servidor de ssh, por tantosoporta cualquier Linux, Unix, macOS. También funcionasobre la PowerShell de Microsoft WindowsEl servidor se denomina controlling machine. Es la máquinaque administra y controla los nodos. El soporte nativo es paraLinux. Hay versiones para macOS y otras plataformas,prácticamente cualquiera donde funcione python y pipGSyC - 2018DevOps49

HerramientasAnsible sigue un paradigmapush: el controlador envı́a lasórdenesPushPullOtras herramientas similarescomo puppet tienen unenfoque pull, que resulta máscomplejo: la máquinaadministrada corre un demonioque, periódicamente, se traelas órdenesIconos: www.vecteezy.comGSyC - 2018DevOps50

HerramientasConceptos principales en AnsibleInventoryFichero que contiene el listado de las máquinas administradas,con su nombre y/o dirección IP, puerto, claves ssh, etcPlaybookEs una especie de howto automatizable, un script de propósitoespecı́fica (configurar una máquina), de alto nivel y fácilmentelegible por humanosPalabra inglesa que significa libro de juego, libro de tácticas olibro de reglasEscrito en formato YAML, similar a JSON pero con sintaxispensada para que sea cómodo para las personas. Filosofı́aanáloga al formato markdown, pero para datos, no para textoRoleEstructura de nivel superior al playbook. Permite hacerplantillas de playbooks. Está formado por playbooks, ficheros,dependencias entre playbooks.GSyC - 2018DevOps51

HerramientasAnsible GalaxyRepositorio centralizado de roles. Facilita la instalación desoftware. Equivalente a tener un repositorio de libros deinstrucciones, pero que se autoejecutanhttps://galaxy.ansible.comGSyC - 2018DevOps52

Herramientas# Configurar un servidor web básico con nginx- name: Configurar servidor web con nginxhosts: miServidor01sudo: yestasks:- name: install nginxapt: name nginx update cache yes- name: copy nginx conf filecopy: src files/nginx.conf dest /etc/nginx/nginx.conf- name: copy nginx server filecopy: src files/server.conf dest /etc/nginx/sites-available/default- name: enable configfile: dest /etc/nginx/conf.d/defaultsrc /etc/nginx/sites-available/defaultstate link- name: copy index.htmltemplate: src templates/index.html.j2 dest /usr/share/nginx/html/index.ht- name: restart nginxservice: name nginx state restarted enabled yesGSyC - 2018DevOps53

HerramientasEl guión denota un elemento de una lista (una tarea, (task)Cada tarea suele estar compuesta por varias lı́neas.La primera suele ser el nombretiene un nombre (opcional)A continuación, la ordenp.e.apt: name nginx update cache yesejecutará en cada nodoapt update; apt install -y nginxGSyC - 2018DevOps54

HerramientasReferencias[1 ] DevOps for DevelopersMichael Huttermann. Ed. Apress, tware-engineering-and-development/9781430245698[2 ] Effective DevOps: Building a Culture of Collaboration,Affinity, and Tooling at ScaleJennifer Davis, Katherine Daniels. Ed. O’Reilly, tware-engineering-and-development/9781491926291[3 ] DevOps for Web DevelopmentMitesh Soni. Ed. Pack, b-design-and-development/9781786465702[4 ] DevOps: A Software Architect’s PerspectiveLen Bass, Ingo Weber, Liming Zhu. Ed. Pearson, C - 2018DevOps55

Herramientas[5 ] Kanban in ActionMarcus Hammarberg, Joakim Sunden. Ed. Manning, t/9781617291050[6 ] The Elements of ScrumChris Sims, Hillary Louise Johnson. Ed. Dymaxicon, 2011GSyC - 2018DevOps56

Qu e NO es DevOps? (2) DevOps no es una herramienta software. Tienen su utilidad, pero ni son su cientes ni son imprescindibles DevOps no es una certi caci on. No es una metodolog a concreta y unica que se pueda ensena r, que se pueda seguir y de la que uno se pueda examinar Con frecuencia, en una ofertas de empleo donde se solicita un