Despliegues en BigCommerce con Bitbucket Pipelines

Transformando nuestro flujo de trabajo e-commerce: Implementando despliegues automáticos en BigCommerce con Bitbucket Pipelines

En el dinámico mundo del comercio electrónico, es esencial contar con procesos que permitan actualizaciones rápidas y eficientes de nuestras plataformas. Esta publicación nos llevará a través del proceso de configuración e implementación de despliegues automáticos en BigCommerce utilizando Bitbucket Pipelines, una solución de integración y entrega continua (CI/CD).

No sólo ganaremos velocidad y eficiencia, sino que también minimizaremos los errores humanos, proporcionando a nuestros clientes una experiencia de compra más fluida y segura. ¡Comencemos!

En Ebolution, desde hace algo más de año y medio decidimos apostar por la incorporación de BigCommerce como plataforma de e-commerce dentro del abanico de tecnologías con las que trabajamos desde hace mas de una década.

Siempre que incorporamos una nueva tecnología se pone de manifiesto la necesidad de trasladar prácticas que ya dominamos al contexto en el que comenzamos a incursionar. Una de esas prácticas es la forma cómo desplegamos nuestros cambios de código para que puedan estar disponibles en un entorno de pruebas, o en una tienda real.

Es importante acotar que en adelante me refiero a temas basados en Stencil y alojados por la propia plataforma BigCommerce, es decir, el escenario estándar de desarrollo de tiendas dentro de esta tecnología.

Antes de avanzar pongámonos en situación con respecto a nuestra operativa habitual en Ebolution:

1. Somos una agencia de desarrollo e-commerce con cerca de 20 profesionales en sus equipos técnicos.

2. Algunas de esas personas trabajan en equipos itinerantes participando en más de un proyecto a la vez.

3. Atendemos a varios clientes dentro de un mismo espacio temporal.

4. En algunos casos los clientes también cuentan con técnicos capacitados para escribir código y aportar a sus propios proyectos.

5. Utilizamos al menos dos o tres entornos o tiendas operativas por cada proyecto (Pruebas de aceptación, Preproducción y Producción).

6. En la plataforma BigCommerce es posible modificar en línea buena parte de los ficheros que componen sus temas basados en Stencil.

Si no hay un mínimo de control, el caos está servido

En estos días escuchaba a alguien decir que para que el trabajo de una agencia tenga una mínima posibilidad de escalar deben existir procesos, y no puedo estar más de acuerdo. Ahora un ejercicio de atención: venga, pregúntame donde escuché esto y te lo cuento en los comentarios, y ya si te suscribes tienes nota.

Después de un largo preámbulo, la realidad es que esta publicación va de eso, de un proceso interno que nos ayuda a mantener a raya el caos potencial que se cierne sobre nuestras cabezas, y que nuestros proyectos estén organizados de forma tal que podamos dedicar mucho más tiempo a las necesidades de nuestros clientes, en lugar de tener a equipos de desarrollo lidiando con particularidades innecesarias que matan tanto la creatividad como la productividad.

Venga, ahora el Rock and Roll. Te voy a hablar de Git, Node, Stencil CLI, Docker, pipelines, etc, pero no te voy a explicar en detalle cada concepto, no quiero bajar al detalle porque mi intención es contarte como pensamos un proceso pequeño pero efectivo dentro de la cotidianidad de una tarea que a simple vista parece ser bastante sencilla, pero que con mucha gente tocando al mismo tiempo se puede ir rápidamente… al desastre.

Así que ahora tienes al menos dos opciones: 1) esas palabras que he mencionado antes te suenan a chino pero sigues leyendo por descubrir nuevos conceptos, o 2) las conoces a la perfección y me sigues leyendo por si acaso con nuestra experiencia te ayudo en algo.

En ambos casos, sabemos que sigues leyendo por lo guay que escribo… (pausa: ¿de verdad voy a publicar esta frase tan innecesaria?… parece que si).

Bueno basta de autopromoción, que vais a creer que de verdad pienso eso. Continuemos.

Un repositorio para controlarlos a todos

Primero lo primero, los temas que usamos en las tiendas son código, el código evoluciona. La evolución del código tiene que quedar registrada en un repositorio de control de versiones, Git. Fin de la discusión.

