2010-08-18 31 views
1

J'essaie de trouver une meilleure solution pour notre groupe de développement pour construire des correctifs pour nos applications (PHP).PHP - patch de l'application build

Nous soumettons actuellement à SVN tous les jours, mais n'exécutons pas un serveur d'intégration continu, car le code enregistré peut être bogué. Pour les correctifs de construction, nous vérifions par rapport à une "date modifiée", à partir de la dernière version. Bien souvent, nous commençons déjà le développement de nouvelles fonctionnalités, ou avons d'autres corrections de bugs, etc. qui ne sont pas planifiées pour le patch. Nous devons donc le choisir lorsqu'il est exécuté sur des serveurs de test. Ce que je cherche est un moyen facile de marquer les fichiers (nous utilisons NetBeans comme IDE), puis de construire cela. Au fur et à mesure de nos propres tests, nous marquerions le fichier, etc. Cela pourrait simplement être une chaîne de texte dans le fichier (nous le supprimerions pour le live). Encore une fois, notre problème est d'essayer de garder une trace des fichiers qui sont marqués comme prêts à aller, par rapport à ce qui est actuellement en développement.

Répondre

1

Ma question est pourquoi ne pas développer dans les branches? Si vous créez une branche pour chaque nouvelle fonctionnalité majeure, vous aurez toujours une branche "stable". Ensuite, vous créez simplement vos correctifs à partir de cette branche stable, et cela inclura seulement le code terminé et vérifié. Quand une branche de développement est prête à partir, après le test, faites simplement une fusion SVN pour ramener les données dans la branche stable ... (Surtout si vous avez plusieurs développeurs). Donc, évitez tout le problème.

+0

Les branches ne fonctionnaient pas. Nous étions en mode firehouse tout le temps (maintenance et nouvelles fonctionnalités). Ce n'était pas une situation optimale (plus là). Ce que j'ai fait à la place a été créé un script qui cherchait un drapeau (comme UPDATE_FLAG = 261b) et qui a ensuite créé les patches. Nous avons effectué des tests en interne et approuvé les fichiers à un niveau de développement avant d'aller à Q/A. S'est bien passé. –