CICD can get out of hand pretty quickly. If an off-the-shelf solution works for you with minimal changes to your code and workflow then that's fantastic. Ofttim

CICD can get out of hand pretty quickly. If an off-the-shelf solution works for you with minimal changes to your code and workflow then that's fantastic. Ofttimes they're simultaneously clunky and full of unnecessary (to you) features while not supporting the few things you care about. Writing a general purpose CICD probably isn't a good idea for most organizations IMO, but writing a CICD that handles just your use cases is super easy and can take less time than writing the workarounds necessary otherwise. Plus, when things inevitably go wrong the code is right there for you to fix. The second you notice your engineers are writing anything like custom batching logic to get around CICD limits, custom change detection because the general-purpose solution can't appropriately recognize transitive dependencies, ways out of the CICD sandbox to interact with some raw hardware device with vendored blobs that only work on XP, or anything else fancy then that's a strong indication that you would have been better off doing it yourself from the start.