search

zetapush / zetapush-next-open-specification

Open specification for Next ZetaPush version
0 stars 0 forks source link

Gestion des environnements #46

Open damienld22 opened 6 years ago

damienld22 commented 6 years ago

Gestion des environnements avec ZetaPush Celtia

Problématiques

Comportement souhaité

Gestion des organisations

Lorsqu'on parle d'organisation ici, on parle de regroupement de comptes sur la plateforme ZetaPush.

Si je ne spécifie pas d'organisation ou que je créé un compte temporaire avec la CLI, j'ai un compte qui n'appartient à aucune organisation (ou plutôt une organisation par défaut mais transparente d'un point de vue développeur). Ensuite je peux à tout moment faire une demande d'accès à une organisation à un responsable d'une organisation.

Je peux créer une organisation via la création de compte sur https://console.zetapush.com. Le choix du nom de l'organisation se fait directement par le développeur (ou chef de projet). Si nous avons un conflit sur le nom de l'organisation, on peut contacter ZetaPush qui fera le nécessaire. (Au sens si un client souhaite créer une organisation au nom de son entreprise et que le nom n'est pas dispo). Pour moi ce n'est pas un problème prioritaire.

Résultat

Gestion des environnements

Un environnement est une "version" de l'application. Par exemple on peut avoir un client MaSuperEntreprise qui a une version de prod et une version de dev

Proposition : Chaque nouvelle application est un nouvel environnement

Pour un développeur seul, la notion d'environnements est complètement transparente. Il utilise son application et tout se passe bien. En revanche dans une entreprise, un chef de projet peut décider de créer une organisation chez ZetaPush et de créer deux applications myApp et myApp-dev.

Point de vue développeur

Voici ma proposition pour la gestion des environnements d'un point de vue développeur :

NotaBene : Le nom de l'application est dans le package.json dans le sous objet zetapush.

Prenons le cas où j'ai mes deux applications myApp et myApp-dev. J'ai au sein de mon application un service d'envoi de SMS qui a une configuration propre à chaque environnement. Voici ce que le développeur peut écrire :

index.js

import { SMS_CONFIG } from "./utils.js";

// Création du service d'envoi de SMS
// Utilisation d'une fonction qui lui affecte sa configuration
const smsService = new SmsService(SMS_CONFIG());

utils.js

// "conf-sms" défini les configurations du service
import { conf_prod_sms, conf_dev_sms } from "./conf-sms";
// Nous voulons lire le "package.json" pour récupérer le nom de l'application
const packageJson = require('./package.json');

function SMS_CONFIG {
    switch(packageJson.zetapush.name) {
        case "myApp":
            return conf_prod_sms;
        case "myApp-dev":
            return conf_dev_sms;
    }
}

Voila pour la proposition, merci d'y ajouter vos suggestions et remarques !

pablo-abreu commented 6 years ago

Si je comprends bien, utils.js et index.js sont gérés sous git. conf-sms aussi, ou pas ? si oui, pas top niveau confidentialité. si non, où est-il ?

De façon générale, quelles sont les bonnes pratiques en dév node.js pour stocker/planquer/gérer sa conf de prod pour que

damienld22 commented 6 years ago

Oui les fichiers utils.js et index.js sont gérés avec Git.

Concernant le fichier conf-sms à voir comment on peut faire. Voici deux nouvelles propositions :

Conf en local

Dans ce cas, on laisse le développeur mettre les configurations dans son code source. Ce n'est pas une bonne pratique mais il faut lui laisser le faire.

Je viens aussi de voir la proposition faite dans les spécifications dans le fichier 6-deploy.md. Cela concerne l'utilisation de la CLI pour spécifier un fichier de configuration, qui est disponible dans Git : 

zeta push --server-only --prod

C'est faisable en ayant par convention un fichier environment-prod.json pour utiliser --prod :

Cela pose problème en ce qui concerne la confidentialité des configurations mais je pense que c'est une bonne manière de faire, que l'on devrait proposer. (Angular utilise ce principe)

Conf en remote

La seconde proposition concerne un stockage de la configuration directement sur la plateforme ZetaPush. La configuration est une info gérée administrativement. C'est le principe utilisé par Firebase.

Voici un cas d'usage :

Pour le stockage des données, le chef de projet peut appeler un Cloud Service dédié ou passer par http://console.zetapush.com. Les configurations sont saisies sous forme de surcharge, et peuvent être nommées. Par exemple un développeur accède aux configurations de cette manière :

utils.js
import { ConfigurationService } from "@zetapush/server";

const confService = new ConfigurationService();

