Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça...
tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)
J'en ai vu aussi, ce n'est pas pour ça que je design mes systèmes pour ce cas-là. Parce qu'il y a déjà trop de problème quand on est dans cette situation.
Les devs n'auront pas peur de la prod pas parce qu'ils peuvent revenir en arrière 50 fois dans la journée mais parce que leurs déploiements, aussi fréquents soient-ils se passeront dans l'ensemble bien et que les soucis en prod ne seront pas inlassablement de même nature.
Si tu as suffisamment de test, tu n'as pas peur de la prod.
chg en base de donnée conséquente : même si entre la liv et le rollback, il c'est passé 5min, tu as potentiellement des données à migrer et du coût le rollback ne peut pas être simple.
Tu peux très bien designer ta migration pour être transparente. Soit tu duplique tes colonnes (soit via une procédure de la db, soit via l'application), et puis une fois que c'est migré, tu switch ton application. Soit tu as du schemaless et tu peux faire ton changement dans l'application. Le but c'est que ton application en version n-1 et n puisse accéder à la db, donc tu peux déployer tranquillement la nouvelle version et revenir en arrière de manière transparente.
tu ne maîtrises pas toute la chaîne de production : ton code dépend d'un web service externe qui a upgrade par ex.
Ça ne dépend pas de ton application. Normalement, tu as pu tester ton webservice avant et ton application peut gérer les deux versions et au moment où le webservice change, tu changes juste la config de ton application pour utiliser le nouveau. Après, pour les webservices bien fait, tu auras les deux versions en parallèle pendant un certain temps et tu pourras switcher sur le nouveau et revenir en arrière sur l'ancien pendant cette période.
tu as des niveaux de cache : t'es obligé d'invalidé tes caches à chaque livraison/rollback : tu peux faire explosé ta prod en jouant à ça.
Tu peux très bien construire ton application pour pouvoir utiliser l'ancien cache et le mettre à jour petit à petit.
Le rollback, pour moi, c'est du travail dans l'urgence.
Tu sais qu'il y a des systèmes qui font des rollback automatiquement ? En fonction des métriques de l'application (par exemple le nombre d'erreur 500, une baisse du nombre de requêtes...)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: rust
Posté par claudex . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 4. Dernière modification le 15 mai 2020 à 13:40.
J'en ai vu aussi, ce n'est pas pour ça que je design mes systèmes pour ce cas-là. Parce qu'il y a déjà trop de problème quand on est dans cette situation.
Si tu as suffisamment de test, tu n'as pas peur de la prod.
Tu peux très bien designer ta migration pour être transparente. Soit tu duplique tes colonnes (soit via une procédure de la db, soit via l'application), et puis une fois que c'est migré, tu switch ton application. Soit tu as du schemaless et tu peux faire ton changement dans l'application. Le but c'est que ton application en version n-1 et n puisse accéder à la db, donc tu peux déployer tranquillement la nouvelle version et revenir en arrière de manière transparente.
Ça ne dépend pas de ton application. Normalement, tu as pu tester ton webservice avant et ton application peut gérer les deux versions et au moment où le webservice change, tu changes juste la config de ton application pour utiliser le nouveau. Après, pour les webservices bien fait, tu auras les deux versions en parallèle pendant un certain temps et tu pourras switcher sur le nouveau et revenir en arrière sur l'ancien pendant cette période.
Tu peux très bien construire ton application pour pouvoir utiliser l'ancien cache et le mettre à jour petit à petit.
Tu sais qu'il y a des systèmes qui font des rollback automatiquement ? En fonction des métriques de l'application (par exemple le nombre d'erreur 500, une baisse du nombre de requêtes...)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche