Trabajando en equipo con Google Apps Script y clasp

2
2804
muestra una melé de jugadores de rugby

Aprende en este tutorial a utilizar un proyecto de Google Apps Script de forma local usando tu entorno de desarrollo favorito, sincronizándolo con git y utilizando clasp para desplegar tus cambios.

Índice de contenidos

  1. Introducción a Google Apps Script
  2. Entorno
  3. Proyecto
  4. Clasp
  5. Sincronización
  6. Conclusiones
  7. Enlaces y Referencias

1. Introducción a Google Apps Script

Aprender a interactuar con el stack de Google con Google Apps Script en la nube aporta rapidez y una adopción temprana de un stack muy potente que permite muchos automatismos. Desde nuestra experiencia, hemos estado colaborando en un proyecto entre varios desarrolladores con Google Apps Script como aplicación web y han salido a la luz los siguientes problemas:

  • Google Apps Script no permite trabajar a dos personas a la vez. En varias ocasiones nos hemos pisado unos a otros sin que nos dé opción a arreglar conflictos.
  • El editor de código remoto no puede competir con otros como Visual Studio Code o Webstorm. No hay apenas atajos y esto penaliza enormemente la productividad
  • Ausencia de historial de versiones del código. Utilizando el editor antiguo podemos restaurar a otras versiones, pero no se aporta un visor para diferenciar cambios.
  • El editor tampoco no corrige bien el código javascript importado en la vista. Puedes tener un error sintáctico y perder mucho tiempo en saber dónde está el error.

Todos estos problemas los arreglaríamos si nos bajáramos el código a nuestro propio ordenador. Esto lo conseguimos hacer con clasp, el cliente que se comunica con Google Apps Script y te permite crear, editar y desplegar un proyecto de Apps Script desde local. Para sincronizarnos con el resto del equipo utilizaremos un sistema de control de versiones como git.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: MacBook Pro (2,5 GHz i7 4 núcleos, 16 GB 1600 MHz DDR3)
  • Sistema Operativo: Mac OS X BigSur 11.0.1
  • Node v12.13.1
  • npm 6.12.1
  • Google Chrome versión 88.0.4324.96
  • Git (2.23)
  • clasp (2.3.0)

3. Proyecto

Vamos a crear un nuevo proyecto en Apps Script muy sencillo que nos sirva de prueba de concepto. Para realizar este paso, es necesario tener o crear una cuenta de correo de Google.  Para crear el proyecto seguimos los siguientes pasos:

Entramos a la página principal de script.google.com donde vemos nuestros proyectos. Hacemos click en Empezar y más tarde otro click en la plantilla de Aplicación web de Apps Script

Imagen de creacion de plantilla de una web app en Apps Script

Se nos abrirá un proyecto nuevo de Apps Script que he titulado como ‘Mi Aplicacion Web‘.

Esta plantilla contiene 4 ficheros: Código.gs, Index.html, JavaScript.html y Stylesheet.html. Por simplificar, borramos los dos últimos y dejamos una versión muy simple de una aplicación web y redefinimos los siguientes ficheros:

function doGet() {
  return HtmlService.createTemplateFromFile('Index').evaluate();
}
<!DOCTYPE html>
<html>
  <head>
    <base target="_top">
  </head>
  <body>
    <h1>Hello world</h1>
  </body>
</html>

Desplegamos una versión de prueba, haciendo click izquierdo en el botón Implementar y luego en Implementaciones de prueba.

Implementacion de prueba por web

Se nos abrirá una nueva ventana con la url donde se alojará la aplicación web. Si entramos, veremos las palabras ‘Hello World‘. Guardamos en favoritos esta url porque representa el despliegue principal o Head deployment de nuestro proyecto. Cuando creamos un proyecto en Apps Script, automáticamente Google ya nos crea un despliegue principal con los últimos cambios que tiene el proyecto en el servidor y cada vez que guardamos se sincroniza.

Ahora que ya tenemos un proyecto dentro de la nube de Google Apps, vamos a pasar a desarrollar desde local gracias a clasp.

4. Desplegando con Clasp