function SMS_CONFIG {
    switch(packageJson.zetapush.name) {
        case "myApp":
            return confService.get("sms-prod");
        case "myApp-dev":
            return confService.get("sms-dev");
    }

On peut aussi penser à une configuration qui est présente par défaut dans le code source. Comme ça dès qu'un nouveau développeur arrive, l'application fonctionne.

dezmou commented 6 years ago

Pouce bleu pour la méthode Firebase

aurelien-baudet commented 6 years ago

Attention quand tu parle de "version" ça peut être mal compris (même si tu explique) par rapport au concept de version en développement (1.2.0 par exemple). Ca peut laisser sous entendre que j'ai une version 1.2.0 en prod et 1.3.0 en dev.

Je ne suis absolument pas d'accord de demander à créer deux applications. C'est justement tout le principe de proposer des environnements (chose que firebase ne fait pas et qui justement OBLIGE à créer plusieurs applications parce qu'il n'y a pas le choix). Profitons-en pour nous démarquer par rapport à notre cible : un milieu d'entreprise.

L'objectif est bien d'avoir le MEME code que ce soit en dev, en prod ou autre. C'est bien la MEME application, juste déployée sur des "zones" (visibles ou non par les clients finaux) et avec une configuration différente (qui peut d'ailleurs être managée depuis la console).

Le but est également d'avoir une console claire : Je sélectionne mon app, je vois les différents environnements d'un coup d'oeil (dev, integration, recette, pre-prod, prod) et leur "santé". Tout ça fait partie du cycle de vie de l'application. En tant que chef de projet, je peux voir quelle version est en prod, laquelle va bientôt arriver en prod, laquelle est en phase de dev... On doit aussi faciliter la gestion d'un projet et non pas ajouter des contraintes parce qu'on a la flemme (je grossi bien évidemment le trait mais je répète, pour moi c'est à nous de faire les efforts pour que ce soit simple et non pas demander à nos utilisateurs de faire avec ce qu'ils ont).

damienld22 commented 6 years ago

Oui je suis d'accord qu'on peut apporter mieux. Dans cette optique j'ai réfléchi à ça, qu'en pensez vous :

Nouvelle proposition de la gestion des environnement

Ce que je souhaite en tant que chef de projet :

Ce que je souhaite en tant que développeur :

Cas d'usage

Je suis chef de projet et j'ai mon application nommée myApp. Je veux créer deux environnements (dev et prod). Pour ceci je passe par ma console. Je vois aussi que mon environnement par défaut est "dev", cela évite que les développeurs poussent du code sur le mauvais environnement.

À présent je souhaite gérer ma configuration selon mon environnement. J'ai un service d'envoi de SMS et un d'envoi de mail. Pour les configurer, je vais remplir un formulaire (clé-valeur), uploader un fichier ou écrire un texte brut (Voir pour plus de choix), bref, j'ai le choix de comment j'écris ma configuration. Je fais cette saisie dans un premier temps pour l'environnement de "dev" (On commence par n'importe quel environnement).

À présent, je souhaite écrire la conf de mon environnement de prod, mais j'ai seulement une valeur qui change par rapport au dev. Je spécifie donc que ma configuration hérite de "dev" et je surcharge seulement la donnée qui m'intéresse.

Pour rendre la configuration accessible aux développeurs, je spécifie un mot clé dans ma console. Par exemple mon environnement de prod sera : prod et mon environnement de dev sera dev.

Je suis développeur et je travaille sur myApp. Je ne m'embête pas à gérer la configuration, je sais que mon chef de projet s'est occupé de ça. Pour travailler j'importe la configuration de mon service de sms de cette manière :

index.js

import { ConfigurationService } from "@zetapush/server";

// Création du service d'envoi de SMS
// Appel du service de configuration pour récupérer la bonne conf automatiquement
const smsService = new SmsService(ConfigurationService.get());

Dans ce cas, la configuration récupérée dépend du package.json dans le champs zetapush > environment.

Si je souhaite utiliser la CLI je peux faire :

zeta push --server-only --prod

Dans ce cas, c'est la configuration spécifiée dans la CLI qui prend le dessus.

Voici le format du package.json :

// ...
"zetapush": {
    "front": "./front", // Optionnel,
    "back": "./server", // Optionnel,
    "name": "myApp",
    "environment": "dev", // Optionnel
}
// ...

Je laisse bien-sûr le choix au développeur de mettre sa configuration dans son Git et de ne pas appeler notre Cloud Service de configuration.

aurelien-baudet commented 6 years ago

Beaucoup mieux je trouve. J'ajouterais quand même deux choses :

aurelien-baudet commented 6 years ago

Pour info, n'hésitez pas à regarder ce que propose Travis CI sur la gestion des variables d'environnement. C'est très simple mais très pratique.

damienld22 commented 6 years ago

En ce qui concerne la sécurité, chaque créateur d'organisation (voir le premier post) gère les droits. Il peut par exemple décider qui pousse en prod, qui peut changer une conf, qui peut créer un nouvel environnement, etc...

Je te rejoins @aurelien-baudet sur le fait que le fichier de configuration dans le code soit la conf par défaut et que ce soit le merge des deux (avec la conf dans la console) qui soit effectif. On pourrait notamment donner la possibilité depuis la console de donner les ordres de priorité sur les configurations à prendre en compte.

pablo-abreu commented 6 years ago

"Par contre dans certaines sociétés que je connais bien, les devs développent mais ne mettent pas en prod"

Je dirais même plus :

sinon, question : quand je clone une sandbox, est-ce que je clone la conf ?

damienld22 commented 6 years ago

@pablo-abreu Oui tout l'intérêt d'avoir une gestion de droits dans l'organisation.

Concernant le clone je pense qu'à présent on devrait parler de clone d'application. Donc selon moi la conf est liée à l'application et devra donc être clonée.