Migrer de Sidekiq vers ActiveJob

[Florian Dutey]

Bonjour a tous,

J'ai un petit dilemme qui n'a malheureusement pas trouve de reponse dans google.

Nous avons migre sur rails 4 il y a 1 ans 1/2. Rails 4 qui apporte ActiveJobs. Nous avons deja une liste de jobs longue comme le bras (un tres long bras) donc nous n'avons pas migre les jobs existants et avons continue a proceder comme avant.

En ce moment, nous deployons beaucoup d'energie a virer les milliards de tonnes de dettes techniques et introduire des bonnes pratiques. ActiveJob semble etre une meilleure solution sur le long terme que des "pure sidekiq jobs" puisque ca permet de s'abstraire du backend et d'en changer quand bon nous semble (si bon nous semble).

Probleme: nous ne pouvons pas migrer tous les jobs d'un coup. Il y en a beaucoup trop.

Question: Est-ce qu'il est possible d'avoir ActiveJob (avec sidekiq comme backend) ET des jobs sidekiq purs qui tournent en meme temps? 

Malgre de longues heures a chercher sur google, je n'ai vu personne qui parlait de ce probleme.

Merci d'avance ;)

Flo

[Olivier El Mekki]

Hello,

Je laisse d'autres te répondre sur la possibilité de cohabitation, chaque fois que j'ai été confronté à ce problème, j'ai choisi soit de rester sur le low level, soit de migrer entièrement sur activejob.

Une mise en garde cela dit : une solution mixte me semble peu efficace si l'objectif est de réduire la dette technique. Si tu utilise à la fois activejob et sidekiq directement, chaque fois qu'un développeur voudra utiliser un job, il devra se demander : "alors, ce job là, est-ce que je dois appeler `performer_later` ou `perform_async`, dessus?". Vous allez vous faire maudire :)

Les changements au niveau fichiers de job pour passer de sidekiq à activejob sont minimes, retirer un include et ajouter un héritage, éventuellement gérer les sidekiq options s'il y en a. Est-ce qu'il n'est pas envisageable d'écrire un parser pour modifier vos fichiers de job?

[Florian Dutey]

Merci pour les details, tu as raison pour les histoires de noms de methodes mais:

1) les nouveaux jobs sont dans un namespace a part (qui contient tout le code reecrit, services, serializers ...). Ca simplifie quand meme pas mal les choses.

2) perform_async / perform_later -> un petit monkey patch a base d'alias ca fait pas le taff?

En ce qui concerne le parser, sidekiq uniqu job (qui veut dire que quelqu'un a foire a un moment ou un autre), les solutions maisons niquees pour tenter de gerer l'ordre des jobs et sidetiq rendent la migration complexe sans avoir a repenser pas mal d'entre eux.

--
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse rails...@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Railsfrance".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscribe@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.