Décrivez votre stream de travail en utilisant le contrôle de version (VCS ou DVCS)

Je voudrais apprendre le workflow d’autres personnes en utilisant vcs ou dvcs.

Veuillez décrire votre stratégie pour gérer les tâches suivantes:

  • Implémenter une fonctionnalité
  • Correction de bugs (pendant le développement et l’application déployée)
  • Révision du code
  • Code de refactoring (post-code-review)
  • Incorporer des patchs
  • Lancement de la nouvelle version de votre application (bureau, Web, mobile, les traiteriez-vous différemment?)

N’hésitez pas à organiser votre réponse non regroupée par tâches mais regroupée par tout ce que vous pensez pertinent, mais veuillez l’organiser par VCS / DVCS (veuillez ne pas les mélanger).

Je vous remercie.

La principale caractéristique utilisée par VCS pour les différentes tâches que vous mentionnez est la twig : la capacité à isoler un effort de développement de manière collaborative. Comme il s’agit d’un VCS central, plusieurs développeurs peuvent collaborer sur une même twig, avec des verrous pessimistes ou optimistes sur les fichiers, afin de développer une histoire parallèle.

Mais être un VCS a deux conséquences majeures sur la création de succursales:

  1. Il a tendance à décourager les commits, car une fois un fichier validé, il influencera immédiatement l’espace de travail des autres vues ayant la même configuration (par exemple, “travailler sur la même twig”).
    ~ Le processus de “publication” est actif, avec des conséquences immédiates,
    ~ tandis que la partie “consommasortingce” (mise à jour de votre espace de travail) est passive (vous êtes obligé de gérer les modifications publiées par d’autres immédiatement après la mise à jour de votre espace de travail)
  2. Cela fonctionne bien pour le stream de travail de fusion linéaire (c.-à-d. “Ne fusionnez que de la twig A à la twig B, sans mélanger les fusions dans les deux directions” – A à B à A à B …). Les fusions sont sortingviales, toutes les modifications de A sont simplement rescopes sur B

À présent:

Implémenter une fonctionnalité

Tout VCS le fera en créant une twig, mais ce qui m’a beaucoup surpris, c’est qu’une twig “fonctionnalité” n’est pas facile:
* la fonctionnalité peut devenir trop compliquée
* il peut être prêt à temps pour la prochaine version
* Seule une partie peut être fusionnée dans la twig de développement principale
* cela peut dépendre d’autres fonctionnalités qui ne sont pas encore complètement réalisées

Donc, vous devez faire attention à la façon dont vous gérez votre twig de fonctionnalités et à vos commits: si elles sont étroitement liées à la même fonctionnalité, cela se passera bien (vous fusionnez le tout avec votre twig de développement principale) . Sinon, les fusions partielles ne sont pas faciles avec ces outils.

Correction de bugs

La différence entre les corrections de bogues pendant le développement et après la publication est que, dans le premier cas, vous pouvez souvent le faire de manière linéaire dans la même twig, car dans ce dernier cas, vous devrez créer une twig de correction besoin de revenir à votre twig de développement actuelle.

Révision du code

Il est préférable de l’utiliser avec des outils externes ( comme Crucible par exemple), et utilise intensivement les fonctions VCS comme le blâme ou les annotations, afin de mieux atsortingbuer les correctifs de code après une révision.

Code de refactoring (post-code-review)

Si le refactoring est mineur, il peut continuer dans la même twig. Mais si elle est grande, une twig spéciale doit être configurée, avec des tests unitaires effectués avant de commencer le refactoring.

Incorporer des patchs

Même commentaire que dernier point. Si le patch est important, une twig doit être créée.

Publication de la nouvelle version de votre application

Un VCS ne vous aidera que dans la publication de votre application, car il ne s’agit pas d’un outil de gestion des versions.
Vous devrez auparavant identifier une version à publier (label), mais ensuite vient le processus de déploiement qui implique:

  • arrêter ce qui est en cours d’exécution
  • copier les nouveaux fichiers
  • les déployer (mise à jour de la firebase database sql, webapp, …)
  • instancier tous les fichiers de configuration (avec les bonnes valeurs, adresses, numéros de port, chemins, …)
  • redémarrer (et si votre système est composé de plusieurs composants, les redémarrer dans le bon ordre!)

Les éléments clés de VCS et de la gestion des versions sont les suivants:

  • ils ne sont pas très bien adaptés pour stocker les binarys à publier, ce qui signifie que vous en avez besoin pour créer votre application, et non pour stocker l’exécutable résultant
  • ils ne sont pas toujours les bienvenus dans l’environnement de production (où les contraintes de sécurité limitent l’access en écriture, ainsi que le nombre d’outils s’exécutant sur ces plates-formes, essentiellement les outils de surveillance et de reporting).

