Pour un bug, ton patch a de grande chances de venir de l’upstream, intégré dans la branche de dev pour la prochaine version, et tu veux juste l’appliquer en local parce que le bug en question est critique pour ton usage (ça m’est arrivé avec Gitlab)
Pour une fonctionnalité plus complexe, tu peux toujours balancer upstream pour pas avoir à maintenir.
Et cc’est sans compter que beaucoup de projets ont un système de plugins (Jenkins/Redmine me viennent en tête). Dans ma boite actuelle on a des plugins redmine développés en interne, bonne chance pour faire la même chose avec un tracker en mode SAAS.
Et sans compter que tout reste à l’intérieur de ton réseau. Je ne comprend toujours pas comment certains arrivent à tolérer qu’un service externe, sur un réseau externe, puisse se connecter sur leurs serveurs de production pour le déploiement (dans le cas où le déploiement se fait par un système de CI/CD externe).
[^] # Re: Pourquoi le feraient-ils ?
Posté par Moonz . En réponse au journal Microsoft rachète Github. Évalué à 5.
Pour un bug, ton patch a de grande chances de venir de l’upstream, intégré dans la branche de dev pour la prochaine version, et tu veux juste l’appliquer en local parce que le bug en question est critique pour ton usage (ça m’est arrivé avec Gitlab)
Pour une fonctionnalité plus complexe, tu peux toujours balancer upstream pour pas avoir à maintenir.
Et cc’est sans compter que beaucoup de projets ont un système de plugins (Jenkins/Redmine me viennent en tête). Dans ma boite actuelle on a des plugins redmine développés en interne, bonne chance pour faire la même chose avec un tracker en mode SAAS.
Et sans compter que tout reste à l’intérieur de ton réseau. Je ne comprend toujours pas comment certains arrivent à tolérer qu’un service externe, sur un réseau externe, puisse se connecter sur leurs serveurs de production pour le déploiement (dans le cas où le déploiement se fait par un système de CI/CD externe).