Escrito en node y distribuido mediante npm, clasp nos va a ayudar a gestionar y coordinar los despliegues de nuestro proyectos. Para ello vamos a proceder con la instalación abriendo la consola e introduciendo el siguiente comando:

npm install @google/clasp -g

Lo primero que haremos será logarnos en el cliente para poder acceder a nuestros proyectos:

clasp login

Posteriormente y dependiendo de nuestro terminal, se nos abrirá una página web donde autorizaremos a clasp para que pueda leer y escribir en nuestros proyectos de Google.

Imagen que muestra cómo dar permisos al cliente Clasp en nuestra cuenta de Google

Pulsamos en el botón Permitir y ya podemos cerrar la página web y volver al terminal. Creamos una carpeta contenedora del proyecto, en mi caso mi-aplicacion-web y clonamos el proyecto con clasp.

mkdir mi-aplicacion-web
clasp clone <script_id>

Para conocer el <script_id> debemos entrar a la home de Apps Script, entrar en nuestro proyecto y seleccionar el botón de configuración tal y como mostramos en la imagen:

imagen que muestra el identificador de nuestro script

Al clonar el proyecto nos saldrá un mensaje parecido a este:

Warning: files in subfolder are not accounted for unless you set a '.claspignore' file.
Cloned 3 files.
└─ Código.js
└─ Index.html
└─ appsscript.json
Not ignored files:
└─ Código.js
└─ Index.html
└─ appsscript.json

Ignored files:
└─ .clasp.json

A partir de ahora, si necesitamos ir al escritorio remoto de este proyecto, podremos entrar desde la propia terminal:

clasp open

Si queremos ir directamente a nuestra aplicación web añadimos la opción –webapp y podremos elegir entre el despliegue principal o despliegues vinculados a alguna versión:

$ clasp open --webapp
? Open which deployment?
>   @HEAD - AKfycbwxm1aNIeCnjRpB2S_gg_X4wI2MrtaKyZLTDzRSjaY
    @7 - AKfycbyd76BT3bXiHAFSDsMgsrP7-YzJsB1qI0Xbd6GAgWOh2AM8lJ0qxNPkkEqRqYji-YaU
    @8 - AKfycbzWsE7neYx-HqgHMUutj_J2A2bwE18SqJlr9UrRiZ_hDbgpgVSwx1-6e10zh2l45jt4
    @9 - AKfycbx-0w-T-2y8sgfAsPDvLnoKRhOhWk8sAJmlgaTLqdr2qIYE_gj18yW-yu_kJU6RDOl1
    @12 - AKfycbz_32xgMJKU8sUMDKRI67zC2dzVgm6eDO_YUpKt1Pub4TS9rP0-X8zL9kHmvrGn_Mzl

Estos despliegues vinculados a una versión se mantienen en el tiempo y podremos acceder siempre y cuando no los eliminemos. Sin embargo, como dijimos anteriormente, el despliegue principal o head siempre se actualiza con los cambios que hacemos, por tanto no es un despliegue estable. Actualmente sólo tendrás un despliegue: el principal (@HEAD).

Subir cambios de local a remoto

Abrimos ahora nuestro entorno de desarrollo favorito, personalmente he utilizado Visual Studio Code, pero no es relevante para lo que vamos a hacer. Abrimos el proyecto de la carpeta mi-aplicacion-web y ya tenemos todos los poderes para modificar y añadir objetos. Si utilizas Visual Studio Code, para que éste te reconozca la sintaxis de Apps Script debes introducir el siguiente comando:

npm i -S @types/google-apps-script

Realizamos cualquier cambio en local, por ejemplo, cambiamos Hello World por otra palabra a tu elección.

Antes de poder subir los cambios, necesitamos activar la API de Google Apps Script para que un tercero (como el cliente clasp) pueda modificar nuestros proyectos. Debes entrar a la home de Apps Script y seleccionar el botón de configuración. Activaremos API de Google Apps Script que está por defecto desactivado.

imagen donde autorizamos el uso de la api de Google App Script por terceros

Para subir los cambios locales al escritorio remoto tendremos dos opciones:

Si no formamos parte de un equipo, con el propio local histórico de nuestro entorno de desarrollo nos bastaría y no necesitaríamos de un sistema de control de versiones como git:

