Indeed, a server certificate change implies a minor rollover (as described in Appendix A.4 to RFC 6698): the new TLSA record has to be published before the certificate is replaced. The new certificate cannot be activated on the server until the TTL has expired and the old TLSA information has been flushed from all caches. If the new certificate is activated too soon, you run the risk that validating clients will not accept it due to a mismatch with the old information.
Certificates generated using the popular Let's Encrypt are valid for ninety days. The developers say that a desire to 'force automation' is one of the main reasons for the short validity period. The requesting and installation of new certificates can easily be automated using certbot software (an ACME client). However, tooling for automatically generating and installing TLSA records on a DNS server is somewhat limited.
OpenDNSSEC users could utilise Dennis Baaten's recently published bash script as a basis for automation. For BIND installations, the most obvious solution would be to build something around the nsupdate command for Dynamic DNS (DDNS) updates.