Aquí no valen los ficheros: portada.html, portada-01.html, portada-01-OK.html, portada-01-OK-ahora-si.html, portada-esta-es-la-buena.html, portada-alskdjalskjd.html. Esta práctica es parte de un pasado oscuro, de la prehistoria. Esa puerta la cerramos hace mucho tiempo.

Este repositorio será el que usemos para controlar la forma cómo se suben los cambios al entorno que corresponda, dependiendo de las funcionalidades que ofrece la herramienta de gestión de repositorios que usemos, que en nuestro caso es Bitbucket y específicamente su herramienta Pipelines.

Dentro de las múltiples formas que hay de plantear una solución, reduciremos el espectro a dos acciones concretas: las subidas a la rama develop lanzan un despliegue hacia el entorno de UAT, y las subidas a la rama main lanzan un despliegue hacia el entorno de producción (PRO).

¿Flujo de trabajo o cadena de procesos?

Por lo habitual intento evitar los anglicismos, considero que nuestra lengua tiene suficientes palabras para ello, pero también muy a menudo me encuentro en esta disyuntiva, en este contexto, referirse a un “Pipeline” es bastante más claro que a una “Cadena de procesos”.

Para configurar un pipeline en Bitbucket lo primero que hace falta, después de activar la opción en la configuración del repositorio, es añadir al proyecto un fichero llamado bitbucket-pipelines.yml. Dicho fichero se estructura más o menos así:

image: ebolution/bigcommerce-stencil-cli
pipelines:

Aquí se indica a Bitbucket que para iniciar el trabajo parta de una imagen de Docker que hemos preparado con una versión de Node específica (la 18 actualmente), y donde hemos instalado previamente la herramienta stencil-cli.

Pasamos a las acciones automáticas. Como decidimos que son las subidas de código a ramas particulares las que disparan los despliegues, el siguiente bloque se ve así:

    branches:
        main:
            - step:
                script:
                    - npm install
                    - export NODE_OPTIONS=--openssl-legacy-provider
                    - stencil init --url $PRO__STORE_URL --token $PRO__API_TOKEN --port 3000
                    - stencil push -a Light

Lo más importante de esta sección es esta línea:

- stencil init --url $PRO__STORE_URL --token $PRO__API_TOKEN --port 3000

Puesto que es la acción que distingue el entorno hacia el que se lanzará el despliegue de acuerdo a la rama que apuntamos.

El siguiente bloque corresponde a la rama develop y al entorno de UAT. Todo es exactamente igual, salvo que las variables son: $UAT__STORE_URL y $UAT__API_TOKEN:

        develop:
            - step:
                script:
                    - npm install
                    - export NODE_OPTIONS=--openssl-legacy-provider
                    - stencil init --url $UAT__STORE_URL --token $UAT__API_TOKEN --port 3000
                    - stencil push -a Light

Lo siguiente que debemos hacer, naturalmente, es configurar las variables en Bitbucket para que el proceso obtenga los datos reales.

Importante en este punto la visibilidad de las variables. Puesto que los tokens de API son datos sensibles, los marcamos como privados.

Al momento de subir nuevo código a develop o main se lanzará el proceso automático, cuyo resultado se verá más o menos así:

Y pispás, eso sería todo.

Lo planteado hasta ahora se puede mejorar de varias formas, usando caché, asignando nombres a los despliegues, asignando las variables por despliegue y no por repositorio, integrando pasos dentro del contenedor de Docker y muchas cosas más, sólo me he quedado en la superficie para no introducir tantos conceptos que realmente no iba a explicar, y porque con esta configuración el problema principal queda resuelto.

Siguientes pasos

Con esta configuración en marcha lo primero que ganamos es que la entrega de código esté centralizada en un mismo punto y controlada por un proceso automático, para un escenario como el que describía al principio, sólo eso ya es una ventaja considerable.

No obstante, la herramienta Pipelines ofrece una gama tan amplia de opciones como podamos imaginar, por ejemplo, ejecutar pruebas automáticas antes del paso de despliegue, ejecutar acciones específicas del proyecto en el que trabajamos, lanzar notificaciones al inicio y final del proceso de despliegue, ejecutar pruebas end-to-end después de acabar el despliegue, y un largo etcétera tan extenso como complejo o completo queramos hacerlo.