Le mécanisme de libération a également une influence sur les dépendances binarys:

  • pour les dépendances binarys externes, vous utiliserez probablement des mécanismes comme maven pour obtenir des révisions fixes des bibliothèques externes
  • mais pour les dépendances internes, lorsque vous ne développez pas une seule application, mais plusieurs qui dépendent les unes des autres, vous devez savoir comment référencer les binarys produits par les autres applications (dépendances internes binarys) et elles ne seront généralement pas stockées. dans votre VCS (en particulier dans la phase de développement, où vous pouvez produire de nombreuses versions différentes pour que vos autres applications puissent les utiliser)

Vous pouvez également choisir d’être dans des dépendances de source (et obtenir toutes les sources des autres projets internes dont vous avez besoin), et un VCS est bien adapté à cela, mais il n’est pas toujours possible / pratique de tout recomstackr.

La principale différence avec un DVCS (Dissortingbuted Version Control) à partir d’un VCS est qu’il est fait (de par la nature même de son travail dissortingbué) pour faire une chose et une chose:

fusionner

Donc, les tâches que vous mentionnez peuvent être vues sous cet angle.
Les twigs seront toujours fabriquées, mais toutes ne seront pas visibles par les autres développeurs. Beaucoup d’entre eux ne quitteront pas réellement votre repository local .

Être un DVCS a deux conséquences principales sur la fusion:

  1. vous vous engagez autant de fois que vous le souhaitez. Ces commits ne sont pas immédiatement visibles pour les autres (c.-à-d. “Ils n’auront pas à les fusionner immédiatement après la prochaine mise à jour de leur espace de travail”)
    ~ le processus de publication est passif: vos push peuvent être ignorés par les autres repos.
    ~ la partie “consommasortingce” est active: vous pouvez examiner ce qui vous a été envoyé avant de le fusionner avec votre twig et décider de ce que vous voulez fusionner et de qui (et pas seulement parce que vous travaillez tous sur un même twig”).
  2. il fonctionne bien pour tout stream de travail de fusion (partiel, croisé, récursif, …) Le DAG (Directed Acyclic Graph) souvent utilisé pour enregistrer l’historique par ces DVCS (au moins Git et Mercurial) facilite la recherche de ce qui a déjà été fusionné et trouver l’ancêtre commun. C’est une différence importante entre SVN et ses homologues DVCS , mais il y en a d’ autres également .

À présent:

Implémenter une fonctionnalité

Comme je le détaille dans ma réponse CVCS (Central VCS) , la difficulté derrière une twig “caractéristique” est que de nombreuses sous-fonctionnalités vont se mêler.
C’est là que DVCS va briller car ils vous permettront de réorganiser leur historique local (comme dans “pas encore poussé”) (changesets pour Mercurial, commits SHA1 de Git), afin de faciliter les fusions partielles, ou les sous-twigs.

Correction de bugs

Vous pouvez presque créer une twig par correctif si vous le souhaitez. L’idée est de s’assurer qu’un correctif est identifié par un simple ensemble linéaire de commits fusionnés dans la twig de développement (ou dans la twig de maintenance si celle-ci est libérée).
Je préfère m’assurer de rebaser d’abord la twig de correction de bogues au-dessus de la twig de développement (pour m’assurer que mes correctifs sont toujours compatibles avec tout travail effectué en parallèle sur ladite twig principale) avant de fusionner cette twig de développement avec correction d’un bug (fusion rapide: la twig principale fait maintenant référence à tous les correctifs)

Révision du code

La fonctionnalité de blâme ou d’annotation est toujours là pour vous aider à atsortingbuer les tâches lors d’une révision de code, mais cette fois, tous les développeurs ne sont pas nécessairement sur un seul site (puisqu’il s’agit d’un VCS * dissortingbué) et non avec le même schéma d’identification ( ne pas utiliser le même LDAP par exemple).

Une méthode DVCS pour organiser une révision de code consiste à transférer de nouvelles modifications vers un référentiel de révision de code spécial, qui:

  • rejeter ces commits s’ils ne répondent pas aux critères de qualité requirejs
  • accepter ceux-ci (les fusionner avec le repo de révision de code) et les pousser vers un nouveau repository (utilisé par exemple pour différents tests)

Code de refactoring (post-code-review)

Elles se font sur le repo local du développeur, dans une twig (car il est si facile de le fusionner)

Incorporer des patchs

Même processus que la dernière section.

Lancement de la nouvelle version de votre application (bureau, Web, mobile, les traiteriez-vous différemment?)

Le processus de publication proprement dit est simplement initié par une version identifiée (tag) spéciale de votre logiciel. (le rest du “processus de gestion des versions”, c’est-à-dire la partie déploiement et configuration, est détaillé dans la réponse CVCS )
La question est, avec un DVCS:
“D’où proviendra cette version officielle de votre logiciel?”

Vous devez établir un référentiel “central” ou plutôt “officiel” qui jouera le rôle de:

  • repo pour les versions à publier
  • repo pour les nouveaux repositorys voulait consortingbuer

Il peut donc servir à la fois à des fins de publication, mais également à de nouveaux objectives de développement.