Je suis un développeur Angular 1 expérimenté qui lit maintenant sur Angular 2. Nous prévoyons de faire un grand projet qui consiste en un certain nombre de petites applications qui se chevauchent et qui utilisent la même télécommande API Je suis intéressé par votre avis sur la façon de configurer ce projet en ce qui concerne la bonne gestion de projet, d'autant plus que ma connaissance de git est limitée. Pensez-y un peu comme les produits de Google où un utilisateur peut utiliser ou non plusieurs produits avec le même compte. Certaines données et «widgets» sont utilisés dans plusieurs produits, tandis que certains composants sont spécifiques à un produit. Il ressemble à quelque chose comme ça (pièces d'orange sont des composants réutilisables pour tous les produits):Meilleure façon de configurer mon projet Angular
Plus de détails:
- Nous n'avons pas à vous soucier de l'API back-end, etc. C'est tous pris en charge de.
- Il devrait y avoir une 'app conteneur' qui gère les auth, les sessions etc et qui a quelques éléments de menu qui permettent à l'utilisateur de passer d'un produit à l'autre (de préférence toujours dans l'application conteneur). Je souhaite gérer les produits (tous les éléments en pointillés gris) séparément en termes de git et de déploiements (par exemple, je ne veux pas avoir à déployer tous mes whitelabels chaque fois que j'en mets à jour un). Je voudrais pouvoir avoir des composants plus petits réutilisables que je peux mettre à jour dans tous les projets dans le flux de travail de l'édition d'un de mes projets. Donc disons que je travaille sur le whitelabel du client Y et que je veux éditer un de mes composants réutilisables que j'utilise là-bas, je ne veux pas ouvrir un projet séparé, pousser les mises à jour et ensuite mettre les mises à jour dans mon whitelabel projet pour chaque petit changement que je fais.
Questions:
- Que cela ressemblerait-il en termes de gestion de projet (git)?
- Où mes services correspondent-ils à cette API?
J'espère que c'est une histoire assez claire. S'il vous plaît demandez si je peux expliquer quelque chose de mieux.
C'est une bonne question mais j'ai peur que ce soit un peu trop large. De plus, les points 3 et 4 semblent pouvoir se contredire. Pour réussir avec ce type d'architecture, vous devriez vraiment déployer vos composants en tant que paquets (npm/bower/etc) que vous pouvez versionner indépendamment. Le mode de déploiement dépend en grande partie de ce à quoi ressemble votre configuration de déploiement continu (c'est-à-dire le pipeline Jenkins-> Sinopia), mais il s'agit également d'un autre long sujet. – axlj