You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Le fonctionnement actuel en version bloque le déploiement de tout un tas de connectifs / améliorations assez triviaux, parce qu'il faut attendre pour qu'ils soient déployés que la version soit prête et testée, et que comme dans toute version, on voudrait bien que les fonctionnalités X et Y soient embarquées, et donc correctement testées, etc.
C'est long et apporte de la latence, mais c'est encore le processus le moins pire qu'on a trouvé avec nos outils et contraintes.
L'exemple inverse, ce serait une intégration continue dans laquelle tout ce qui est mergé sur prod est automatiquement déployé en prod. Sauf que ça pose d'autres problèmes, notamment dès qu'une version nécessite des opération manuelles pour être déployée.
Or donc voici qu'au boulot on utilise GitLab (une instance locale), qui vient avec une intégration continue assez géniale. Depuis quelques mois, cette intégration continue propose une fonctionnalité tout aussi géniale : les déploiement intégrés à l'intégration continue
Ce sont des tâches d'intégration continue comme les autres (donc potentiellement des scripts Shell arbitraires), qui sont taggués comme « déploie la version en cours sur l'environnement X ». Et surtout, on peut les lancer manuellement.
En admettant qu'on trouve un outil d'intégration continue sur Github qui propose la même fonctionnalité, on pourrait tout à fait définir ce genre de tâches (actives, disons, sur la branche prod et/ou sur les tags), ce qui permettrait :
De déployer en 1 clic une version arbitraire sur la bêta ;
De déployer en 1 clic une version arbitraire sur la prod (attention à qui on donne les droits d'appuyer sur ce bouton) ;
De gérer les cas particuliers en faisant un déploiement manuel.
Je pense que ça peut être un gros plus pour le déploiement de ZdS est éviter cet espèce d'effet tunnel qu'on a aujourd'hui.
Si vous voulez des détails supplémentaires sur le fonctionnement du truc et la théorie, n'hésitez pas !
The text was updated successfully, but these errors were encountered:
Moi, l’intégration continue, je suis moyen chaud : pour rester concret, je dirais qu'au vu du nombre de RC de nos dernières releases, l'intégration continue est assez suicidaire. Et du coup, on peut pas se permettre, avec notre coverage actuel (pourtant pas mauvais, mais par exemple on a pas de tests fronts), de se reposer uniquement sur les tests, ce qui signifie intensifier la phase de QA, qui est déjà pas drôle à la base. Bref, dangereux.
Après, je suis assez fan de la fonctionnalité de GitLab CI en elle-même :)
J'ai réfléchi à tout ça et je pense que si j'avais une semaine de vacances ce serait jouable.
Petite note :
De déployer en 1 clic une version arbitraire sur la bêta ;
Là aussi, attention à ne pas autoriser trop de gens à appuyer sur ce bouton. Les données sur la bêta sont généralement quelques jours/semaines derrière la prod. On peut pas se permettre de déployer du code sans être certain qu'il ne donne pas accès à la DB.
Le fonctionnement actuel en version bloque le déploiement de tout un tas de connectifs / améliorations assez triviaux, parce qu'il faut attendre pour qu'ils soient déployés que la version soit prête et testée, et que comme dans toute version, on voudrait bien que les fonctionnalités X et Y soient embarquées, et donc correctement testées, etc.
C'est long et apporte de la latence, mais c'est encore le processus le moins pire qu'on a trouvé avec nos outils et contraintes.
L'exemple inverse, ce serait une intégration continue dans laquelle tout ce qui est mergé sur
prod
est automatiquement déployé en prod. Sauf que ça pose d'autres problèmes, notamment dès qu'une version nécessite des opération manuelles pour être déployée.Or donc voici qu'au boulot on utilise GitLab (une instance locale), qui vient avec une intégration continue assez géniale. Depuis quelques mois, cette intégration continue propose une fonctionnalité tout aussi géniale : les déploiement intégrés à l'intégration continue
Ce sont des tâches d'intégration continue comme les autres (donc potentiellement des scripts Shell arbitraires), qui sont taggués comme « déploie la version en cours sur l'environnement X ». Et surtout, on peut les lancer manuellement.
En admettant qu'on trouve un outil d'intégration continue sur Github qui propose la même fonctionnalité, on pourrait tout à fait définir ce genre de tâches (actives, disons, sur la branche
prod
et/ou sur les tags), ce qui permettrait :Je pense que ça peut être un gros plus pour le déploiement de ZdS est éviter cet espèce d'effet tunnel qu'on a aujourd'hui.
Si vous voulez des détails supplémentaires sur le fonctionnement du truc et la théorie, n'hésitez pas !
The text was updated successfully, but these errors were encountered: