4.2 La tubería de despliegue · Metodologías Ágiles de Desarrollo de Software Domingo Gallardo,...

Metodologías Ágiles de Desarrollo de SoftwareDomingo Gallardo, DCCIA, Univ. Alicante, 2014-15

4.2 La tubería de despliegueTema 4: Continuous delivery

Metodologías Ágiles de Desarrollo de SoftwareDomingo Gallardo, DCCIA, Univ. Alicante, 2014-15 La tubería de despliegue

Índice• La tubería de despliegue• Gestión de configuraciones• Construcción de builds• Integración continua• Gestión de entornos de prueba

2


La tubería de despliegue (versión sencilla)

3

John Ferguson Smart - Real-World Strategies for Continuous Delivery with Maven and Jenkins

http://www.slideshare.net/wakaleo/continuous-deliverywithmaven


Principios de automatización

4




Sólo compilar una vez

5




Elementos de una tubería de despliegue• Sistema de control de versiones• Compilación y construcción de binarios (builds)• Repositorio de artefactos • Renombrado de versiones (de builds y releases)• Análisis de código• Configuración de entornos• Despliegue de binarios• Ejecución de tests: unitarios, aceptación, funcionales, capacidad• Monitorización de datos y publicación de informes

6


Tubería de despliegue (versión completa - Jez Humble)

7


Gestión de la configuración• Configuration managent

“Configuration management refers to the process by which all artifacts relevant to your project, and the relationships between them, are stored, retrieved, uniquely identified and modified”

Jez Humble - Continuous Delivery

• En metodologías tradicionales la gestión de la configuración es un proceso costoso en el que hay que desarrollar una gran cantidad de documentación que asegure que todos los ítems de configuración del sistema y sus relaciones están identificados, registrados y monitorizados.

• En un enfoque ágil la gestión de la configuración tiene que ver además con la gestión del cambio y de la evolución del software y con su desarrollo incremental.

8

http://en.wikipedia.org/wiki/Configuration_Management_(ITSM)


Objetivos de la gestión de la configuración• Una buena gestión de la configuración permitirá:• Reproducir cualquiera de nuestros entornos, incluyendo la versión del sistema

operativo instalada, la configuración de la red, el stack de software, las aplicaciones instaladas y su configuración

• Realizar fácilmente un cambio incremental a cualquiera de estos ítems y desplegar el cambio en algunos o todos los entornos

• Comprobar el cambio que ha ocurrido en un entorno particular y recuperar el origen del mismo: quién lo ha hecho, qué se ha hecho y cuando se ha hecho

• Hacer posible que cualquier miembro del equipo obtenga la información necesaria y pueda realizar los cambios necesarios

• El elemento central de la gestión de la configuración es el sistema de control de versiones: Subversion, Mercurial o Git• Permite acceder a cualquier versión de cualquier fichero almacenado• Permite la colaboración de equipos distribuidos en el tiempo y el espacio

9


Cómo utilizar bien un sistema de control de versiones1. Mantén absolutamente todo bajo el control de versiones• Código fuente, tests, scripts de base de datos, scripts de construcción y despliegue,

documentación, ficheros de configuración, librerías, etc. • Información requerida para recrear los entornos de pruebas y producción en los que

corre la aplicación: configuración de servidores, redes, sistemas operativos• Debe ser posible recrear cualquier versión de cualquier entorno en el que corren las

aplicaciones y analizar la historia de cambios

2. Sube diariamente los cambios al repositorio• De esta forma se hacen públicos y todos los miembros del equipo pueden

conocerlos• Dos enfoques (no demasiado distintos)• Una única rama de desarrollo con ramas de features de vida corta• GitFlow con la rama master y la develop que hace de rama de integración continua

3. Utiliza mensajes de commit que tengan sentido

10


Aplicación = Configuración + Binarios + Datos• Podemos cambiar una aplicación modificando

cualquiera de los siguientes elementos que la constituyen:• Ficheros de configuración que pueden cambiar el comportamiento de

la aplicación en tiempo de construcción (build time), de despliegue (deploy time) o de ejecución (run time)

• Binarios obtenidos a partir del código fuente• Datos (guardados en la BD, imágenes, vídeos,

etc.)

• Todos los elementos deben estar en el sistema de control de versiones y debemos poder recuperar una versión determinada

