New: Add 'AL - Releaseability and 'AL - Pipeline' pages

Author: pedroamador

es/application-lifecicle.md

@@ -1,21 +1,52 @@
 # Ciclo de vida
 
-Vamos a definir _Ciclo de vida_ del software como las actividades, técnicas, tácticas, servicios, procesos y herramientas relacionadas con la creación y explotación de una aplicación en todos sus aspectos. Sabemos que el _desarrollo_ supone la actividad principal, pero no es la única actividad. Cuanto más entidad tiene el proyecto software en el que estamos inmersos, más personas trabajan en él y más importancia tiene el concepto _Ciclo de Vida_.
+## Definición 
+
+Conjunto de actividades, técnicas, tácticas, servicios, procesos y herramientas relacionadas con la creación y explotación de una aplicación en todos sus aspectos. Sabemos que el _desarrollo_ supone la actividad principal, pero no es la única actividad. Cuanto más entidad tiene el proyecto software en el que estamos inmersos, más personas trabajan en él y más importancia tiene el concepto _Ciclo de Vida_.
 
 Podemos extender el _Ciclo de Vida_ a otras actividades 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 [al punto de partida](#ciclo-de-vida).
 
-Lo más 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, quizá a un proceso interativo e incremental que se repite una y otra vez en el tiempo. Bajo cierto punto de vista, si es necesario disponer de una herramienta de orquestación tipo Jenkins, su instalación, configruación, despliegue y mantenimiento también forma parte del _Ciclo de Vida_, al igual que el resto de herramientas, servicios, actividades, técnicas, tácticas y procesos.
+Lo más 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 interativo e incremental que se repite una y otra vez en el tiempo. Bajo cierto punto de vista, si utilizamos servicios, por ejemplo una herramienta de orquestación como pueda ser 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.
+
+## Ciclo de vida como evolución
+
+Es posible trabajar en un proyecto unipersonal y desarrollar el software editando el código directamente en el servidor. En este caso _Ciclo de Vida_ supone acceder al servidor y editar el código. Seguramente hubo actividades previas como configurar el servidor instalando lo necesario: servicio web, base de datosm, etc. Tal vez tengamos el servicio web y el de base de datos en nuestro PC, junto con algún IDE, para desarrollar y probar las cosas antes de subirlas al servidor.
+
+Todas esas actividades formarán parte de nuestro _Ciclo de Vida_:
+
+ - Instalr y configurar las herramientas de desarrollo y los servicios en nuestro PC
+ - Instalar y configurar los servicios en el servidor
+ - Desarrollar y probar en nuestro PC
+ - Acceder al servidor para subir código o editar código existente
+
+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, tests 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 puede ser diferente adaptándose 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, uno para los usuarios y otro para los administradores del sistema, en los que estén involucrados dos equipos de desarrollo direrentes.
 
-Es posible trabajar en un proyecto unipersonal y desarrollar el software editandol el código directamente en el servidor. En este caso _Ciclo de Vida_ supone acceder al servidor, editar el código, y listo. Seguramente hubo actividades previas como configurar el servidor instalando lo necesario: servicio web, base de datosm, etc. Aunque no hayamos prestado demasiada atención, nuestro _Ciclo de Vida_ incluye esas tareas.
+## CI-CD-CD
 
-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 de tareas e incidencias, entornos de desarrollo / pruebas / preproducción / producción, herramientas de control de código fuente, tests 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.
+Se trata de tres conceptos estrechamente relacionados con el _Ciclo de Vida_ que nos vamos a encntrar tarde o temprano en desarrollo de software.
 
-El _Ciclo de Vida_ de cada aplicación puede ser diferente adaptándose a la complejidad de cada contexto. Dentro de una misma aplicación pueden coexistir variantes en su _Ciclo de Vida_ para acomodar distintos componentes. Podría darse el caso de una aplicación formada por dos componentes, uno para los usuarios y otro para los administradores del sistema, en los que estén involucrados dos equipos de desarrollo direrentes.
+- 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 el software pueda ser liberado en cualquier momento.
+
+- CD - _Continuous Deployment_ (Despliegue Continuo): Proceso automatizado de despliegue de cambios en producción. En general está dirigido por un Pipeline en una serie de pasos o etapas que llevan nuestros cambios desde el PC del desarrollador hasta el servidor de producción en un único proceso.
+
+El concepto de _Entregabilidad_ del software supone 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. La _Entrega Continua_ se refiere concretamente este punto.
+
+Gracias a estos automatismos, si tenemnos un grado alto de _Entregabilidad_ podemos garantizar que el despliegue de nuestros cambios se puede hacer en cualquier momento de manera confiable.
+
+Mediante prácticas de _Integración Continua_ mezclamos de manera frecuente nuestros cambios en la rama principal de desarrollo para garantizar que lo que estamos desarrollando es sostenible en la aplicación, que nada deja de funcionar. Esta garantía se certifica con la ejecución de _pruebas_ de diverso tipo: unitarias, funcionales, de integración, de aceptación, de seguridad, de rendimiento, etc.
+
+## Modelo de ejemplo
 
 Trataremos un _Ciclo de Vida_ "tipo" definiendo:
 
 - Configuración y puesta en marcha del [entorno local](application-lifecicle/al-local-environment.md) (ver [entornos](environments.md))
-- [Pipeline](application-lifecicle/al-pipeline.md): Develop, Build, Test, Deploy, Release
 - [Entregabilidad]((application-lifecicle/al-releaseability.md))
+- [Pipeline](application-lifecicle/al-pipeline.md): Develop, Build, Test, Deploy, Release
 - Etiquetas y versionado semántico
 - Changelog

es/application-lifecicle/al-local-environment.md

@@ -0,0 +1,3 @@
+# Ciclo de vida: Entregabilidad: Entorno local
+
+(TBD)

es/application-lifecicle/al-pipeline.md

@@ -0,0 +1,11 @@
+# Ciclo de vida: Pipeline
+
+Es el proceso definido para gestionar todas las actividades que suceden desde que cambiamos una línea de cóodigo en nuestra aplicación hasta que esos cambios se despliegan en un entorno de producción. 
+
+## Ramas
+
+Desde el punto de vista del repositorio de código y sus ramas, los cambios que realizamos en el código fuente de la aplicación siguen una ruta de promoción _hacia produccion_, "viajando" desde nuestra rama de característica como punto de partida (feature branch), donde trabajamos de manera aislada, y realizando distintas pruebas como test unitarios, de integración, de seguridad o de rendimineto por el camino. Puede haber etapas donde nuestro código se someta a una revisión por una persona o un comité antes de integrarse en otra rama. 
+
+Un escenario típico es avanzar el desarrollo en "feature branches" (feature/*) y realizar peticiones de integración (pull requests / merge requests) hacia la rama principal de desarrollo, generalmente denominada "develop". En este caso la rama "develop" no debe ser una rama de trabajo, sino una rama de integración y promoción de cambios hacia otras ramas, generalmente "master".
+
+(TBR) (TBC)

es/application-lifecicle/al-releaseability.md

@@ -0,0 +1,15 @@
+# Ciclo de vida: Entregabilidad
+
+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.
+
+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".
+
+El equipo del proyecto hace desarrollos que suponen cambios en la aplicación. Estos desarrollos se realizan en ramas de características (_feature branches_). A medida que se avanza en el desarrollo todos los esfuerzos se dirigen a que los cambios resuelvan lo que esté previsto deban resolver, a la vez que se mantiene el funcionamiento del resto de la aplicación. Es decir, que no "se rompe" nada.
+
+Una vez que los cambios están listos, se llevan a la rama principal de desarrollo. El equipo del proyecto debe garantizar que esos cambios son _potencialmente entregables_, que se van a poder desplegar en el entorno de producción en cualquier momento, revisando y modificando, si es necesario, los procesos y _scripts_ de despliegue. Estos automatismos son al fin y al cabo software, código fuente que ha pasado por ciclos de desarrollo y pruebas.
+
+La _Entregabilidad_ del software supone que los automatismos se han revisado y se han probado con los nuevos cambios. Las pruebas que se han realizado fuera del entorno de producción garantizan que en el momento del despliegue todo irá bien.
+
+Haciendo iteraciones cortas y aumentando la frecuencia de entregas tendremos una _Entregabilidad_ más confiable, porque habremos ejecutado más veces los automatismos de despliegue. Si pasa demasiado tiempo entre relases, esa garantía y esa confianza es menor.