The things in build pipelines today that you mentioned (linting, testing, events/webhooks), are all things that Reflame will eventually try to build versions of, with a focus on speed similar to what we've done with deployment, but they're definitely not there today.
This means if you want those things (and most reasonable people probably do), you do still need to install and run them locally and in whatever existing CI pipeline you're currently running them in.
The difference Reflame makes even in this context is that your deploys, both to preview and to production, are no longer blocked behind all of those frustratingly slow processes that break your flow every time you hit them:
If you want to share a work in progress with someone else, you no longer have to wait minutes for a preview to go up. It will be up the moment you made your changes.
If you have a production issue where you need to ship new code to fix, you no longer have to wait minutes for a build pipeline to run, during which your product will remain broken. It can go live as soon as you're done coding the fix.
Most importantly, having instant deploys unblocks a ton of opportunities around running tests and checks against the live production deployment, either as sanity checks that run after shipping with notifications on failure, allowing you a chance to revert (also instantly) if you broke something, in order to maximize the efficiency of the feedback loop (this is the approach I'd recommend and build first), or as a blocking safety net that can prevent broken changes from reaching customers in exchange for adding more friction to deploy every other good changeset (I'll probably build this eventually given enough demand, but would recommend that it be used very sparingly).
The things in build pipelines today that you mentioned (linting, testing, events/webhooks), are all things that Reflame will eventually try to build versions of, with a focus on speed similar to what we've done with deployment, but they're definitely not there today.
This means if you want those things (and most reasonable people probably do), you do still need to install and run them locally and in whatever existing CI pipeline you're currently running them in.
The difference Reflame makes even in this context is that your deploys, both to preview and to production, are no longer blocked behind all of those frustratingly slow processes that break your flow every time you hit them:
If you want to share a work in progress with someone else, you no longer have to wait minutes for a preview to go up. It will be up the moment you made your changes.
If you have a production issue where you need to ship new code to fix, you no longer have to wait minutes for a build pipeline to run, during which your product will remain broken. It can go live as soon as you're done coding the fix.
Most importantly, having instant deploys unblocks a ton of opportunities around running tests and checks against the live production deployment, either as sanity checks that run after shipping with notifications on failure, allowing you a chance to revert (also instantly) if you broke something, in order to maximize the efficiency of the feedback loop (this is the approach I'd recommend and build first), or as a blocking safety net that can prevent broken changes from reaching customers in exchange for adding more friction to deploy every other good changeset (I'll probably build this eventually given enough demand, but would recommend that it be used very sparingly).