Help me stop testing in prod. Suggestions and strategies welcome.
intermediate
So, I've written a Discord Bot. It is primarily moderation and logging-focused, with many features based around reactive moderation (performing action X when even Y is received). In the past I used to leverage a secondary bot running on a separate token for testing purposes, only pushing updates to the main bot when they were ready. As the bot grew in scale and complexity (and most importantly, became a public bot) this quickly became unfeasible for me at my level of experience.
I've painted myself into a bit of a corner while developing this current iteration of the bot and I do not know how to break free from this cycle. This is primarily due to the addition of new features or the lack of ability to test them outside of "production" due to platform (Discord) limitations. However admittedly it is likely due to my lack of experience as a developer in a professional sense - I am entirely self taught and have no real world experience building apps outside of as a hobby.
Some notable problems include:
1. The bot is designed to post a message when it joins a server for the first time, thanking the server owner for inviting the bot and providing links to documentation. The check for this is stored in the database. If I am utilizing a secondary (or freshly created) database on the testing bot, every time I restart it, every server will receive a "welcome" message over and over again unless I DON'T wipe the database during testing.
2. Some features in Discord are only available in larger servers — this means some features for the bot can ONLY be tested or developed in these larger servers, the biggest of which is the server the bot was originally developed for. This means I could not maintain a 100% separation between prod and dev environments.
3. Related to 2, many features of the bot are "reactive" in response to Discord events such as users leaving, being banned, messages being sent, etc. If the testing bot and the main bot were in the same server, this would lead to events being handled twice which could (and did) cause undefined or unexpected behavior as both bots tried to handle an event in the same manner at the same time.
4. I cannot reliably "mock" Discord in any feasible capacity to simulate the variety and frequency of events that occur across all the servers the bot is in. Systems and services that work fine when there are 20 users could slow to a crawl, break, or cause other strange things to happen when there are 200,000 users. There is only so much I can do to test new features with myself and a dummy alt account, or a couple friends I've successfully convinced to help me over an afternoon.
I would greatly appreciate any insight from more seasoned developers or anyone willing to suggest ways I can get myself out of this corner I've painted myself into. It would be very nice to be able to test and develop things without the inherent risk of being hooked right up to the production database, or causing mayhem across the 1,000+ servers and hundreds of thousands of users the bot interfaces with on a daily base. I know it's a terrible, terrible practice, but I'm seriously stumped on how to get around this roadblock as a developer.
I've painted myself into a bit of a corner while developing this current iteration of the bot and I do not know how to break free from this cycle. This is primarily due to the addition of new features or the lack of ability to test them outside of "production" due to platform (Discord) limitations. However admittedly it is likely due to my lack of experience as a developer in a professional sense - I am entirely self taught and have no real world experience building apps outside of as a hobby.
Some notable problems include:
1. The bot is designed to post a message when it joins a server for the first time, thanking the server owner for inviting the bot and providing links to documentation. The check for this is stored in the database. If I am utilizing a secondary (or freshly created) database on the testing bot, every time I restart it, every server will receive a "welcome" message over and over again unless I DON'T wipe the database during testing.
2. Some features in Discord are only available in larger servers — this means some features for the bot can ONLY be tested or developed in these larger servers, the biggest of which is the server the bot was originally developed for. This means I could not maintain a 100% separation between prod and dev environments.
3. Related to 2, many features of the bot are "reactive" in response to Discord events such as users leaving, being banned, messages being sent, etc. If the testing bot and the main bot were in the same server, this would lead to events being handled twice which could (and did) cause undefined or unexpected behavior as both bots tried to handle an event in the same manner at the same time.
4. I cannot reliably "mock" Discord in any feasible capacity to simulate the variety and frequency of events that occur across all the servers the bot is in. Systems and services that work fine when there are 20 users could slow to a crawl, break, or cause other strange things to happen when there are 200,000 users. There is only so much I can do to test new features with myself and a dummy alt account, or a couple friends I've successfully convinced to help me over an afternoon.
I would greatly appreciate any insight from more seasoned developers or anyone willing to suggest ways I can get myself out of this corner I've painted myself into. It would be very nice to be able to test and develop things without the inherent risk of being hooked right up to the production database, or causing mayhem across the 1,000+ servers and hundreds of thousands of users the bot interfaces with on a daily base. I know it's a terrible, terrible practice, but I'm seriously stumped on how to get around this roadblock as a developer.
