CI integration alone does not let Pernosco support all the debugging developers do. We have built additional tools to integrate Pernosco into developers' workflows.
We have a tool that lets users submit rr recordings to Pernosco for debugging. Developers can record a bug locally, submit to Pernosco, wait half an hour (for example), and receive an email with a link to the debugging session. The extra latency over immmediate local debugging with rr is unfortunate, and we can reduce it, but we think that one-off latency is worth trading off for reduced latency of every user interaction during the actual debugging session.
Many workflows involve developers pulling work from a bug tracker. Actionable bug reports typically contain steps to reproduce the bug; in that case, manual or automated systems could record the buggy execution, process it with Pernosco and link to the Pernosco debugging session from the bug report. We did this manually for a number of Mozilla Firefox bugs (e.g. bug 1490117). Some projects have infrastructure that can file bugs with testcases automatically (e.g. via fuzzing); that infrastructure could automatically generate Pernosco debugging sessions for those bugs.
Better record-and-replay systems could overcome rr's limitations and make it feasible to record the execution of applications in production, both for services and client applications. For this to be feasible for most workloads, new approaches will need to be implemented in software (e.g. extending the Linux kernel itself) or possibly hardware. We have some ideas on how this could work but it requires significant investment.