Like POTTT mentioned, Pega has it's own facilities to manage release rulesets, hot fixes etc.
Now a days, I'm seeing a few clients are trying to integrate this with other tools to achieve something of no use to Business. Some clients are trying to do "Deployment automation", I don't understand why would some one want to automate deployment and jeopardize their production systems.. It hardly takes 20 mins to do a deployment normally in Pega using Import (except for initial releases, then also most of the time is done for sanity testing).
Is that worthy to build custom solution for deployments? Absolutely no, it's just wasting resources on something which is already available and easily done in Pega. Pega is a BPM tool and shouldn't be used for IT projects where it's not intended to (can be used in IT projects where there's a process but definitely for things like Deployment automation etc.).
The point of automation is reliable repeatability across all environments, not just the final production release. Teams want to be able to promote a set of changes into, e.g., UAT, possibly making changes along the way. Each time, they want the changes to be pushed in a completely automated way. Once everything stabilises, they want to use exactly the same mechanism to push to production so they know they're getting exactly what they tested against in UAT.
Moreover, Pega is often not the only moving part in a complex environment. Being able to integrate Pega deployments into the larger ecosystem is hugely beneficial, allowing, for example, CI infrastructure to stand up the right version of a Pega application with a particular build of some downstream code base for automated testing with no human intervention.