Well, to my understanding, you already have your answer.
Replace "common code" to "common business rules" and it becomes obvious. If the behaviors of both services A and B have changed, you have to redeploy both A and B.
However, I think this situation smells familiar... Do you have "common code" for things that aren't really common business rules? If you do, you're in for some surprises.
I may just be straying from the topic here, but I've seen this happen before. Quite often, people see two similar blocks of code and think "Hey, I've seen this before... A for-loop at a collection of Orders, filtering by isSubmitted... Yep, just like in that other component. I think I can extract that into a common object!". This is soon followed by a "Hey guys, look, I've just removed some duplication!" (I may or may not be quoting myself here...).
What happens next is surprising: One component changes that behavior, while the other doesn't. Then you go to the "common component" and try to slice into smaller "reusable pieces", trying to keep it as common, but different for each dependent component. This happens for a while, until people finally realize that the code shouldn't really belong there.
Turns out this is a often the result of following DRY and "remove duplication", without considering that, in a more abstract level, there really isn't duplication in the two very similar blocks of code. Now, I'm not saying DRY and "remove duplication" are bad at all, but that you must also pay attention to the Single Responsibility Principle.
Sometimes, two identical blocks of code serve different roles in the system, and just accidentally happen to do the same thing. But since the roles are different, the requirements for a role may change while the other doesn't. I recommend watching this talk about the SRP, where that same example is given.
It may look like I've strayed too far off from the topic here, but SRP is very closely related to continuous delivery, exactly because it aims at reducing the amount of accidental coupling between modules (and services), allowing changes to be kept at a minimum range of impact, to a point where only one module has to be redeployed.
But hey, I may really just have strayed off, and you really just have common business behavior between your services. If that's the case, as I said before, you already have your answer. Anything that changes get redeployed, and you won't have to find new tools for that, since this should be obvious, because you also need to test those services.