Comment gérez-vous la gestion des versions dans un projet à plusieurs faces?

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?

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é.

Ce message fait un point intéressant sur votre question.

De manière plus pratique, si vous avez 3 composants:

• 2 Consommateurs: un frontal et une application mobile
• 1 fournisseur d'API: un back-end

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.mtel 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 un M.m+1, M+1.m+1ou M+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

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:

1. Chaque composant sera versionné lors de sa sortie. Cela inclut les bibliothèques de bas niveau ainsi que vos produits finaux.
2. Chaque validation de code déclenchera une génération d'instantanés. Cela aide à garder vos développeurs honnêtes, surtout si vous utilisez la fonction pour envoyer un e-mail au coupable qui a cassé la version.
3. Chaque build peut exécuter des tests unitaires. Cela améliore considérablement la qualité du code.
4. Chaque version sera étiquetée, donc si un correctif de production est requis, il est facile de dériver le tag et de faire le correctif.
5. Vous devrez tenir un registre de compatibilité quelconque. (par exemple, BackOffice 1.0.23 est compatible avec l'API REST 2.0.267, etc.). Je ne connais pas d'outil qui puisse aider dans ce domaine.

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.

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]

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:

1. Contrôle de version - Le contrôle de version est un outil de gestion de configuration qui vous aide à garder une trace des instantanés et de l'historique de votre développement. TOUT CODE DOIT ÊTRE SOUS CONTRÔLE DE VERSION. Je me fiche que ce soit juste les scripts de commodité que vous ajoutez à votre dossier bin, tout ce qui valait la peine d'écrire du temps vaut les deux secondes à ajouter à un logiciel de contrôle des révisions.
2. Gestion de la configuration - Comment contrôler le contenu de la build. Tous les logiciels devraient avoir un certain degré de gestion de la configuration. J'aime décrire aux gestionnaires la différence entre le contrôle de version et la gestion de la configuration, car le contrôle de version n'est qu'un outil pour suivre l'historique du développement, tandis que la gestion de la configuration est la ligne directrice pour la création de l'historique et la manière dont nous décidons le code est bon.
3. Versionnage du logiciel - attribution de noms aux versions de code. C'est la chose que beaucoup de gens verrouillent lorsqu'ils voient le problème pour la première fois parce qu'ils ont l'habitude de voir "MineSweeper 7.1.29290149210" ou quoi que ce soit sur les trucs qu'ils achètent, mais honnêtement, je trouve que c'est la partie la plus mineure d'un problème beaucoup plus important. Pour être honnête, il suffit d'utiliser le hachage généré par 1 et de ne pas se soucier tant que son non lisible par l'homme est parfaitement bien à faire.

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:

1. Comment puis-je garder une trace des versions (et des problèmes associés avec elles) que je supporte sur le marché?
2. Comment vais-je décider quels chemins de développement sont prêts à être publiés sur les systèmes de production? (Il pourrait également être prêt pour toute autre étape d'un processus)
3. Qui devrait contrôler / gérer la configuration du système? Quel est le flux de travail pour ajouter du code à distribuer à d'autres développeurs?
4. Comment vais-je contrôler l'interaction entre les parties en interaction? Comment saurai-je si le changement d'une pièce cassera le reste du système?
5. Comment allons-nous améliorer notre système de gestion de configuration au fil du temps.

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.