continuous delivery (2)€¦ · metodologías Ágiles de desarrollo de software domingo gallardo,...

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

Continuous Delivery (2)Sesión 10


Tubería de build

�2

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

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


Principios de automatización

�3




Sólo compilar una vez

�4




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

�5

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


• Podemos cambiar una aplicación modificandocualquiera de los siguientes elementos que la constituyen:• Ficheros de configuración que

definen valores dependientes del entornode ejecución

• 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

Aplicación = Configuración + Binarios + Datos

�7

Aplicación

Ficheros de configuración

Binarios

Datos


Gestión de configuraciones

• Determinan valores necesarios para ejecutar y probar la aplicación• URL de servicios, URL del sistema de base de datos, etc.

• Conjunto de tuplas• Dependen de

• La aplicación• La versión de la aplicación• El entorno en el que corre la aplicación

• Ejemplo usando ficheros de propiedades (Java)• Directorio myapp/config

dev-application.properties test-application.properties uat-application.properties prod-application.properties

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

�8

Aplicación

Ficheros de configuración

Binarios

Datos


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:

�9

S3Handler = new S3Handler("" " " " " " " " System.getenv("S3_KEY"), " " " " " " " " System.getenv("S3_SECRET"))

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

�10

# Database configuration"# ~~~~~ "# You can declare as many datasources as you want."# By convention, the default datasource is named `default`"#"db.default.driver=org.h2.Driver"db.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

�11

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)" }"}


En cada entorno se deben copiar ficheros específicos

�12

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


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

�13


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

�14


Automatización del build

• Lenguajes y herramientas de build• Make (C, Unix)• Ant y Maven (Java)• Rake (Ruby) - Buildr (Scala)• sbt (Scala, Play Framework)

�15

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,)”

�16

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

�17

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.jar!5. Copia el JAR con el binario al directorio target/staged!6. Crea el comando target/start con el que arrancar la aplicación

�18

$ play clean compile stage


Build en Play (3)

• Comando para empaquetar una aplicación Play

!1. Hace todo lo que stage!2. 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)

�19

$ 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:

�20

object ApplicationBuild extends Build {"! val appName = "todolist"" val appVersion = "1.0." + System.getenv(“BUILD_NUMBER")"…

object ApplicationBuild extends Build {"! 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

�21

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

�22


Separación de pruebas unitarias y de integración en Play

• Es posible definir etiquetas en los tests spec!!!!!!

• Y lanzar los tests incluyendo o excluyendo los etiquetados

�23

class ApplicationSpec extends Specification with Tags {" " "Application" should {" " "send 404 on a bad request" in {" running(FakeApplication()) {" route(FakeRequest(GET, "/boum")) must beNone " } " } tag ("integration")!

$ play "test-only test.ApplicationSpec -- exclude integration”"$ play "test-only test.ApplicationSpec -- include integration"


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.

�24


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)

�25

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

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


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

Ejemplo de automatización con Jenkins

�26

http://www.wakaleo.com


http://www.wakaleo.com

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


Lecturas

• Martin Fowler - Continuous Integration• Paul Duval - Continuous Integration Refcardz• Paul Duval - Continuous Delivery Refcardz

�54

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

http://refcardz.dzone.com/refcardz/continuous-integration

http://refcardz.dzone.com/refcardz/continuous-delivery-patterns

continuous delivery (2)€¦ · metodologías Ágiles de desarrollo de software domingo gallardo,...

Documents