Livraison continue pour le projet multi-composants

Question

Dans notre projet, nous avons plusieurs composants développés par des équipes distinctes ayant des repos git séparés. Tous les composants ont un travail de travail et d'emballage de validation et publie les artefacts dans artefact.

Le problème survient lorsque nous voulons déployer tous les composants en tant que système.

Étant donné que tous ces composants se déploient sur des serveurs distincts, puis interagissent entre eux pour fonctionner. Beaucoup d'incohérences de temps se produisent en raison de la nouvelle version d'un composant déployé sur l'un des serveurs.

Par ex. J'ai les composants A, B, C et je veux déplacer les versions suivantes A1, B1, C1 dans le pipeline de déploiement et de test. Comment puis-je m'assurer qu'aucune version plus récente d'un composant n'est déployée dans un environnement d'assurance qualité (serveurs). J'utilise Jenkins comme outil CI/CD. Il semble que j'ai besoin d'un outil d'intégration ou de gestion de la configuration légère pour gérer le versionnement de mon système dans son ensemble comprenant tous les composants que je peux promouvoir dans le pipeline de déploiement.

J'espère pouvoir décrire ma question. Des suggestions pour s'attaquer à cette situation seront vraiment utiles.

Merci,

Answer 1

Nous utilisons ce modèle: pour chaque client

• qui utilise nos produits il y a un « projet »: Il contient presque pas de code, une configuration. Nous utilisons ce schéma de nom: coreapp_customerslug.
• le projet dépend de N applications. Le projet épingle toutes les versions exactes des dépendances.

Pendant CI nous le faisons:

1. projet d'installation P et toutes les dépendances épinglés
2. puis mettre à jour toutes les dépendances à leur dernière version.
3. Exécuter tous les tests
4. Si tous les tests aboutissent, mettez à jour les versions des dépendances et incrémentez la version du projet.
5. Maintenant, le projet a une nouvelle version stable.
6. déployer la nouvelle version (pour le moment, nous ne le faisons pas automatiquement, mais dans un proche avenir).

Avec ce motif ("projet" est un conteneur des applications) vous pouvez gérer le problème de version. Si vous avez plusieurs serveurs, le processus de mise à jour doit être rapide, pour éviter différentes versions en même temps.

Mise à jour

Le CI maintient les versions épinglés. Nous utilisons python et pip et le fichier requirements.txt est mis à jour par un script. Nous utilisons le schéma de version YYYY.N. N est incrémenté si tous les tests sont corrects.

Attention: Si app1 a la dernière version N, cela ne signifie pas que cela fonctionne dans tous les projets. Si vous avez deux projets: P1 et P2, cela peut arriver: app1 avec la dernière version N fonctionne bien dans le projet P1, mais échoue dans P2. Cela signifie que vous ne pouvez pas créer une nouvelle version stable du projet P2.Parfois, c'est ennuyeux, mais cela maintient une mise à jour constante en vie. Nous utilisons toujours la dernière version de nos applications dans nos projets.