• Ficheros de configuración: • Determinan valores necesarios para ejecutar y probar la aplicación: URL de servicios, URL

del sistema de base de datos, etc.• Modifican la aplicación: mensajes de error, imágenes e incluso su comportamiento (no

recomendable)

11

Aplicación

Ficheros de configuración

Binarios

Datos


Tipos de configuración• La información de la configuración puede ser inyectada en la aplicación en bastantes puntos

en el proceso de construcción, despliegue, test y lanzamiento• Los scripts de build pueden obtener la configuración e incorporarla en los binarios en

tiempo de construcción • El software de empaquetado puede inyectar configuración en tiempo de

empaquetamiento• Los scripts de despliegue o instaladores pueden obtener la información necesaria o

preguntar al usuario y pasarla a la aplicación en tiempo de despliegue o como parte del proceso de instalación

• La aplicación misma puede conseguir la configuración en tiempo de arranque (startup time) o en tiempo de ejecución

12

Mala práctica, porque los binarios deberían ser los mismos en todos los entornos


Ejemplo de gestión de configuraciones en Java• Conjunto de tuplas (propiedades)• Se definen en ficheros de propiedades• Formas de gestionar distintas configuraciones:• Distintos ficheros:

myapp/config/dev-application.properties myapp/config/test-application.properties myapp/config/uat-application.properties myapp/config/prod-application.properties

• En el proceso de despliegue el fichero correcto se coloca en /home/myapp/config/application.properties

13

Configuration Management With RESTful Git

firstName=LokeshlastName=Guptablog=http://blog.miweb.estechnology=java

http://www.andycaine.com/configuration-management-with-restful-git/


En cada entorno se deben copiar ficheros específicos

14

ToDoListv 2.1 UAT

Conf ToDoList v2.1 UAT

Binarios ToDoList v2.1

Datos ToDoList v2.1 UAT

ToDoListv 2.1 Prod

Conf ToDoList v2.1 Prod


Datos ToDoList v2.1 Prod

ToDoListv 2.1 Develop

Conf ToDoList v2.1 Develop


Datos ToDoList v2.1 Develop

Desarrollo UAT Producción


Variables de entorno• Otra forma de gestionar la configuración es hacer que el proceso de despliegue inicialice

variables de entorno y obtener sus valores en los binarios• Sistema usando en Heroku (ver Configuration and Config Vars)• Heroku también permite gestionar distintas configuraciones remotas de una misma

aplicación• La aplicación lee los valores de las variables del entorno. Por ejemplo, en Java:

15

String databaseUser = System.getenv(“DB_USER”); String databasePasswd = System.getenv("DB_PASSWORD"))

https://devcenter.heroku.com/articles/config-vars

https://devcenter.heroku.com/articles/multiple-environments


Gestión de configuración en Play• En Play Framework se definen las variables de configuración en el fichero

application.conf :

• Se pueden cargar otros ficheros de configuración usando el comando start

• En la aplicación se pueden obtener los valores de las variables declaradas

16

# Database configuration# ~~~~~ # You can declare as many datasources as you want.# By convention, the default datasource is named `default`#db.default.driver=org.h2.Driverdb.default.url="jdbc:h2:mem:play"# db.default.user=sa# db.default.password=""

start -Dconfig.file

$ start -Dconfig.file=/opt/conf/prod.conf$ start -Dconfig.url=http://conf.mycompany.com/conf/prod.conf

val configuration = Configuration.load()val isEnabled = configuration.getString("engine.isEnabled")

https://github.com/typesafehub/config


Gestión de configuración en Play• Otra opción: definir ficheros alternativos y cargarlos de forma explícita• Se puede usar una variable de entorno en la que guardamos el tipo de entorno (dev, test, prod) para cargar el

fichero correspondiente: application.dev.conf, application.test.conf, application.dev.conf

17

object Global extends GlobalSettings { override def onLoadConfig(config: Configuration, path: File, classloader: ClassLoader, mode: Mode.Mode): Configuration = { val appMode = configuration.getString("application.mode") val modeSpecificConfig = config ++ Configuration(ConfigFactory.load( “application.”+appMode+".conf")) super.onLoadConfig(modeSpecificConfig, path, classloader, mode) }}


Tubería de despliegue (versión completa - Jez Humble)

18


Construcción de builds• Verbo “to build”: construir un sistema (fichero o conjunto de ficheros) que se van a