clasp push -w
# abrimos otra pestaña de la terminal
clasp open --webapp # elegimos @HEAD

Con la opción -w (o –watch) dejamos al cliente que escuche todos nuestros cambios en local para que cuando los guardemos en local se sincronice con lo que hay en remoto.

Sin embargo, si formamos parte de un equipo la situación se nos complica un poco más.  Podemos subir nuestros cambios y justo después podemos abrir la página web del despliegue principal:

clasp push
clasp open --webapp
# elegimos @HEAD

Debemos tener en cuenta que este despliegue desde @HEAD es compartida con el resto del equipo y que tiene los últimos cambios del escritorio remoto. Si algún compañero ha hecho subido sus cambios, va a modificar también la aplicación y por tanto el @HEAD. Si refrescas la página web puede que ya no estén tus cambios.

Para evitarlo, vamos a crear un despliegue con tus últimos cambios donde le podamos dar una descripción más acorde:

 $ clasp push
└─ Código.js
└─ Index.html
└─ appsscript.json
Pushed 3 files.
$ clasp deploy -d "Despliegues de Alberto"
Created version 17.
- <ID> @17.

Ya hemos aprendido a entrar a la página web de este despliegue  con clasp open –webapp eligiendo el despliegue asociado a la versión @17 (o el número que sea en tu caso). Este despliegue será tuyo y podrás redesplegar de nuevo tus últimos cambios si lo deseas con los siguientes comandos:

clasp push
clasp deploy -d "Despliegues de Alberto" -i <ID>

Hemos de mencionar tres cosas del apartado anterior:

  • siempre haremos clasp push. Es la única manera de subir nuestros cambios y machacar lo que hubiera en el escritorio remoto.
  • debemos incluir el <ID> de nuestro despliegue para no crear un despliegue nuevo. Es importante utilizar siempre el mismo para simular un entorno local y que la url no cambie. Si no lo hacemos, iremos acumulando despliegues que generarán basura.
  • a medida que vamos haciendo despliegues vamos generando versiones de los mismos. una versión es un snapshot numerado de tu código. Las versiones son importantes porque puedes hacer uso de ellas si tu proyecto es una librería, aunque no es nuestro caso.

Con el comando clasp undeploy <deploymentId> podemos borrar despliegues no deseados o antiguos. Por otra parte, para borrar versiones tendremos que acceder desde el editor remoto usando el editor antiguo: Archivo > Gestionar versiones. Algunas versiones no se podrán borrar por tener despliegues activos referenciados.

5. Sincronización de un proyecto Google Apps Script

Como te habrás percatado ya, sólo hemos ejecutado un clasp pull y no lo haremos más pues su propósito era descargarse el proyecto en local.

Toda la sincronización con tu equipo debe ser a través de un sistema de control de versiones como por ejemplo git. En este tutorial vamos a presuponer ciertas nociones básicas de git como incorporar un proyecto a git y saber las acciones básicas. De hecho, he elegido git pero elige el que te resulte más sencillo.

Una vez tengamos el proyecto en local y sincronizado en git, un flujo de trabajo habitual podría ser el siguiente:

  1. Desarrollo una funcionalidad
  2. Para probarla, creo mi propio despliegue como ya vimos en el apartado de clasp
  3. Posiblemente no salga bien a la primera, editamos y redesplegamos con nuestro id de despliegue.
  4. Cuando estemos seguros hacemos un commit y hacemos push.

¿Parece fácil? ¿no? ¿Se te ocurre algún otro flujo de trabajo? Si es así, háznoslo saber en los comentarios.

6. Conclusiones

Hemos logrado solucionar parcialmente el desaguisado de pisarnos el código en el editor remoto de Google Apps Script. Al ser un editor nuevo con carencia de funcionalidad que sí tenía el editor antiguo es posible que su evolución nos genere alguna que otra sorpresa (para bien espero ;)). Por el momento este editor no es sostenible para proyectos que ya empiezan a tener un tamaño considerable. Tampoco olvidar que es muy cómodo tener un entorno de desarrollo local con atajos y colorines.

Espero que os sirva y sobretodo que mejore vuestra productividad.

7. Referencias

 

2 COMENTARIOS

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad