Enimbos.com
Close

Cómo preparar un entorno Octopus para desplegar Web Sites siguiendo un Pipeline CI/CD

A lo largo de este artículo de Blog vamos a explicar, utilizando ejemplos, cómo preparar un entorno Octopus para desplegar Web Sites siguiendo un Pipeline CI/CD. Partiremos de un servidor Octopus ya preparado y trataremos de configurar los entornos, las instancias donde desplegaremos, el proceso de despliegue, versionado y el paso entre entornos.

 

Añadir Entornos y configuración de las instancias

El primer paso es añadir entornos para identificar las máquinas y nuestro desarrollo. Para ello, tenemos que ir donde se señala la imagen y darle click a “ADD ENVIRONMENT”, donde nos saldrá un menú emergente para introducir el nombre del entorno. Nosotros hemos elegido crear los entornos DEV, TEST, PRE y PRO.

 

Añadido de varias Instancias a la lista de Deployment Targets

Para este blog hemos preparado dos Instancias, una DEV y otra TEST, ambas configuradas con el IIS y preparadas para alejar Web Sites. Ambas Instancias tendrán un tentacle, que es un software que conecta Octopus con la Instancia para realizar los despliegues y configuraciones del proyecto. La forma más sencilla de hacerlo es seguir las siguientes imágenes:

Seleccionamos el SO (Windows en nuestro caso) y le damos a Listening Tentacle.

Una nueva ventana nos dará un link para descargar el Tentacle (1) y nos da el Thumbprint (2). Debemos de pasar el instalador del Tentacle a las Instancias e introducir el Thumbprint en las Instancias, seleccionando la misma opción de añadido (Listening Tentacle en este caso). Una vez instalado, deberemos de introducir la IP de la Instancia en (3) y darle a Next para dejarlo configurado.

Posteriormente, rellenaremos sus detalles poniendo su nombre (1), el entorno (2) y el rol (3) (que se trata de un identificador de las máquinas). Después le damos a Save y ya tendríamos nuestra Instancia guardada y preparada:

 

Package en la librería de Octopus

Los Package en Octopus contendrán la aplicación que queremos desplegar sobre las Instancias. Éstos se pueden identificar por dos partes:

  • Package ID: que está compuesto por el nombre del Package.
  • Version number: que es la versión del Package.

Se recomienda tener una nomenclatura para poder diferenciar las versiones. Nosotros utilizaremos la siguiente:

NombreProyecto_Entorno.NumEntorno.Version.Version

Entorno sería DEV, TEST, PRE y PRO. El NumEntorno sería, en este caso, 1 para DEV, 2 para TEST, 3 para PRE y 4 para PRO. Las versiones identificarían la versión del Package para ese tipo de entorno.

Nosotros vamos a desplegar un Package con el proyecto “Hello World by Enimbos” en el entorno DEV, que contendrá una simple web. Su nombre sería:

HelloWorldByEnimbos_DEV.1.1.1

Cabe señalar que los Packages que soporta Octopus son en formato NuGet, zip, tar, jar, war, rar, … entre otros. Nosotros usaremos ZIP.

Para subir el Package, tenemos que ir a Library -> Package -> Upload Package, tal y como puede verse:

Saldrá una ventana para seleccionar nuestro ZIP y lo subimos.

Una vez subido el Package, nos mostrarán los detalles. Véase:

 

Creación y configuración de un Proyecto Octopus

Una vez subido el Package, podemos proceder a crear un Proyecto Octopus. No ahondaremos demasiado en este punto, pero sí explicaremos brevemente el proceso.

Para crear el proyecto, tenemos que irnos a Projects y hacer click en ADD PROJECT:

NOTA: Véase que se pueden crear grupos para agrupar Proyectos.

Saldrá un menú emergente para meter el nombre, la descripción, el grupo de Proyectos y el Lifecycle (paso de la aplicación de entornos). Rellenamos y le damos a Save:

 

Una vez creado, nos redirigirá a nuestro proyecto y podremos definir los procesos del mismo.

Para definir nuestro proceso tendremos que ir a Process y luego añadir tanto Steps como sean necesarios. Puede verse a continuación el orden y, también, una lista de Steps que hemos definido:

