SAP Cloud Platform Continuous Integration and Delivery – Guia en 5 minutos
Introducción
Si recuerdas una de las entradas anteriores en la que recopilava algunos consejos de como empezar ( o reconducir ) un proyecto en SCP, comentava que un punto importante es tener organizado el paso del código entre distintos entornos así como tener automatizados ciertos pasos o/y testing .
Si no lo recuerdas o no lo has leído, aquí te dejo el enlace 😉
En ella te contava que puedes utilizar herramientas como Jenkins, Bamboo o el servicio de «Trasnport management» de SCP.
Hoy os traigo una guia de como realizar los transportes/test y otras tareas con otro servicio incluido en SCP llamado «SAP Cloud Platform Continuous Integration and Delivery».
Este servicio basado en docker nos permite ejecutar el flujo de acciones necesarias para llevar el código a productivo (la base de CI). Algunos pasos pueden ser: validar la integridad del código, compilar, ejecutar pruebas unitarias, ejecutar pruebas integradas y realizar el deploy.
En caso que algunos de estos pasos ejecutados de manera automática no termine de manera satisfactoria, no se transportará el código al siguiente entorno.
Para poder entrar en materia, os dejo más información en este link.
https://help.sap.com/viewer/product/CICD_OVERVIEW/Cloud/en-US?task=discover_task
Utilizando CI en SCP
Creando un proyecto nuevo o modificando el actual
Cuando creamos un proyecto nuevo con BAS, nos permite añadir una nueva funcionalidad llamada «pipeline», esto añadirá a nuestro proyecto un fichero compatible con el plugin «Blue ocean» de Jenkins.
Los siguientes hasta crear el proyecto se realizan con normalidad. Vamos con el siguiente apartado para añadir la configuración de despliegue.
Añadiendo la configuración de despliegue
Una vez creado el fichero, necesitaremos modificar el fichero de configuración del «pipeline» para que una vez realizadas las tareas de validación de software despliegue el software en la subcuenta y space indicada.
Para ello abriremos el fichero ubicado en la carpeta «./pipeline» con nombre «config.yml». Este fichero nos permite añadir credenciales para nuestros test integrados o la configuración de despliegue.
Para ello, descomentaremos las líneas finales que cuelgan de «productionDeployments» y añadiremos los siguientes datos:
- org = Nombre de nuestro subaccount, esto lo encontramos en la pestaña de overview de la subaccount
- space = Espacio al que queremos enviar el deploy
- apiEndpoint = Como en el caso del ORG, encontramos esta información en el overview de la subaccount
- appName = nombre que le queramos poner a la aplicación
- credentialsId = Id de las credenciales de despliegue configuradas en el servicio, esta parte la veremos mas adelante cuando configuremos el entorno de despliege.
Con esta sencilla modificación ya tenemos apunto nuestro proyecto para realizar despliegues. Por supuesto, podemos realizar el deploy de manera tradicional.
Por último, sera necesario subir el código a GIT para que el sistema de CI pueda recuperar el código. Os dejo un enlace de como subir vuestra carpeta ya creada a un GIT remoto, podéis utilizar por ejemplo GITHUB que es completamente gratis.
Configurando el servicio estándar
Lo primero para poder utilizar el servicio sera suscribir a nuestra cuenta (trial) el servicio. Para ello vamos al apartado de «Subscriptions» y añadimos el servicio «Continuous Integration & Delivery»
Una vez subscrito se nos habilitará la opción para acceder al link del servicio, recuerda añadir los roles a tu usuario para poder acceder en la sección «Manage Roles» ;).
Como veis el servicio es relativamente sencillo de configurar, ya que solo tiene dos opciones. Una para los pipelines y el otro para las credenciales.
Lo primero sera añadir las credenciales, así que vamos a «Credentials» para añadirlas. En mi caso, creare dos, una para la cuenta CF y la otra para GIT.
- Configuración de CF (como ejemplo): Como veis aquí añado como nombre el mismo que he añadido en la configuración del Pipeline.
- Configuración para GIT (como ejemplo):
El resultado es el siguiente:
Una vez tenemos las credenciales, ya podemos crear el job que verifica si hay modificaciones en GIT. Para ello en la pestaña «Jobs» añadiremos un nuevo Job con la siguiente configuración:
- Jobname = Nombre que queramos para identificar nuestro pipeline
- Repository URL = Url del repositorio GIT, cuando lo añadimos es importante que sea la URL que termina en «.git»
- Repository credentials = Seleccionamos las credenciales GIT que hemos creado
- Branch = Rama de la que obtener el código.
Como en el punto anterior, con estos sencillos pasos ya podemos realizar los test, deploy o lo que nuestro pipeline tenga configurado. Pasamos el ultimo punto para ejecutar el pipeline.
Ejecutando el pipeline
Para ejecutar de manera rápida el pipeline accedemos al pipeline que queramos ejecutar y pulsamos el boton play.
El proceso se inicia y podemos ver en directo en que paso esta. Tambien podemos consultar el log, aunque en el caso del log hay que ir actualizando el navegador.
Si pulsamos sobre el numero de ejecución, podemos ver el detalle de cada paso que se va ejecutando y su resultado:
En caso de error, el proceso se para (o no, en función de la configuración que hayas hecho) y podremos ver el detalle del error. En caso correcto, veremos que el hilo de ejecución termina correctamente y se muestra el color verde.
Como ves la configuración de este servicio es us muy rápida y te puede ahorrar tener que contratar otros servicios como Atlasian o Jenkins Cloud, o crear tu propia infraestructura de despliegue con (por ejemplo) AWS.
Por otro lado, este servicio se limita al despliegue de la parte SCP, por lo que quizás las opciones anteriores te pueden dar mas opciones.
En esta entrada únicamente te presento el servicio para que lo conozcas y te ayude a decidir cual es la mejor estrategia a seguir en tu infraestructura.
Como siempre dale a la campanita de notificaciones y comparte en redes para estar a la última.