desplegar (copiar) en un entorno (computador o conjunto de servidores)• Entendemos por build el conjunto de ficheros (binarios y de configuración) obtenidos a

partir de la compilación del código fuente de un proyecto y su configuración para ser desplegado y lanzado en un entorno

• Un elemento fundamental son las dependencias:• Entre ficheros compilados y ficheros de configuración• Entre ficheros compilados y paquetes externos• Entre ficheros compilados y entornos en

los que se van a desplegar• Fundamental la automatización y no depender del IDE

19


Tareas comunes en el build• Compilación (java -> .class)• Selección de ficheros de configuración (XML o .properties)• Lanzamiento de pruebas unitarias • Empaquetado (construcción de JARs) y copia en repositorio de artefactos• Despliegue

20


Automatización del build• Lenguajes y herramientas de build• Make (C, Unix)• Ant y Maven (Java)• Rake (Ruby) - Buildr (Scala)• Gradle (Java, Scala, etc.)• sbt (Scala, Play Framework)

21

http://www.gradle.org/index

http://www.scala-sbt.org/release/docs/index.html


Gestión de las dependencias• Tanto Maven como sbt utilizan un sistema similar para definir las dependencias de la aplicación con otras

librerías. Está basado en el proyecto Ivy de Apache.

• Es posible definir dependencias distintas para tests

• Es posible definir dependencias basadas basadas en el número de versión: “latest.integration”, “2.9.+” o “[1.0,)”

22

Documentación Play Framework - Managing library dependencies

Apache Ivy - Dependencies

http://ant.apache.org/ivy/

http://www.playframework.com/documentation/2.2.x/SBTDependencies

http://ant.apache.org/ivy/history/2.3.0/ivyfile/dependency.html


Build en Play (1)• Fichero project/Build.scala

23

