Je sais que c'est une vaste question, je vais donc essayer d'être aussi précis que possible. Cette question est plus une question «organisationnelle» qu'une question technique.
Nous avons un projet multi-faces avec ces composants principaux:
- Un serveur, hébergeant la logique métier principale (modèles de données)
- Un backoffice pour les clients qui utilise la logique métier principale
- Une API d'application (REST) qui utilise également la logique métier principale
- Il existe des applications pour smartphone (iOS et Android) utilisant l'API d'application
- Il existe une autre application pour tablette (Android) différente de celle pour smartphone utilisant la même API d'application.
Bientôt, je serai en production avec des clients actifs. Et comme tout projet, je devrai maintenir tous les différents composants au fil du temps. Cela signifie que tous les éléments suivants peuvent être mis à niveau:
- le code de la logique métier principale du serveur (utilisé par le back-office, l'API et, comme effet secondaire, par les applications mobiles)
- l'API elle-même (utilisée par les applications pour smartphones et tablettes)
- toutes les applications mobiles (via appstore / googleplay)
Bien sûr, les parties côté serveur (code logique métier et code API) peuvent être modifiées immédiatement par moi-même. Cependant, les nouvelles applications mobiles doivent être téléchargées par les clients sur l'appstore / googleplay, et je ne peux pas être sûr qu'elles sont à jour.
Pourriez-vous fournir des conseils, des conseils de bonnes pratiques, pour rendre ces mises à niveau fluides et sans risque pour le client?
De quel composant ai-je besoin pour "version"? Comment s'assurer que tout fonctionne même si le client ne met pas à jour son application mobile? Dois-je le forcer à mettre à niveau pour faciliter mon travail?
En un mot, comment dois-je m'organiser pour faire vivre mon projet multi-faces dans le temps?
Réponses:
Comme vous ne pouvez pas contrôler quand les applications mobiles seront mises à jour vers une nouvelle version, vous devez au moins mettre à jour votre API REST. Si vous ne le faites pas, il sera impossible d'apporter des modifications incompatibles en amont à cette interface.
Outre l'API REST, c'est une bonne idée de versionner également les autres interfaces de communication qui passent par une interface réseau. De cette façon, vous n'êtes pas non plus obligé de mettre à niveau tous les clients backoffice en même temps que les serveurs et vous pouvez implémenter une migration progressive vers une nouvelle version avec une période de «beta test».
Outre la version des interfaces de communication, vous devez également essayer de rendre les modifications rétrocompatibles autant que possible. Idéalement, vous pourriez déployer une nouvelle version d'interface qui prend toujours pleinement en charge les anciens clients afin qu'ils ne remarquent rien a changé.
la source
Ce message fait un point intéressant sur votre question.
De manière plus pratique, si vous avez 3 composants:
Vous pouvez utiliser le schéma de version Mmp (Major.minor.patch) typique pour chacun, mais, sur votre URL principale, vous pouvez mettre quelque chose comme
http://youhost/M.m/resourceURI
.Au fur et à mesure que vous évoluez et que les modifications de l'API n'affectent pas votre contrat avec les consommateurs que vous conservez
M.m
tel quel dans l'URL. À partir du moment où vous effectuez un changement dans le BackEnd qui affecte vos consommateurs (que ce soit un changement de comportement ou un objet différent), vous utilisez unM.m+1
,M+1.m+1
ouM+1.m
.La façon de faire fonctionner les choses consiste à déployer le nouveau back-end en même temps que l'ancien, pendant que vos utilisateurs installent les nouveaux consommateurs et arrêtent lentement l'ancienne API.
Vous pouvez voir une meilleure réponse que la mienne ici: Versioning de l'API REST sur Stackoverflow
la source
Je vous recommande d'installer un serveur d'intégration continue, de le connecter à votre référentiel de code et à un référentiel d'instantanés / versions et d'automatiser vos builds. Cela aura un certain nombre d'avantages:
Mon expérience a été avec des outils open source: SVN, Maven 2, Jenkins et Nexus, mais il existe des alternatives à tout cela.
Ne sous-estimez pas le temps d'apprentissage pour mettre votre équipe au courant. Mais une fois qu'ils seront à jour, ils ne reviendront jamais.
la source
Pour une équipe relativement petite pour le développement et le déploiement, le modèle de compatibilité Client N-1 tel qu'employé par IBM Jazz peut très bien fonctionner
Essayez de conserver les clients et les serveurs au même numéro de version. [Au lieu de gérer une matrice de versions indépendantes et leurs compatibilités]
Définissez une stratégie selon laquelle la version client Xyy devrait fonctionner avec toutes les versions de serveurs supérieures à Xyy mais inférieures à X + 2.0.0
Pour une version de serveur 4.0, il devrait idéalement y avoir une version client 4.0 pour chaque type de client. Cependant, la compatibilité doit être maintenue afin de permettre des versions légèrement différentes des clients et des serveurs.
Une version client 4.x doit être compatible avec les serveurs version 4.x et supérieure mais inférieure à 6.0; Un serveur 4.x doit être compatible avec tous les clients version 3.0 et supérieure mais inférieur ou égal à 4.x
De cette façon, vous pouvez mettre à jour une version sur le serveur sans vous soucier de la sortie immédiate des nouvelles versions des clients, mais vous n'aurez qu'une fenêtre de compatibilité bien définie à maintenir.
Réf: IBM Jazz Model [ https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]
la source
Tout d'abord, je vais commencer par définir le problème un peu différemment. Vous avez demandé de quels logiciels vous avez besoin de "version". La version est un terme surchargé dans CS, et pourrait signifier environ 100 choses différentes. Les principales choses que je regarderais sont:
Donc, comme c'est le plus nébuleux et le plus intéressant pour moi, je vais me concentrer sur le # 2. Il n'y a pas de solution unique et unique pour la gestion de la configuration. Les règles qui fonctionnent bien pour une équipe de 2 ou 3 personnes peuvent être trop lâches pour garder la raison dans un projet qui prend des centaines de travailleurs. Les règles qui fonctionnent dans la grande équipe peuvent nécessiter beaucoup trop de frais généraux pour la petite équipe. Vous devrez probablement bricoler quelque chose pour créer quelque chose, mais j'utiliserais la liste suivante pour développer les spécifications de votre système de gestion de configuration:
Besoin d'aide pour répondre aux questions ci-dessus? Vous devriez probablement embaucher un consultant ou un responsable de l'ingénierie logicielle ... une réponse qui peut remplir des manuels et est bien hors de portée pour ce type de forum.
la source