En naming en desarrollo es importantísimo. Cuando empecé en esto, recuerdo «discusiones» en el equipo que podían durar 10-15 minutos para elegir el nombre de un método o una variable. «Mi no entender» pensaba, si solo es un nombre. ¡Que equivocado estaba! Yo venia de estudiar y de usar variables llamadas «aux, aux2, sum», etc.
Para tener una consistencia dentro de un mismo proyecto basado en Azure, es necesario establecer una convención de nombres para los recursos de Azure en la que apoyarnos a la hora de crearlos. Ya sabes como moverte por el portal de Azure para crear estos recursos, ahora debes ponerles un buen nombre.
Pueden existir muchas estrategias a la hora de elegir la convención adecuada, y todo dependerá del proyecto en el que trabajes y del equipo con el que colabores, pero aquí expongo mi propuesta.
Para poner un nombre a los recursos de Azure, podemos basarnos en los siguientes parámetros:
- Nombre del proyecto
- Entorno donde va a estar el recurso
- Tipo de recurso
Para los entornos puede usar una definición de tres caracteres: dev, pre, pro, uat, stg…
Para elegir el prefijo en el tipo de recurso, existe una tabla creada por Microsoft, que puedes ver aquí.
Hay que tener en cuenta que algunos tipos de recursos tienen ciertas restricciones en el nombre, por ejemplo, Key Valult o Storage no pueden tener espacios. En esta guía de Microsoft se pueden ver estas reglas.
Recursos en distintas regiones e instancias
Si las necesidades del proyecto nos llevasen a tener recursos redundados en distintas regiones y/o instancias, podemos usar dos parámetros más:
- Región del recurso
- Número de instancia del recurso
Para la representación de región, se puede utilizar un número de dos dígitos que identifique cada una de las regiones. Hay muchas regiones y van apareciendo nuevas, por eso propongo un número que se tendría que definir a nivel de proyecto, según nuestras necesidades.
Por ejemplo:
01 – West Europe
02 – West Us
La instancia será también un número incremental que represente a cada instancia de dos dígitos: 01, 02…
Así pues, nos queda una convención como: {proyecto}-{entorno}-{tipo_recurso} y en el caso de tener redundancias en zonas distintas: {proyecto}-{entorno}-{tipo_recurso}-{zona}
Para los servicios que no acepten el símbolo «-«, la convención será: {proyecto}{entorno}{tipo_recurso} o {proyecto}{entorno}{tipo_recurso}{zona}
Ejemplos de nombres de recursos
Grupo de recursos: contoso-dev-rg
Key Vault: contosodevkv
Storage: contosoprest
Si tenemos un app service plan redundado en dos zonas:
West Europe = 01
East US = 02
contoso-pro-plan-01
contoso-pro-plan-02
Para servicios no vinculados a una suscripción, como pueden ser maquinas virtuales, por ejemplo, obviaremos el entorno.