object ApplicationBuild extends Build {

val appName = "todolist" val appVersion = “1.0.203"

val appDependencies = Seq( // Add your project dependencies here, jdbc, anorm, "postgresql" % "postgresql" % "8.4-702.jdbc4" )

val main = play.Project(appName, appVersion, appDependencies).settings( // Add your own project settings here )

}


Build en Play (2)• Comando para compilar y preparar para su ejecución una aplicación play

1. Descarga todas las dependencias al directorio target/staged2. Empaqueta los fuentes en

target/scala-2.10/todolist_2.10-1.0.203-sources.jar 3. Crea y empaqueta la documentación en

target/scala-2.10/todolist_2.10-1.0.203-javadoc.jar 4. Compila y empaqueta los binarios en

target/scala-2.10/todolist_2.10-1.0.203.jar5. Copia el JAR con el binario al directorio target/staged6. Crea el comando target/start con el que arrancar la aplicación

24

$ play clean compile stage


Build en Play (3)• Comando para empaquetar una aplicación Play

1. Hace todo lo que stage2. Crea el fichero ZIP dist/todolist-1.0.201.zip con todos los JARS de los que depende la

aplicación3. Dentro del ZIP guarda el comando start

• Ejemplo práctico sobre cómo poner en producción una aplicación Play (Alvin Alexander)

25

$ play clean compile dist

http://alvinalexander.com/scala/play-framework-deploying-application-production-server


Número de versión delbuild en Play• Para crear el número de versión a partir de una variable de entorno:

• Para crear el número de versión a partir de una propiedad especificada en línea de comando:

26


val appName = "todolist" val appVersion = "1.0." + System.getenv(“BUILD_NUMBER")…


val appName = "todolist" val appVersion = "1.0." + System.getProperty(“build.number”)…

$ play -Dbuild.number=203 clean compile stage

$ export BUILD_NUMBER=203 $ play clean compile stage


Repositorio local de artefactos• “Ya está Maven bajándose todo Internet”• Es conveniente mantener las dependencias con JAR externos en un repositorio local de

artefactos• Maven (o sbt) busca en el repositorio local antes de ir al repositorio Maven 2 estándar• Dejamos también ahí los builds compilados de nuestros proyectos y librerías de utilidad• Aplicaciones que gestionan el repositorio local y lo mantienen sincronizado con los repos

remotos: artifactory, Nexus

27

http://www.jfrog.com/home/v_artifactory_opensource_overview

http://www.sonatype.org/nexus/


Pruebas unitarias y de integración• Cada desarrollador debe probar los tests unitarios en sus máquinas locales antes de hacer

un push• Diariamente el servidor de Integración Continua:• Ejecuta todos los tests unitarios en la rama principal y genera el build • Despliega en el entorno de integración para ejecutar los tests de integración

• Es conveniente separar los tests unitarios de los tests de integración y poder ejecutarlos unos independientemente de otros

28


Tests de integración y ramas de características• Un problema cuando se trabaja con ramas de características es que es difícil automatizar

los tests de integración• Algunos servidores de IC permiten definir estrategias automáticas de build para cada rama

(por ejemplo, Atlassian Bamboo)• Solución simple: • Hacer los tests de integración en la rama principal • Desarrollar en la rama principal usando interruptores de características que son

“activados” por los tests unitarios y de integración• Si se crean ramas de características que sean “short-lived” de verdad y que no duren

más de dos o tres días. Mezclar tras ese tiempo en la rama principal y pasar los tests de integración.

29


Calidad de código

• Herramientas para el análisis de código estático en Java: PMD, Findbugs, Checkstyle (análisis en RebelLabs)

• Hay que tomarse la calidad del código en serio• Integrarlo en el servidor de CI para que si no se

pasan las reglas, falle el build• Es mejor definir pocas reglas y ser estrictos que

definir muchas reglas y no cumplirlas• Importante para la calidad del código: dominar el IDE• Uno de los menos conocidos y mejores IDE

para Java (y Scala): IntelliJ IDEA (disponible versión gratuita)

30

http://zeroturnaround.com/rebellabs/code-quality-tools-review-for-2013-sonar-findbugs-pmd-and-checkstyle/

http://www.jetbrains.com/idea/


Integración continua• Diariamente la aplicación se integra y se ejecutan las pruebas unitarias y de integración

• Proceso automático:• Se baja la última versión del control de versiones• Se lanza el script de build• Se publican los resultados de los tests en una página web accesible a todo el equipo

• Herramientas• Bamboo • Cruise Control • Jenkins • Go • TravisCI

31

https://www.atlassian.com/software/bamboo

http://cruisecontrol.sourceforge.net

http://jenkins-ci.org

http://www.thoughtworks.com/products/go-continuous-delivery

https://travis-ci.org


Ejemplo de integración continua con Jenkins• Tomado de John Ferguson Smart - Real-World Strategies for Continuous Delivery with

Maven and Jenkins

32

http://www.wakaleo.com


http://www.wakaleo.com

Metodologías Ágiles de Desarrollo de SoftwareDomingo Gallardo, DCCIA, Univ. Alicante, 2014-15 La tubería de despliegue 33



























Metodologías Ágiles de Desarrollo de SoftwareDomingo Gallardo, DCCIA, Univ. Alicante

Tubería de despliegue

59


Entornos de prueba• La última parte de la tubería de despliegue consiste en probar los builds compilados en

distintos entornos de prueba• Distintos entornos• Tests de integración y aceptación• UAT• Tests de capacidad• Producción

• A su vez, cada uno de ellos puede tener distintas configuraciones y estar formado por múltiples máquinas• Pruebas con distintos clientes y navegadores• Pruebas con distintas bases de datos y servicios (si se va a desplegar la aplicación en

distintos entornos de producción)

60


Desplegar de la misma forma• Es esencial usar el mismo proceso para desplegar en los distintos entornos• Características diferentes de los entornos en ficheros de configuración, no en el script de

despliegue• Distintas IP (como mínimo)• Distintos sistemas operativos• Distinta configuración del middleware (localización de las bases de datos y servicios

externos)• El script de despliegue debería ser el mismo en todos los entornos:

1. Configurar el entorno2. Desplegar los binarios3. Poner en marcha las aplicaciones y comprobar que funcionan (pruebas de humo)

61


Gestión de entornos de prueba y producción• Cuanto menos control tenemos sobre el entorno en el que el código se ejecuta, más

probabilidades hay de comportamientos no esperados• Nos interesa tener control sobre todos y cada uno de los bits del entorno en el que se

despliega nuestra aplicación• Los cambios en los entornos deben realizarse sólo mediante procesos automatizados y

registrados• En cada entorno se debe definir claramente (y guardar en el control de versiones):• Configuración• Software que se despliega• Topología de la red• Estado

• El objetivo final es necesitar solo dos parámetros para realizar el despliegue:• Identificador del entorno de despliegue• Identificador del build a desplegar

62


Herramientas de empaquetado• En cada entorno hay que desplegar:• Conjunto de ficheros binarios• Ficheros de configuración• Ficheros estáticos en el control de versiones

• Es muy recomendable utilizar un sistema de empaquetado para desplegar la aplicación en el entorno: RPMs en el mundo Linux • Cada release se empaqueta y se sube a un repositorio• Las herramientas de gestión de entornos se encargan de instalar el paquete de la misma

forma que instalan el resto de software

63

http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html


Virtualización de entornos• La virtualización permite crear y configurar distintos entornos en una única máquina física• Muy económico• Entornos controlables• Ejecuciones repetibles

• Software más popular• VirtualBox (Oracle)• vSphere Hypervisor (VMware)

64

https://www.virtualbox.org

http://www.vmware.com/products/vsphere-hypervisor/


Vagrant• Software open source, creado por Mitchel Hashimoto

(@mitchellh)• Escrito en Ruby• Permite automatizar la creación, puesta en marcha, configuración y aprovisionamiento de

entornos virtuales

65

Vagrant web site

https://twitter.com/mitchellh

http://docs.vagrantup.com/v2/why-vagrant/index.html


Instalación de Vagrant• Funciona inicialmente con VirtualBox• Fácil instalación mediante paquetes nativos del SO• Se instala el comando vagrant• Posibles comandos:

66


Inicializando y descargando una box• Se crea un directorio y se ejecuta el comando vagrant init para crear un fichero

Vagrantfile que contiene una configuración por defecto

• Se descarga una máquina virtual vacía (box) de una URL con el comando vagrant box add nombre URL

67

$ mkdir prueba-vagrant$ cd prueba-vagrant$ vagrant init

$ vagrant box add precise32 http://files.vagrantup.com/precise32.boxDownloading box from URL: http://files.vagrantup.com/precise32.boxExtracting box...te: 568k/s, Estimated time remaining: 0:00:02))Successfully added box 'database' with provider 'virtualbox'!


Boxes• Las boxes son esqueletos de máquinas virtuales de la plataforma de virtualización con la

que Vagrant esté trabajando• Lista de boxes oficiales:

https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Boxes• Lista de boxes de la comunidad: http://www.vagrantbox.es • Contienen lo básico para poder poner en marcha Vagrant:• Gestor de paquetes• ssh• Usuario ssh• Chef o Puppet (aunque no es necesario, lo veremos después)

• Se guardan en el directorio ~/.vagrant.d/boxes

68

https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Boxes

http://www.vagrantbox.es


Cómo usar una box• Un primer ejemplo• Fichero Vagrantfile

• Para poner en marcha la máquina virtual y conectarse por ssh: $ vagrant up $ vagrant ssh

69

Vagrant.configure("2") do |config| config.vm.box = "precise32"end


Carpeta compartida• Vagrant comparte automáticamente el directorio de la máquina host (el directorio con el

fichero Vagrantfile) en el directorio /vagrant de la máquina virtual

70

$ vagrant upBringing machine 'default' up with 'virtualbox' provider...[default] Booting VM...[default] Waiting for machine to boot. This may take a few minutes...[default] Machine booted and ready![default] Mounting shared folders...[default] -- /vagrant[default] VM already provisioned. Run `vagrant provision` or use `--provision` to force it$ vagrant ssh Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic-pae i686)

* Documentation: https://help.ubuntu.com/Welcome to your Vagrant-built virtual machine.Last login: Fri Sep 14 06:22:31 2012 from 10.0.2.2vagrant@precise32:~$ pwd /home/vagrantvagrant@precise32:~$ ls /vagrantVagrantfile


Aprovisionamiento• Es posible automatizar la instalación de software en las máquinas virtuales definiendo un

script en el fichero bootstrap.sh en el mismo directorio del Vagrantfile:

• Y añadiendo una instrucción en Vagrantfile:

71

#!/usr/bin/env bash

apt-get updateapt-get install -y apache2rm -rf /var/wwwln -fs /vagrant /var/www

Vagrant.configure("2") do |config| config.vm.box = "precise32" config.vm.provision :shell, :path => "bootstrap.sh"end


Puesta en marcha• El comando vagrant reload --provision vuelve a lanzar la máquina virtual y ejecuta el

aprovisionamiento:

72

$ vagrant reload —-provision... se ejecuta el script bootstrap.sh $ echo "Hola mundo" > hola.txt$ vagrant sshvagrant@precise32:~$ wget -qO- 127.0.0.1/hola.txtHola mundo


Configuración de la red• El fichero Vagrantfile permite también configurar la red de la máquina virtual con distintas opciones

• Reenvío de puertos• Asignación de dirección IP estática• Definición de redes privadas entre máquinas (documentación de Vagrant)

• Ejemplo de reenvío de puertos

• Si hacemos vagrant reload podremos acceder en la máquina host al servidor web en http://127.0.0.1:4567

73

Vagrant.configure("2") do |config| config.vm.box = "precise32" config.vm.provision :shell, :path => "bootstrap.sh" config.vm.network :forwarded_port, host: 4567, guest: 80end

http://docs.vagrantup.com/v2/networking/private_network.html

http://127.0.0.1:4567


Múltiples máquinas• Es posible controlar distintas máquinas con un único Vagrantfile

• Es posible arrancar, conectarse, etc. a cualquier máquina convagrant up <machine-name>

• Es posible comunicar una máquina con otra a través de la red privada

74

Vagrant.configure("2") do |config| config.vm.provision "shell", inline: "echo Hello"

config.vm.define "web" do |web| web.vm.box = "apache" end

config.vm.define "db" do |db| db.vm.box = "mysql" endend


Otros comandos• vagrant halt: para la máquina• vagrant destroy: elimina el estado de la máquina (no borra la box)• vagrant status: muestra el estado de las máquinas

75


Herramientas de gestión de entornos• Por defecto la configuración (aprovisionamiento) de la máquina Vagrant se hace con un

script de shell• Es posible utilizar otras herramientas de mayor nivel, independientes del shell y del SO

usado, como Puppet o Chef

76

Vagrant.configure("2") do |config| config.vm.provision "puppet_server" do |puppet| puppet.puppet_server = "puppet.example.com" puppet.puppet_node = "node.example.com" puppet.options = "--verbose --debug" endend


Introducción a Puppet• Permite automatizar la gestión toda la infraestructura de

máquinas de una empresa• Terminología:• Nodo: máquina que mantiene una configuración

determinada• Puppet master: servidor de Puppet que chequea la configuración de los nodos cada

30 minutos• Puppet agent: agente de Puppet que se ejecuta en cada nodo y se comunica con el

Puppet master• Estado deseado: Configuración definida para cada uno de los nodos

• Cada nodo envía al Puppet master datos sobre su estado actual• Si un nodo no se encuentra en la configuración deseada, el maestro le envía detalles de su

configuración y el agente realiza los cambios necesarios en el nodo para volver al estado deseado

77


Introducción a Puppet

78

http://puppetlabs.com/puppet/what-is-puppet



Introducción a Puppet

79




Descripción de la configuración de un nodo• La configuración de un nodo se describe mediante la definición de recursos• Cada recurso es una instancia de un tipo de recurso, tiene un nombre, unos atributos

(definidos por el tipo) y unos valores para cada atributo• Puppet usa su propio lenguaje para definir los recursos

• En los recursos se define el estado deseado

80

user { 'dave': ensure => present, uid => '507', gid => 'admin', shell => '/bin/zsh', home => '/home/dave', managehome => true, }


Tipos de recursos• Es conveniente tener a mano la chuleta de tipos de recursos

81

• Otros importantes• notify• exec• cron• user• group

• The Trifecta• file• package• service

http://docs.puppetlabs.com/puppet_core_types_cheatsheet.pdf


Consola de administración• La versión enterprise de Puppet (gratuita hasta 10 nodos) tiene herramientas y utilidades

para simplificar la gestión, como la consola de administración

82


Vídeo de Puppet enterprise

83

http://www.youtube.com/watch?v=j8ImF23jZAg#t=1

http://www.youtube.com/watch?v=j8ImF23jZAg#t=1


Bibliografía de ampliación• Martin Fowler - Continuous Integration

• Jez Humble, Continuous Delivery, Addison Wesley 2011

• Web y blogs de Thoughtworks sobre Continuous Delivery

84

http://martinfowler.com/articles/continuousIntegration.html

http://www.thoughtworks.com/continuous-delivery

Date post:	24-Jun-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

4.2 La tubería de despliegue · Metodologías Ágiles de Desarrollo de Software Domingo Gallardo,...

Documents