Pourquoi ne pas déployer un vendredi?
Joel a mentionné dans le podcast # 24 de StackOverflow que la politique de l'entreprise FogCreek est de ne pas expédier de logiciels le vendredi. Cependant, il n'a pas expliqué pourquoi.
Je suis d'accord. Chez mon employeur, nous déployons le jeudi soir. Nous avons donc vendredi pour nettoyer tous les bogues qui manquaient à l'assurance qualité (AQ).
Cependant, mon responsable a suggéré que nous déployions le vendredi soir dans le cas où le contrôle qualité n'aurait pas assez de temps pour tester le logiciel avant une version. Je dis, qu'en est-il des plans de week-end des gens? Et si nous déployons un vendredi soir, nous devrons travailler samedi pour nettoyer tous les bogues manqués - ce qui est nul.
Alors pourquoi ne pas expédier de logiciel un vendredi?
* Nous pourrions (pas sûr) faire cette hypothèse: il y a une équipe de développement de logiciels de base située dans un fuseau horaire déployant l'application Web de base de leur entreprise.
Ce n'est pas juste une question de bugs. Il peut y avoir d'autres charges de support liées - expliquant les nouvelles fonctionnalités aux utilisateurs, surveillant qu'il n'y a pas de problèmes de performances.
Une nouvelle version signifie généralement un bref pic d'activité de support - donc planifier que cela se produise quand il y a moins de personnes disponibles (ou quand il y a plus de ressentiment de temps occupé) est une mauvaise idée.
Vous avez à peu près répondu à votre propre question. C'est une raison courte et douce: si vous expédiez un vendredi et qu'un bogue entre en production, il n'y a généralement personne pour le réparer ou parler aux clients jusqu'au lundi suivant. Cela représente potentiellement plusieurs jours de perte de revenus dans le pire des cas.
Ne déployez jamais le vendredi car:
- C'est la fin de la semaine donc les gens sont moins pointus
- C'est la fin de la semaine donc les gens ne sont pas disponibles pour corriger les bugs
- C'est la fin de la semaine donc les gens ne sont pas disponibles pour répondre aux questions
- C'est la fin de la semaine, alors pourquoi vous déploieriez-vous alors?
Nous évitons de publier du code jeudi o vendredi - personne ne veut passer son vendredi à trouver des bogues critiques pour la mission, et il est probable que même si nous produisons un correctif en 1 jour, ce sera au moins un autre la veille de sa sortie, ce qui signifie soit travailler le week-end, soit il ne sera réparé que la semaine prochaine.
Cela dépend de votre groupe cible. Nous déployons principalement le vendredi. Notre produit basé sur un navigateur est utilisé dans le monde entier par les clients, mais principalement pendant les heures de bureau. Cela signifie que nous n'avons pas vraiment d'autre temps que le dimanche matin si nous voulons nous assurer que nous n'affectons aucun client (l'Inde et le Moyen-Orient ne quittent pas le travail de bureau le samedi), mais en général, nous nous "compromettons" et déployer le vendredi après-midi.
Si précédemment travaillé sur un site de datation où nous voulions idéalement déployer de nouvelles choses autour de mardi, car l'activité a culminé le week-end et, étrangement, le lundi autour du déjeuner.
Quoi qu'il en soit, cela se résume à 2 considérations. 1. Quand cela sera-t-il le moins perturbateur pour vos clients (s'il s'agit d'une application Web) et 2. Quand cela conviendra-t-il le mieux à l'équipe de développement pour corriger rapidement les bogues critiques?.
Si vous craignez que vos développeurs deviennent bâclés vers la fin de la semaine, votre pipeline d'assurance qualité peut être trop court.
Nous déployons normalement le mardi, puis nous avons le reste de la semaine pour sauter sur n'importe quel problème. Cela dépend aussi un peu de l'industrie, s'il n'y a pas de travail le week-end, c'est peut-être bien de déployer le vendredi soir, mais s'ils fonctionnent, ce n'est pas une bonne idée.
Pour cela, les gens ont tendance à être un peu plus bâclés les vendredis (pensant déjà à cette date chaude | bière froide | les deux) et les jours avant de partir en vacances ;-)
Cela dépend vraiment de votre application et de son niveau d'occupation/critique le week-end.
Nous ne déployons généralement pas de logiciels un vendredi, mais le faisons souvent le samedi ou le dimanche. Nous avons constaté que le dimanche matin était particulièrement bon pour minimiser l'impact d'une version.
Cela dépend vraiment si vous essayez de minimiser l'impact de tout temps d'arrêt dont vous avez besoin pour faire votre version, OR atténuer les bugs potentiels.
Vous ne verrez aucun bogue tant que les clients n'utiliseront pas le système (dans la plupart des cas), donc le déploiement le vendredi équivaut au déploiement le lundi matin, si vous avez une faible utilisation le week-end.
D'un autre côté, des choses comme les achats en ligne ont tendance à être plus utilisées le week-end, il est donc déconseillé d'en déployer un le vendredi.
Cela dépend également de votre politique d'assistance en dehors des heures d'ouverture. Si vous avez quelqu'un sur appel qui peut restaurer le logiciel, c'est moins un risque. Je préfère quand même le faire pendant la semaine de travail.
Nous déployons généralement des trucs du mardi au jeudi, préférant éviter le lundi (notre jour le plus chargé) et le week-end (lorsqu'un bug peut rester inaperçu et causer des problèmes)
Je ne planifierais jamais un déploiement le vendredi, sauf si je prévoyais également d'être au bureau le samedi pour vérifier que son fonctionnement fonctionne correctement, si vous finissez par vous déployer un vendredi en raison d'un glissement, vous courez un grand risque de précipiter les choses, il vaut mieux attendre , laissez tout le monde se calmer pendant le week-end, puis expédiez-le lundi après une revue matinale.
Si votre déploiement se déroule le week-end, le fait de commencer le vendredi soir peut vous donner une bonne longueur d'avance, car le bureau s'effacera souvent un peu plus tôt, de sorte que la charge globale du système sera inférieure à celle du lundi matin, par exemple.
Vous ( devriez déployer vendredi afin d'avoir tout le week-end pour le nettoyer et corriger les bugs avant que le reste de votre équipe ne le remarque vos oublis lundi.
J'ai travaillé avec une entreprise qui avait une politique de déploiement le vendredi; ils étaient en Israël et le samedi est généralement le dernier jour de la semaine de travail. En tous cas...
Dans ma dernière entreprise, la politique consistait à fournir à Ops le package de déploiement au plus tard à midi les mardis et jeudis. Cela signifie qu'ils ont une demi-journée pour le sortir et demander des ajustements mineurs en cas de problème avec la dernière phase de l'assurance qualité pré-live. (Tout autre AQ peut se produire à tout moment de la semaine car il n'est pas en direct.)
La sortie dans n'importe quel environnement sauf en direct est très bien à tout moment, si les Ops ont le temps de le faire (bien sûr, cela devrait être réservé à l'avance de toute façon) mais ne sortez jamais pour vivre:
Lundi - Mauvais, vous venez de rentrer d'un week-end (je l'espère un non-travail) et vous n'aurez pas tout ce que vous avez fait la semaine dernière dans votre esprit. Mercredi - Habituellement le jour le moins productif de la semaine et se situe comme le "milieu du travail". Si votre emplacement était mardi et que vous l'avez manqué en raison de bogues, mercredi est probablement un mauvais choix car vous ne disposez pas de suffisamment de temps pour corriger et tester ces bogues. Vendredi - Allez. Sérieusement? C'est vendredi. Si cela doit vraiment être expliqué, vous n'avez pas suffisamment d'expérience pour occuper le genre de poste de direction dans lequel vous vous trouvez. Mais sérieusement, c'est parce que le déploiement le vendredi signifie que vos clients doivent se présenter le week-end pour tester votre travail en direct environnement. Pour moi, cela bat toute idiotie pour laquelle vous pourriez vous aligner.
Nous avons la chance de faire bon usage du décalage horaire, nous avons des bureaux répartis dans le monde entier. Ainsi, lors de la mise à jour des clients, nous l'organisons pour que cela se fasse du jour au lendemain afin de minimiser l'impact sur eux.
cela fonctionne bien lorsque vous contrôlez la mise en œuvre et le déploiement de votre logiciel, mais la publication sur un site Web est un autre animal. Comme d'autres l'ont déjà souligné, assurez-vous de prévoir du temps pour:
- Prise en charge des bizarreries et des bogues pouvant survenir
- Accompagner les utilisateurs dans les transitions
- Correctifs de dernière minute