Build: Update to jpl v2.7.0

pedroamador · pedroamador · commit c79833760a8c · 2019-03-25T07:30:13.000+01:00
diff --git a/Jenkinsfile b/Jenkinsfile
@@ -1,6 +1,6 @@
 #!groovy
 
-@Library('github.com/red-panda-ci/jenkins-pipeline-library@v2.6.2') _
+@Library('github.com/red-panda-ci/jenkins-pipeline-library@v2.7.0') _
 
 // Initialize global config
 cfg = jplConfig('general-concepts', 'doc', '', [slack: '#integrations', email:'redpandaci+general-concepts@gmail.com'])
diff --git a/es/application-lifecicle.md b/es/application-lifecicle.md
@@ -15,7 +15,7 @@ Conjunto de actividades, técnicas, tácticas, servicios, procesos y herramienta
 
 Sabemos que el _desarrollo_ supone la actividad principal, pero no la única: podemos extender el _Ciclo de Vida_ a otras actividades incluso más allá de la puesta en producción del software, añadiendo métricas y alarmas en el entorno de producción, con _feedback loops_ que derivan en tareas de mantenimiento, soporte o características nuevas y que suponen modificaciones del código fuente que nos llevan de nuevo [al punto de partida](#introducción).
 
-Es habitual es encontrar el concepto de _Ciclo de Vida_ asociado a una serie de pasos ejecutados en orden: análisis, diseño, desarrollo, pruebas, integración, despliegue. O quizá a un proceso _iterativo e incremental_ con etapas que se repiten una y otra vez en el tiempo. Bajo cierto punto de vista, si utilizamos servicios (por ejemplo Jenkins) su instalación, configuración, despliegue, mantenimiento y operación también forma parte del _Ciclo de Vida_, al igual que el resto de herramientas, servicios, actividades, técnicas, tácticas y procesos.
+Es habitual encontrar el concepto de _Ciclo de Vida_ asociado a una serie de pasos ejecutados en orden: análisis, diseño, desarrollo, pruebas, integración, despliegue. O quizá a un proceso _iterativo e incremental_ con etapas que se repiten una y otra vez en el tiempo. Bajo cierto punto de vista, si utilizamos servicios (por ejemplo Jenkins) su instalación, configuración, despliegue, mantenimiento y operación también forma parte del _Ciclo de Vida_, al igual que el resto de herramientas, servicios, actividades, técnicas, tácticas y procesos.
 
 ---
 
diff --git a/es/application-lifecicle/al-cicdcd.md b/es/application-lifecicle/al-cicdcd.md
@@ -11,7 +11,7 @@ Contenido:
 
 Se trata de tres conceptos estrechamente relacionados con el _Ciclo de Vida_:
 
-- CI -  _Continuous Integration_ (Integración Continua): Práctica de desarrollo de software en la que los miembros de un equipo integran su trabajo frecuentemente. El objetivo es detectar fallos cuanto antes.
+- CI  _Continuous Integration_ (Integración Continua): Práctica de desarrollo de software en la que los miembros de un equipo integran su trabajo frecuentemente. El objetivo es detectar fallos cuanto antes.
 
 - CD - _Continuous Delivery_ (Entrega Continua): Enfoque en el desarrollo de software por el que se garantiza que los cambios en el código puedan ser desplegados en cualquier momento en el entorno de producción.
 
diff --git a/es/application-lifecicle/al-evolution-and-adaptation.md b/es/application-lifecicle/al-evolution-and-adaptation.md
@@ -15,16 +15,16 @@ Es posible trabajar en un proyecto unipersonal y desarrollar software editando e
 
 Todas esas actividades formarán parte de nuestro _Ciclo de Vida_:
 
- - Instalar y configurar las herramientas de desarrollo y los servicios en nuestro PC
- - Instalar y configurar los servicios en el servidor
- - Desarrollar y probar los cambios en nuestro PC
- - Acceder al servidor para subir el código nuevo
+- Instalar y configurar las herramientas de desarrollo y los servicios en nuestro PC
+- Instalar y configurar los servicios en el servidor
+- Desarrollar y probar los cambios en nuestro PC
+- Acceder al servidor para subir el código nuevo
 
 A medida que la aplicación y el equipo de desarrollo del proyecto crecen vamos a incorporar lo necesario para que nuestros "entregables" tengan la máxima calidad posible: herramientas de gestión y seguimiento de tareas, entornos de desarrollo / pruebas / preproducción / producción, herramientas de control de código fuente, test unitarios, test funcionales, servicios de alojamiento de código, servicios de integración continua con procesos de promoción del código, y un largo etcétera.
 
 ## Ciclo de vida como adaptación
 
-El _Ciclo de Vida_ de cada aplicación se puede adaptar a la complejidad de cada contexto. Dentro de una misma aplicación pueden coexistir variantes del _Ciclo de Vida_ para acomodar distintos componentes. Podría darse el caso de una aplicación formada por dos componentes, los administradores del servicio y otro para los usuarios finales, en los que estén involucrados dos equipos de desarrollo diferentes.
+El _Ciclo de Vida_ de cada aplicación se puede adaptar a la complejidad de cada contexto. Dentro de una misma aplicación pueden coexistir variantes del _Ciclo de Vida_ para acomodar distintos componentes. Podría darse el caso de una aplicación formada por dos componentes distintos, uno para los administradores del servicio y otro para los usuarios finales, en los que estén involucrados dos equipos de desarrollo diferentes.
 
 ---
 
diff --git a/es/application-lifecicle/al-pipeline.md b/es/application-lifecicle/al-pipeline.md
@@ -24,7 +24,7 @@ Este proyecto de documentación tiene un Pipeline de Jenkins asociado con el arc
 ```groovy
 #!groovy
 
-@Library('github.com/red-panda-ci/jenkins-pipeline-library@v2.6.2') _
+@Library('github.com/red-panda-ci/jenkins-pipeline-library@v2.7.0') _
 
 // Initialize global config
 cfg = jplConfig('general-concepts', 'doc', '', [slack: '#integrations', email:'redpandaci+general-concepts@gmail.com'])
diff --git a/es/application-lifecicle/al-releasability.md b/es/application-lifecicle/al-releasability.md
@@ -11,7 +11,7 @@ Contenido:
 
 Una actividad muy importante en cualquier aplicación es la entrega, el despliegue o la puesta en producción. Creamos software para ser entregado de alguna forma.
 
-Nos sirve de muy poco un desarrollo que funciona en la máquina del desarrollador (Eh! En mi local funciona). El software es evolución y adaptación, las características nuevas pueden suponer cambios en las configuraciones del servidor; supone un riesgo trabajar con una receta de puesta en producción obsoleta, con pasos que no hayamos ejercitado nunca.
+Nos sirve de muy poco un desarrollo que funciona en la máquina del desarrollador (Eh! En mi local funciona). El software es evolución y adaptación, las características nuevas pueden incluir cambios en las configuraciones del servidor; supone un riesgo trabajar con una receta de puesta en producción obsoleta, con pasos que no hayamos ejercitado nunca.
 
 Se hace necesario pues trabajar en la _Entregabilidad_ de nuestra aplicación. Lo habíamos definido como "aquellas actividades que el equipo del proyecto debe hacer para desarrollar y mantener automatismos que permitan el Despliegue Continuo de la aplicación en el entorno de producción".
 
diff --git a/es/environments.md b/es/environments.md
@@ -19,7 +19,7 @@ Podemos disponer de varios entornos de ejecución, cada uno destinado a un prop
 Ejemplo: balanceo de carga y servicio WEB. El entorno local de desarrollo dispondrá de un balanceador y dos elementos que dan servicio WEB (por ejemplo, dos nginx), y en el entorno de producción tendremos un "balanceador como servicio" (podría ser un ELB, o un balanceador hardware como un F5) y un servicio WEB formado por decenas o cientos de instancias con Nginx.
 
 Algunas categorías de entornos típicas:
- 
+
 - Entorno local de desarrollo. Destinado a ejecutarse en el PC de un desarrollador.
 - Entorno de integración. Compartido por todos los miembros del equipo, destinado a pruebas de integración.
 - Entorno de validación / calidad / pruebas. Aquel en el que ejecutamos test de aceptación (BDD), pruebas de carga, pruebas de seguridad, etc.
diff --git a/es/jenkins/jenkins-builds.md b/es/jenkins/jenkins-builds.md
@@ -13,7 +13,6 @@ Llamamos `build` a la ejecución de un `job`. Un `job` tendrá muchos `builds` a
 
 Vamos a seguro con el ejemplo de [Jobs](jenkins-jobs.md) en nuestro "Test Lab"
 
-
 ## Test Lab
 
 Vamos con el navegador a la página del job en https://localhost:10080/job/prueba/
diff --git a/es/jenkins/jenkins-jobs.md b/es/jenkins/jenkins-jobs.md
@@ -7,7 +7,7 @@ Contenido:
 - [Builds](jenkins-builds.md)
 - [Hooks](jenkins-hooks.md)
 
-Son el elemento principal de Jenkins. Contienen una serie de pasos que definimos a nuestra conveniencia, y que podemos ejecutar tantas veces como se requiera. 
+Son el elemento principal de Jenkins. Contienen una serie de pasos que definimos a nuestra conveniencia, y que podemos ejecutar tantas veces como se requiera.
 
 Podemos añadir parámetros de ejecución, asociar los Jobs a repositorios alojados en GitHub o GitLab, etc.
 
diff --git a/es/repositories.md b/es/repositories.md
@@ -28,7 +28,6 @@ El servicio alojamiento más popular para proyectos públicos de fuente abierta
 ### Recursos adicionales
 
 - [Git, la guía sencilla](http://rogerdudler.github.io/git-guide/index.es.html)
-https://medium.com/@sthefany/primeros-pasos-con-github-7d5e0769158c
 - [Guía básica de github para principiantes](https://medium.com/@sthefany/primeros-pasos-con-github-7d5e0769158c)
 
 ---
diff --git a/es/repositories/repositories-basic-concepts.md b/es/repositories/repositories-basic-concepts.md
@@ -11,9 +11,9 @@ Contenido:
 
 Existen multitud de tutoriales y guías acerca del uso de git. Uno de los mejores recursos es el libro tutorial [pro-git](https://git-scm.com/book/es/v2). La información que ahí figura es realmente extensa y completa.
 
-Podemos ver un repositorio `git` como una suerte de base de datos de código fuente donde almacenamos cada uno de los cambios que vamos desarrollando en nuestra aplicación. Los cambios se guardan agrupados en conjuntos denominados **commit** identificados mediante un _hash_ que sirve para localizar ese conjunto de cambios y diferenciarlo del resto. Cada uno de estos **commit** lleva asociada su descripción en forma de mensaje.
+Podemos ver un repositorio `git` como una suerte de base de datos de código fuente donde almacenamos cada uno de los cambios que vamos haciendo en nuestra aplicación. Los cambios se guardan agrupados en conjuntos denominados **commit** identificados mediante un _hash_ que sirve para localizar ese conjunto de cambios y diferenciarlo del resto. Cada uno de estos **commit** lleva asociada su descripción en forma de mensaje.
 
-Si vemos el **repositorio** como una _base de datos_ los **commit** serían _registros de una tabla_. 
+Si vemos el **repositorio** como una _base de datos_ los **commit** serían _registros de una tabla_.
 
 Tamibén podemos ver un repositorio git como una _máquina del tiempo_ donde se guardan los cambios que hemos ido haciendo día tras día en nuestro código fuente.
 
diff --git a/es/repositories/repositories-collaboration.md b/es/repositories/repositories-collaboration.md
@@ -101,7 +101,7 @@ Cuando nos traemos las novedades del servidor remoto con `git pull` sobre la ram
 
 El segundo desarrollador trata de llevar sus modificaciones a la rama principal de desarrollo y se encuentra con que en la rama "develop" el primer desarrollador ha modificado el fichero README.md. Por tanto, tenemos un conflicto
 
-Para resolver el conflicto hemos utilizado Visual Studio Code. 
+Para resolver el conflicto hemos utilizado Visual Studio Code.
 
 ![VSCode - Show conflicts](img/vscode-show-conflicts.png?raw=true "VSCode - Show conflicts")
 
diff --git a/es/repositories/repositories-git-flow.md b/es/repositories/repositories-git-flow.md
@@ -30,7 +30,7 @@ Ejemplos:
 - `git flow feature publish ejemplo` // Se publica la feature branch "ejemplo" en el servidor remoto con el nombre de rama "feature/ejemplo"
 - `git flow feature finish ejemplo` // Se reintegra la feature branch "ejemplo" en la rama principal de desarrollo "develop"
 
-En realidad, el uso de `git flow` supone un atajo al uso de comandos de `git`. Cada acción de `git flow` se traduce en una o varias acciones de git. 
+En realidad, el uso de `git flow` supone un atajo al uso de comandos de `git`. Cada acción de `git flow` se traduce en una o varias acciones de git.
 
 ## Test Lab
 
diff --git a/es/repositories/repositories-main-actions.md b/es/repositories/repositories-main-actions.md
@@ -30,7 +30,7 @@ Ejemplo:
 
 En nuestro día a día vamos añadir, modificar o borrar archivos de código fuente de la aplicación en nuestro disco duro. Tal y como hemos dicho antes, cuando descargamos el repositorio por primera vez mediante el `clone`, `git` se queda el repositorio unido a un directorio local ".git".
 
-`git` es, de alguna forma, consciente de todas esas modificaciones. 
+`git` es, de alguna forma, consciente de todas esas modificaciones.
 
 - Utilizando `git add` preparamos nuestros cambios. Se preparan tanto los archivos nuevos como los que hemos modificado.
 - Mediante `git rm` informamos a `git` que estamos eliminando un archivo de nuestro directorio de trabajo.
@@ -66,7 +66,7 @@ Ejemplo:
 
 Descarga los cambios que se han hecho en el repositorio desde el servidor remoto a nuestra copia local. Podemos decir que "se trae las cosas nuevas".
 
-Es posible que las modificaciones deban mezclarse (`merge`) con el código en el que estamos trabajando. 
+Es posible que las modificaciones deban mezclarse (`merge`) con el código en el que estamos trabajando.
 
 Ejemplo:
 
@@ -121,7 +121,7 @@ En esta ocasión:
 
 - Creamos un archivo nuevo "new_file.txt"
 - Lo preparamos para añadir al repositorio `git add new_file.txt`
-- Confirmamos nuestros cambios en la copia local del repositorio con `git commit ... `
+- Confirmamos nuestros cambios en la copia local del repositorio con `git commit ...`
 
 Al final podemos ver como tenemos 2 nuevos "commits" que subir al servidor remoto
 
diff --git a/es/toc.md b/es/toc.md
@@ -19,4 +19,3 @@ Esta documentación nace para quedar obsoleta: trata sobre una aplicación WEB q
 ## Créditos
 
 - Como ayuda para elaborar parte de este material se utilizó el proyecto [Red Panda CI symfony](https://github.com/sergioortegagomez/red-panda-ci-symfony) que en su día hizo [Sergio Ortega Gómez](https://github.com/sergioortegagomez), sirviendo de base para los ejemplos y el "Test Lab". Gracias, Sergio :)
-
