Je suis un entrepreneur qui a récemment commencé avec une entreprise.
L'équipe est composée de 3 développeurs composés de 2 développeurs de niveau junior à moyen, avec un autre au même niveau qui commence bientôt, et moi-même (6 ans xp). Pour les développeurs existants, il s'agit de leur premier emploi hors de l'université / du collège, et ils n'ont jamais eu de développeur senior supervisant leur travail auparavant.
Il n'y a pas de politique de contrôle de version explicite. Les développeurs effectuent tout le développement sur le tronc puis se déploient en production directement à partir de leurs machines de développement. L'équipe existante n'est pas familière avec la création de succursales.
Je change tout cela et présente CI, les serveurs de test / transfert / production TDD, etc., ainsi qu'une politique de contrôle de version pour compléter cela.
Le système de contrôle des sources est TFS, que je n'ai jamais utilisé auparavant. Il est configuré comme un référentiel géant.
J'ai écrit quelques conseils pour eux, mais y a-t-il autre chose que je devrais ajouter / modifier, compte tenu de l'expérience de l'équipe?
Politique de contrôle de version
Le développement se fait sur le tronc
Si un changement est estimé à prendre plus d'une semaine, il doit être effectué sur une branche, avec des fusions régulières du tronc dans la branche pour empêcher les deux de se désynchroniser.
Libérer les branches créées pour le code de production. Cette branche ne doit contenir que du code stable. Nous pouvons soit avoir une branche de publication qui est mise à jour à partir du tronc une fois par sprint, soit créer une branche de publication distincte pour chaque semaine.
Si un correctif de bogue urgent affectant le code de production doit être effectué, il est effectué sur la branche de publication et fusionné dans le tronc.
Si nous adoptons la stratégie d'une branche de publication, le tronc est fusionné dans la branche de publication une fois par sprint vers la fin du sprint.
Si nous adoptons la branche distincte par stratégie de version, le tronc ne sera JAMAIS fusionné dans la branche Release
Dans certains scénarios, il peut être nécessaire de corriger le bogue deux fois sur différentes branches, si les branches ont trop divergé. Si nous faisons des sprints courts, cela ne devrait pas arriver trop souvent.
J'ai l'intention d'avoir trois serveurs. Environnement de test qui exécute toujours le dernier code dans le référentiel. Un environnement de mise en attente qui exécute la dernière version candidate pour la mise en place / le test du code de la version candidate et à des fins d'UAT, et l'environnement de production.
La raison pour laquelle je prévois de le faire est que jusqu'à présent, le client n'a fait que des logiciels internes. Le projet le plus récent concerne un client médiatique de haut niveau et j'ai le sentiment que l'équipe doit adopter un modèle de développement plus professionnel que ce qu'elle fait actuellement.
Par exemple, pour le moment, un utilisateur peut téléphoner à l'équipe avec un rapport de bogue. Les développeurs localisent et corrigent le bogue, effectuent un test rapide du globe oculaire sur leurs propres machines, puis se déploient directement en production. Aucun test automatisé ou quoi que ce soit.
Avec le recul, je pense que la branche de fonctionnalité est un pas trop loin et je vais supprimer cela.
Donc, essentiellement, cela revient à a) pas de branchement du tout) b) une branche de libération et le tronc, et c) une branche de libération par libération et le tronc.
Je me penchais vers ce dernier. Ma pensée initiale serait que j'aurais à la fois une version candidate et une version à vivre sur des serveurs distincts (UAT / Production) en même temps, mais en fait, le tronc est la version candidate à tout moment, donc une branche par la libération penche vers la folie. Ma seule pensée serait que si nous ne voulions pas que nos parties prenantes voient le code de développement, nous pourrions avoir besoin d'une branche de candidat de version distincte, mais YAGNI et tout cela .....