Dans mon entreprise (une start-up de 3 ans dans l'industrie du Web), nous avons souvent des problèmes avec l'équipe produit qui dit "aaaah, c'est un problème de crise maintenant!" (pas tout le monde?)
Cela a un impact sur la productivité (et le moral) du personnel technique, y compris lui-même. La direction a réfléchi à la façon de réduire la fréquence de ces demandes le jour même et a trouvé la solution que nous allons publier chaque semaine. (Auparavant, nous en faisions une toutes les deux semaines, ce qui diminuait généralement de quelques jours.)
Il y a 13 développeurs et 6 testeurs locaux / 9 en mer; la théorie est que seulement 4 développeurs (et tous les testeurs) travailleront sur des versions paires, à moins qu'un travail ne survienne qui nécessite vraiment une expertise spécifique de l'un des autres développeurs. Chaque cycle contiendra deux jours de travail de développement et deux jours de travail d'AQ (plus 1 jour de cadrage / triage / ...).
Mes questions sont:
(a) Quelqu'un a-t-il de l'expérience avec cette durée de cycle de publication?
(b) Quelqu'un a-t-il déjà entendu parler de cette durée du cycle de libération?
(c) Si (a) ou (b), comment faites-vous pour que ça marche? (Les pièges à éviter, etc., sont également appréciés.)
d) Comment pouvons-nous minimiser les dommages si cet effort échoue?
la source
Réponses:
Vous pouvez certainement livrer chaque semaine - ou même plus fréquemment. Pour le moment, nous publions généralement toutes les deux semaines, mais il n'est pas inhabituel de déployer des fonctionnalités lorsque quelque chose est arrivé sans préavis de l'un de nos partenaires, ce qui ne serait pas pertinent si nous attendions le prochain cycle. À un moment donné au cours des prochains mois, j'aimerais que nous passions à la livraison continue (les articles sont publiés dès que possible une fois qu'ils sont `` terminés '') en standard, mais nous ne sommes pas encore assez confiants pour aller de l'avant. loin.
L'essentiel est que votre site Web soit fortement couvert par des tests automatisés - à la fois des tests unitaires et des tests d'acceptation de bout en bout / spécifications exécutables. Par implication, cela signifie également que votre build est entièrement automatisé. Au niveau de l'acceptation, nous utilisons Robot Framework, qui est excellent pour créer rapidement une suite de tests maintenable grâce à son approche par mots clés. Pour l'apparence, notre testeur sur place effectue quelques vérifications superficielles, mais nous avons également quelques gars en Inde qui effectuent une vérification plus approfondie sur différents navigateurs (il existe des sites qui aident à ce genre de choses en prenant des captures d'écran pour vous, par exemple BrowserLab ).
Nous n'automatisons pas entièrement le déploiement (la toute dernière étape nécessite une intervention manuelle, c'est une décision compliquée pour nous) - mais nous automatisons toutes les choses comme s'assurer que les connexions de base de données correctes sont utilisées, etc., avec des cycles de déploiement courts il serait trop facile de se tromper avec ce genre de chose.
Il y a un assez bon livre récent sur la livraison continue que vous voudrez peut-être consulter, je l'ai parcouru mais je ne l'ai pas encore parcouru en détail. Ce que j'ai lu jusqu'à présent correspond bien à nos expériences: Livraison continue: versions de logiciels fiables via l'automatisation de la construction, des tests et du déploiement
En résumé, vous avez besoin d'une équipe hautement disciplinée, d'un haut niveau d'automatisation et - plus important encore - d'un degré de confiance extrêmement élevé dans cette automatisation. Pour moi, il semble que passer à des cycles hebdomadaires dans votre cas peut être une erreur - les correctifs de crise font allusion à d'autres problèmes et vous devriez travailler pour les éliminer. Augmenter le rythme pourrait potentiellement aggraver la situation ...
la source
Si vous êtes continuellement en mode «sortie de crise», je dirais qu'il serait plus prudent de prendre du recul et de réévaluer votre code et votre processus. De toute évidence, il y a une sorte d'échec qui ne cesse de se répéter.
Bien qu'il ne soit pas tout à fait possible de le faire à une véritable échelle de production, il serait probablement utile d'avoir au moins un membre senior et un autre sous-ensemble de développeurs et de testeurs dédiés à cette évaluation.
Le "4 à la fois approche" ne me semble pas un gagnant clair. Cela signifie un changement de contexte constant, ce qui signifie beaucoup moins d'efficacité.
N'oubliez pas que si vous vous dépêchez constamment d'apporter des modifications, vous êtes beaucoup plus susceptible de faire des erreurs dans ces modifications et de casser quelque chose d'autre pendant que vous le faites.
la source
Des cycles de sortie inférieurs à une semaine ont certainement été atteints dans l'industrie du logiciel. Ils utilisent la technique appelée livraison continue (également appelée déploiement continu ).
Il y a une entreprise qui sort 50 fois par jour. Ce billet de blog décrit comment ils le font .
la source
On dirait que votre gestion est championne du monde ... pourquoi ne pas investir dans votre esprit d'équipe? Vous verrez que les problèmes disparaîtront d'eux-mêmes.
(a) + (b) À mon humble avis, selon la taille de votre équipe, elle devrait être de deux semaines maximum. Une semaine fonctionnera pour un seul homme ou de très petites équipes (comme 2 ou 3).
(c) + (d) Mais quelle que soit la taille de votre équipe ou de votre projet, l'une des premières choses que je fais est d'automatiser la construction et le déploiement. J'économise des jours voire des semaines de travail en le faisant dans les premiers jours d'un projet.
Vos déploiements doivent être effectués en un seul clic. De la source à la mise en scène, puis de la mise en scène à la production. Il existe de nombreux outils pour rendre cela possible. Des ant / nant aux trucs super lourds comme Automated Build Studio .
Tout peut être automatisé, du déploiement des fichiers à la mise à niveau de la base de données, en passant par les sauvegardes, les notifications, les rapports, ...
la source