Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the strategy to deploy bot without downtime and without duplicated responses? #2478

Open
warycat opened this issue Jun 26, 2023 · 1 comment
Labels
question A question about Serenity.

Comments

@warycat
Copy link

warycat commented Jun 26, 2023

I am new to bot development and I can't find solutions online to answer some of my questions. Also ChatGPT can't help with the design.

  • If I have a bot running in production, what is a good way to roll out a new version of the bot and kill the old version of the bot?
  • How to roll back if the new version is bad?
  • How to do load balancing with multiply instances of the bot running without duplicated responses?
@arqunis arqunis added the question A question about Serenity. label Jul 15, 2023
@Brian-ED
Copy link

Brian-ED commented Jan 8, 2024

If I have a bot running in production, what is a good way to roll out a new version of the bot and kill the old version of the bot?

This can get complicated depending on what your bot currently is doing, if your bot is running games it may need to pack currently running stuff into some kind of data to load later (probably a file). You then need to have the bot automatically pull in the version you want, lets say you're using Github. One way is having a command like !update where your argument is a commit/branch/etc and have the bot automatically pull and compile it. This shouldn't affect your currently running bot assuming your bot doesn't read files that were replaced/removed in the pull. The next step is re-compiling the pulled code, and running it. If there's a compile error then you should revert to the commit you had beforehand, recompile that, and have the bot say "update failed". if it's a success, run the new code and intentionally stop the currently running code. You may need to somehow feed it the last bot's state, that depends a lot on the bot. Also remember that your updated bot should be able to handle last bot's state that it had, so if it was running a game, the currently running bot should be able to run the same game. If you can't feed the data and it errors, it may be best to just drop it and delete it, since you should still want to update, just remember to backup the data just in case.
Another way would be to incrementally move to the next version is to just make the old bot not accept any commands to let the new one running take it, but let the old version still complete all the commands it has currently running. after lets say 10 minutes you can stop the old bot and keep the new one.
Compiling on a server running your bot may be unnecessary though, depending on how you're hosting it. you may want to compile it on your development machine and give the binary directly to the bot somehow. I haven't experimented with this, but i don't see why not.

How to roll back if the new version is bad?

If the new bot fails, pull the old version back and compile and run, or if you went with the incremental approch just make old bot accept commands again. In case of complete failure of the move system, or invalid states and such, you could keep a way to communicate to your server through some other means, maybe a small extra bot that just listens in on the !update command so you can do a complete restart.

How to do load balancing with multiply instances of the bot running without duplicated responses?

I have never had issues with load but I can imagine one way that would work is if you had each bot instance only listening in on a specific amount of servers, with some kind of center server that manages which servers each bot-instance takes care of.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question A question about Serenity.
Projects
None yet
Development

No branches or pull requests

3 participants