re: Projection Building Blocks: What you'll need to build projections VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Thanks for replying. The thing is that we have been using all the technics you described for a while already. They play nice, indeed. But you desc...

You system deployed on the other part of the world and the next time you, as a developer, have a chance to fix it and deploy your fix will be in a month or so.
What would be your solution to this?

I'm really confused by this. If you deploy code with a bug, and you can't fix it for over a month, then it's going to be broken for a month. There's no way around this, it doesn't matter if it's event driven or not. That's why no one touches the topic.

If you're asking how you ensure the system is stable before releasing, then the answer is automated tests.

If the release process is the bottleneck, you should look into CI/CD, so you can get the fix out faster.

Otherwise you're just stuck.

None of the mentioned technics give me 100% protection(Of course you might say: there is no such thing). They are reducing the likelihood, but not completely.
When there are lots of moving parts: ui, domain, projection code, projection storage, it is really easy to miss something. For example, we have all of these: CI/CD, unit testing, integration testing, manual testing, several levels of UAT and yet, I was once in a situation deploying 4 times a day into prod, just because of those tiny missing things which were breaking the whole system. It is possible, I've seen it, I was fixing it. Luckily the users of this software were just next to. Even though they were not happy with such interruptions.

But currently we are in a difficult situation - all the users are somewhere and there is no way patching it right away.

Where were we? Right. Would you be happy as a client of a banking system, if a tiny mistake in my account blocks your account as well?
See where I am heading?

code of conduct - report abuse