La solución aquí explicada está enfocada a skills de Amazon Alexa, pero sirve para cualquier otro software que utilice funciones lambda de Amazon Web Services y que no queramos arriesgarnos a que deje de funcionar cuando modifiquemos el código fuente de la función Lambda AWS.
La solución consiste en utilizar alias y versiones en las funciones Lambda y no utilizar el ARN por defecto (o Unqualified ARN) de la función Lambda como endpoint.
Cuando creamos una función Lambda, por defecto solo tiene la versión «LATEST» y esta versión tiene un ARN (Amazon Resource Name) que aparece en la parte superior derecha del editor de la función Lambda. Por otro lado, desde el panel de desarrolladores de skills de Alexa, podemos configurar que nuestra skill invoque a una determinada función Lambda, especificando el ARN de dicha función Lambda. Es una mala práctica utilizar el ARN por defecto de la versión «LATEST», por los siguientes motivos:
- Si realizamos cambios en el código de nuestra función (por ejemplo, mientras desarrollamos la versión 2), corremos el riesgo de romper la skill que hay ya publicada.
- No podremos utilizar el versionado de funciones que ofrece AWS Lambda, por lo que no podremos tener una versión de la función usándose por la skill publicada y otra versión en desarrollo para la versión 2 de nuestra skill.
Lo correcto será utilizar alias y versiones. ¿Qué son?
- Una versión es una «foto» del código fuente de nuestra función, que realizamos en un momento concreto y que nunca podrá modificarse. Esta foto tiene una descripción y un nº de identificación. Cada versión tiene un ARN del tipo «ARN por defecto de la función»:»nº versión».
- Un alias es un «link» dinámico a una versión. Al crear un alias indicaremos un nombre y una versión, pero en cualquier momento podremos editar el alias para que apunte a otra versión. Cada alias tiene un ARN del tipo «ARN por defecto de la función»:»nombre del alias»
No usaremos directamente el ARN de una versión como endpoint de nuestra skill, ya que si quisiéramos corregir un error en producción no podríamos: las versiones no son modificables y cambiar el endpoint de una skill en producción requiere volver a pasar por el proceso de certificación (+-5 días laborales).
Sí que usaremos los ARN de los alias como endpoint de nuestra skill, ya que en cualquier momento podremos hacer que un alias apunte a otra versión de la función si hiciera falta.
Pasos para trabajar correctamente con versiones y alias:
1. Creamos nuestra función lambda. Por defecto solo tendrá una versión (LATEST, la única editable). No usaremos el ARN por defecto.
2. Creamos un alias, con nombre «alias publicación 1», y lo configuramos inicialmente apuntando a la versión LATEST.
3. En este alias y en los futuros alias que creemos, tendremos que configurar como trigger «Alexa Skill Kit» y por seguridad indicar el Skill ID de nuestra skill.
4. Configuramos nuestra skill para que utilice como endpoint el ARN de «alias publicación 1».
5. Cuando el código de nuestra skill esté terminado, enviaremos la skill a publicar.
6. Durante el proceso de certificación de nuestra skill, recomiendo no tocar el código de la función Lambda.
7. Cuando finalmente certifiquen y publiquen nuestra skill (puede costar un poco las primeras veces, revisa estos consejos), crearemos una versión «1» y editaremos el alias existente «alias publicación 1» para que ahora apunte a la versión «1» en lugar de a LATEST.
8. Con la skill ya publicada (live) y el código congelado en la versión «1», podemos trabajar en la siguiente actualización de nuestra skill. Crearemos un nuevo alias «alias publicación 2» que apunte a la versión LATEST.
9. En el panel de skills veremos que las skills live no son editables pero tienen una versión de desarrollo (in development) que sí podemos modificar. Modificaremos esta skill in development para que su endpoint sea el ARN de «alias publicación 2».
10. Al llegar a este punto, la versión live de la skill utiliza una versión «1» no editable de la función Lambda, mientras que la versión «in development» utiliza la única versión editable de la función Lambda. Podremos trabajar sin problemas en la actualización del código de nuestra skill sin miedo a romper la versión que hay en producción 🙂 .
Cuando la nueva actualización esté terminada, repetiremos los pasos 5-9, pero creando una versión «2» y un alias «alias publicación 3», etc.
Bonus: ¿Qué hago si tengo una versión en producción y quiero corregir un error en su función Lambda?
Ejemplo: Skill live, que usa como endpoint un alias «alias publicación 1» que a su vez apunta a la versión «1». He tardado varios días en detectar el error en la función Lambda y he estado trabajando en otra actualización ajeno a ese error (es decir, se ha modificado el código en la versión LATEST y es posible que no sea compatible con el skill live).
1. Para no perder los cambios realizados en la versión LATEST y que me servirán en el futuro, crearemos una versión.
2. A continuación partiremos del código de la versión «1» y lo importaremos en la versión LATEST. Esto podemos hacerlo exportando la versión «1» como ZIP e importando el ZIP en la versión LATEST:
Para corregir el error y testear:
3. Editaremos el alias «alias publicación 1» para que apunte temporalmente a la versión LATEST.
4. Una vez solucionado el error, crearemos una nueva versión (ponerle de descripción «versión 1 fixed») y haremos que «alias publicación 1» apunte a esta nueva versión.
5. Es importante mencionar que, como el error estaba en la función Lambda y no en el modelo de la skill, no hará falta a enviar de nuevo a certificación nuestra skill.
6. Finalmente, podremos seguir trabajando en la próxima actualización de nuestra skill, sobre el código de la versión LATEST. Si estamos utilizando un repositorio de código como GIT, haremos merge del fix y el código de la nueva actualización.
[…] creado un rol previo para temas de permisos en AWS pero es sencillo. Os recomiendo también trabajar en base a versiones de la función que habéis creado. Os dará flexibilidad y control a la hora de […]