Un proyecto de Octopus está compuesto por Procesos que se ejecutan en orden. Octopus es capaz de ofrecer una enorme variedad de Pasos que podemos utilizar para preparar nuestra instancia con enorme facilidad.

El primer paso es para definir una App Pool que tendrá alojada el Web Site que vamos a desplegar. El segundo paso es para desplegar el Web Site en la Instancia.

Es importante que cada Step del Proceso pueden asignársele tags de Entorno (DEV, TEST, …) y de Role (enimbostest), siendo este último el que indica en qué Instancias va a realizarse esa operación.

 

Creación de Releases para desplegar

Para ello, crearemos un Release dándole al botón de Create Release y le daremos un identificador:

Un reléase es un lanzamiento. Cada reléase está formado por todo lo que es el proyecto en el momento de su creación: proceso, variables, etcétera. También los paquetes

Tal y como puede verse en la imagen, se recomienda que la versión del Release siga el mismo estilo que en Packages, pero con un campo más:

Num_Entorno.Version.Version.Num

El campo Num indicaría el número del despliegue para esa versión. Por ejemplo, como queremos desplegar por primera vez este Package, su versión sería: 1.1.1.1

Si creamos una nueva reléase de esta versión, sería: 1.1.1.2

De esta manera, podremos controlar nuestro proyecto fácilmente.

 

Despliegues

Una vez creado el Release, nos redirecionará directamente a él. También podemos ir al Release haciendo click en Releases, que nos mostrará todos los ya creados.

Para desplegar un Release, simplemente tenemos que darle a cualquiera de los dos botones de la derecha de Deploy. Véase:

Cada Release puede desplegarse infinitas veces. Todos los Release están disponibles aunque haya versiones posteriores, a no ser que se borren.

Una vez click en uno de los Deploys, podremos seleccionar el entorno (1) y excluir pasos (2) en este despliegue, entre otras opciones. En este caso, simplemente desplegaremos sobre el entorno DES:

Una vez le demos a Deploy (3), comenzará el despliegue y nos informará de su progreso, tal y como podemos ver a continuación:

Si vamos al servidor, podremos observar que se ha desplegado. Véase:

 

Despliegue de nuevas versiones

Dado que la web nos parece poca cosa, vamos a realizar un nuevo despliegue sobre DEV. Para ello, subiremos la nueva versión llamándola de la siguiente forma:

HelloWorldByEnimbos_DEV.1.1.2

Así quedará agrupado bajo el nombre de Package HelloWorldByEnimbos_DEV, donde podremos ver las versiones del Package.

Si queremos desplegar el nuevo Package, tendremos que crear un nuevo Release donde seleccionaremos la versión que queremos utilizar:

Desplegaremos y, una vez hayamos finalizado, podremos ver los nuevos resultados en nuestro Web Site:

¡Ahora está mucho mejor!

 

Despliegues en otros entornos

Imaginemos que este último Package, HelloWorldByEnimbos_DEV.1.1.2, queremos que salga al entorno de TEST. Para ello, subiremos el Package con el nombre:

HelloWorldByEnimbos_TEST.2.1.1

Modificamos el Process para que despliegue este en TEST:

Creamos un nuevo Release y observaremos que se desplegará en la Instancia de TEST que habíamos asignado.

Una vez desplegado, lo tendríamos listo en el entorno de TEST.

 

Conclusiones

Este ejemplo ha sido una buena visión de un Pipeline CD/CI. Hemos empezado desde el entorno de desarrollo, desplegando nuevas versiones en él y lo hemos pasado, finalmente al entorno de TEST.

Octopus se caracteriza por ser flexible. Por ejemplo: podemos hacer esto mismo con la misma versión inicial en vez de crear un nuevo Package explícito para TEST. También podemos crear otro proyecto para otro entorno, añadir un nuevo rol a una máquina, desplegar un paso o un proceso en más de un rol y/o entorno… Además, su enorme variedad de procesos nos permite llevar a cabo cualquier acción con facilidad.

Octopus ha sido uno de nuestros pilares a la hora de ofrecer soporte a nuestros clientes en el desarrollo e implementación de sus aplicaciones utilizando la base de una Pipeline CD/CI.

Related Posts